LINUX.ORG.RU

browser и ipv6

 , , ,


0

1

Можно ли как в хроме (yandex browser) что-нибудь подкрутить чтоб он ходил на сервера предпочтительно по ipv4?
В системе это, как я понял, делается в /etc/gai.conf, но браузеру он по барабану.
Все равно ломится по ipv6 и соответственно криво работает геолокация. Я в Вашингтоне :)

★★★★★

Последнее исправление: hbars (всего исправлений: 1)

Ответ на: комментарий от anonymous

ipv4 и так всем хватает, адрес 192.168.1.2 можно назначить хоть миллиону компов одновременно.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от hbars

дыкыть елементарно ватсон.
если стучишься на ипв4 сайтики - будут ипв4 пакетики.
если стучишься на ипв6 сайтики будет ипв6 :)

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ещё скажи, что NAT — хорошая технология

Конечно хорошая. У меня внешних белых статических ip-адресов больше чем компов дома, но всё равно всё за натом с пробросом нужных портов в нужные места, потому как внутри сделано как удобнее поддерживать, а наружу показано так как хочется чтоб выглядело снаружи (а иногда и не просто выглядело, ведь некоторый софт прибит гвоздями к определённому порту), и эти два слоя абстракций благодаря нату друг от друга не зависят.

стокгольмский синдром — норма.

Не знаю что это такое. Никогда не был ни в Стокгольме ни вообще в иностранных городах.

firkax ★★★★★
()
Ответ на: комментарий от Khnazile

Получи ipv6 адрес не в Вашингтоне, делов-то. Туннельные брокеры не только в США есть.

У меня брокер he.net. Tunnel Server в Стокгольме. Яндекс определяет как сша.

hbars ★★★★★
() автор топика
Ответ на: комментарий от vbr

Попробуй настроить локальный DNS-сервер так, чтобы он не отдавал AAAA записи. Я сам не пробовал, но, думаю, это не должно быть очень сложно.

Не сложно, но и не нужно. У меня в bind специально настроена обратная зона на мой домен.
Для почты, например.
А домен как бы нейтральный. .site Так что спотыкается все-таки на ipv6.
К ipv4 прикручен тот же домен и все ок.

hbars ★★★★★
() автор топика
Ответ на: комментарий от firkax

Я просто подумал, что тот же яндекс по ip смотрит имя домена и решает где я.
И чего я добьюсь отключением aaaa на днс кроме не рабочих мне нужных сервисов на ipv6 привязанных к доменам?

hbars ★★★★★
() автор топика
Ответ на: комментарий от hbars

ipv6-only сервисы да ещё и с доменными именами это что-то очень странное. Тогда настрой чтоб для белого списка доменов AAAA были разрешены а остальным нет. Правда я не знаю как это сделать, но думаю можно.

firkax ★★★★★
()
Ответ на: комментарий от firkax

ipv6-only сервисы да ещё и с доменными именами это что-то очень странное.

Ну почему. Мне намного проще запомнить имя хоста чем то безобразие как ip в ipv6.

hbars ★★★★★
() автор топика

В системе это, как я понял, делается в /etc/gai.conf, но браузеру он по барабану.

Нет, не по барабану. Вы что-то неправильно настроили.

Должно быть вот так:

# Configuration for getaddrinfo(3).
#
# So far only configuration for the destination address sorting is needed.
# RFC 3484 governs the sorting.  But the RFC also says that system
# administrators should be able to overwrite the defaults.  This can be
# achieved here.
#
# All lines have an initial identifier specifying the option followed by
# up to two values.  Information specified in this file replaces the
# default information.  Complete absence of data of one kind causes the
# appropriate default information to be used.  The supported commands include:
#
# reload  <yes|no>
#    If set to yes, each getaddrinfo(3) call will check whether this file
#    changed and if necessary reload.  This option should not really be
#    used.  There are possible runtime problems.  The default is no.
#
# label   <mask>   <value>
#    Add another rule to the RFC 3484 label table.  See section 2.1 in
#    RFC 3484.  The default is:
#
label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5
label fc00::/7      6
label 2001:0::/32   7
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
#precedence ::ffff:0:0/96  10
#
#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

#
# scopev4  <mask>  <value>
#    Add another rule to the RFC 6724 scope table for IPv4 addresses.
#    By default the scope IDs described in section 3.2 in RFC 6724 are
#    used.  Changing these defaults should hardly ever be necessary.
#    The defaults are equivalent to:
#
#scopev4 ::ffff:169.254.0.0/112  2
#scopev4 ::ffff:127.0.0.0/104    2
#scopev4 ::ffff:0.0.0.0/96       14
ValdikSS ★★★★★
()