Pull to refresh

Comments 14

Небольшой комментарий: в соотвествии с RFC 3484, операционные системы (как минимум Windows точно) предпочитают IPv4 адресам 6to4 (хотя в остальных случаях IPv6 предпочтительней). Так что не удивляйтесь, если программы будут использовать IPv6 только тогда, когда записи A нет. Это можно изменить, но это будет отступлением от SHOULD из RFC.
Спасибо, интересно. А я то думал зачем у туннельных брокеров существуют статические маршруты, когда есть 6to4.
В любом случае мои задачи «дать гаджетам доступ к IPv6» оно удовлетворяет. Те, кому 6to4 будет не хватать, могут использовать туннельных брокеров (SixXS, NetAssist или HurricaneElectric), получать у них /48 подсети и настраивать openvpn и маршрутизацию так же как у меня в статье. Собственно домашний вайфай у меня через NetAssist.
Я немного наврал про нарушение. RFC говорит SHOULD по отношению к ненастроенным (значения по умолчанию) и ненастраиваемым хостам. Настраивать можно как душе угодно, «if you know what are you doing».
Вероятно, такие значения по умолчанию были приняты для обхода кривых 6to4-роутеров. Чтобы не страдали пользователи, которые и понять не могут, что происходит.
А зачем вы закрываетесь файрволлом? Разве удобно каждый раз «открывать» нужный порт? Не лучше уже на конечном устройстве файрволл настроить так, как требуется?
Все зависит от задач. У меня клиенты VPN в основном гаджеты на андроиде или на iOS\OS X. Торренты мы там не ставим. Обращаться к ним извне не нужно. Поэтому мне проще закрыть их глобально. IPv6 лично мне нужно для доступа к IPv6 сайтам и моим серверам.
Я недавно понял, что это прекрасно вешать тот же SSH на какой-нибудь «хрен угадаешь какой» адрес IPv6 из /48 диапазона 6to4. И ни один сканер этот ssh не найдет. А еще можно по IP сервисы лочить, так как у каждого устройства свой уникальный внешний IPv6 адрес. Или несколько.
К сожалению, атак по IPv6 дохрена и больше. Есть такой проект, thc-ipv6, и некоторые утилиты в нем позволяют быстро узнать все компьютеры в удаленной сети. Для локальной же сети есть магический адрес ff02::1, который можно пинговать, и на этот пинг ответят все машины.
А каким таким образом в теории можно вычислить, что на адресе 2001:AABB:CCDD:EEFF:0123:F200:7895:ABC3 на порту 65002 висит SSH, если ВЕСЬ остальной траф на этот IP режется фаерволом?

А еще:
ping6 ff02::1
connect: Недопустимый аргумент

в том числе и из-под рута.
если ВЕСЬ остальной траф на этот IP режется фаерволом?

Да, действительно, как-то и не подумал об этом.

connect: Недопустимый аргумент

Это link-local адрес.
Либо
ping6 -I eth0 ff02::1

либо
ping6 ff02::1%eth0

к слову, последний вариант записи работает почти везде. Нужно вам, например, подключиться к компьютеру в локальной сети, который, скажем, не успел получить IPv4 по DHCP, но у него с большой вероятностью есть IPv6-адрес, то сначала пингуете ff02::1, а затем
ssh fe80::...%eth0
Сработало.

к слову, последний вариант записи работает почти везде. Нужно вам, например, подключиться к компьютеру в локальной сети, который, скажем, не успел получить IPv4 по DHCP, но у него с большой вероятностью есть IPv6-адрес, то сначала пингуете ff02::1, а затем


Не очень понял как мне найти адрес именно того компьютера, который мне нужен среди мешанины всех адресов в локалке, которые откликаются на этот пинг.
Не очень понял как мне найти адрес именно того компьютера, который мне нужен среди мешанины всех адресов в локалке, которые откликаются на этот пинг.

Теоретически можно использовать node information query. Например, если набрать что-то вроде
ping6 -N name -I eth0 ff02::1
в ответ придут адреса и хостнеймы машин в сети. На практике на такие запросы у меня дома только мак отвечает… :)
Ни одна статья, посвященная туннелям 6в4 не будет полной без пары ссылок:
6to4
Teredo

Краткое содержание обеих статей: туннель хорош только если v6 адрес нужен «просто так». В деле распространения IPv6 туннель — скорее зло.
Лучше native ipv6 может быть только native ipv6. Кто бы спорил? Но вот с точки распространения… На безрыбье и рак рыба. Как вы предложите здесь и сейчас пользователю за NAT у провайдера без IPv6 подключаться к IPv6 ресурсам?
Отвечая на ваш вопрос: туннель v6 поверх v4 из-за NAT'а (кстати, много ли провайдеров занимаются трансляцией?) называется teredo. Вещь, кстати, не менее странная и удивительная чем 6to4 + openvpn. RFC по ней сознание расширяет просто феерично.

Туннели дают возможность провайдерам откладывать внедрение v6. Типа, «на кой вам нативный, если есть туннель?» Это костыль, который местами используется очень странно: например в винде-семерке туннель включается автоматом, однако ничего не работает если не прописано v4 резолверов. В результате 95-100 процентов трафика генерится ничего не подозревающими пользователями, которым на v6 наплевать. Так что распространению v6 туннели никак не помогают.
Я спрашивал про замену не только моему решению, а туннелям вообще.

Все-таки мне кажется, в переходном режиме, для перехода к IPv6 нужны временные средства, коими являются туннели. Так как намного лучше желающим пользователям иметь хоть какое-то средство доступа к IPv6, чем не иметь его вообще. Туннели не то что помогают — они просто необходимая мера.
Все прекрасно понимают, что туннели — временная мера. Пинги больше, чем у нативного IPv6, скорости меньше. Поэтому пинанию провайдеров — это никак не мешает. Но иметь доступ к существующим IPv6 ресурсам — помогает изрядно.
Sign up to leave a comment.

Articles