Плавный переход сети компании на IPv6. Ipv6 роутер


Как IPv6 помогает роутеры ломать / Хабр

image
Предисловие
Проснулся я сегодня с мыслью, что огромное количество инструкций по настройке NAT советуют использовать строку вида:iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Многие понимают проблемы этой конструкции, и советуют добавлять:iptables -A FORWARD -i ppp0 -o eth2 -m state --state ESTABLISHED,RELATED -j ACCEPT Но, зачастую, забывают задать таблице FORWARD действие DROP по умолчанию, или добавить правило REJECT в конец таблицы. На первый взгляд, вроде бы, все кажется нормальным. Однако, это далеко не так. Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза. Все современные SOHO роутеры это учитывают, а вот неопытный администратор, который делает роутер под обычным linux, может не знать или забыть об этом. В подсети моего провайдера таких роутеров не оказалось, и мой план по захвату мира провалился. Однако, статья совсем не об этом.
Магические двоеточия
Как вы, может быть, знаете, многие современные программы и сервисы биндятся на IP :: (два двоеточия), а не на 0.0.0.0, как было раньше. IPv6 адрес :: значит то же самое, что и IPv4 0.0.0.0, т.е. «слушаем все интерфейсы». Многие считают, что если программа слушает ::, то этот сокет может принимать только IPv6-соединения, однако это далеко не так. В IPv6 есть так называемое отображение IPv4-адресов в IPv6 диапазон. Если программа слушает сокет ::, а к ней обращаются из IPv4-адреса 1.2.3.4, то программа получит соединение с адреса ::ffff:1.2.3.4. Этого можно избежать, сделав:sysctl -w net.ipv6.bindv6only=1 Но это нужно далеко не всегда, т.к. обычно удобно, что программа слушает один сокет, а получать соединения может по двум протоколам сразу. Практически во всех дистрибутивах, IPv6-сокеты ведут себя именно так, т.е. bindv6only=0.
fe80 и его друг ff02
Если вы не застряли в 90-х, вы гарантированно сталкивались с IPv6, сами того не зная. Абсолютно во всех современных операционных системах по умолчанию включена поддержка IPv6, а это значит, что на каждый (кроме редких исключений) интерфейс автоматически назначается IPv6 Link-Local адрес, который начинается с fe80::. Более того, в некоторых случаях этот адрес получается просто путем кодирования MAC-адреса. Казалось бы, найти Link-Local адреса должно быть проблематично, они же все-таки длинные и страшные, но тут нам на помощь приходит мультикаст-диапазон ff02::.

Есть такой классный адрес: ff02::1. Если его попинговать (обязательно с указанием интерфейса, т.к. это Link Local адрес), то откликнутся все компьютеры в сети:

% ping6 ff02::1%enp4s0 PING ff02::1%enp4s0(ff02::1) 56 data bytes 64 bytes from fe80::21f:d0ff:fea2:46a3: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from fe80::fe8b:97ff:fe66:9100: icmp_seq=1 ttl=64 time=1.60 ms (DUP!) 64 bytes from fe80::226:9eff:fe6d:22a0: icmp_seq=1 ttl=64 time=1.62 ms (DUP!) 64 bytes from fe80::f2de:f1ff:fe27:3685: icmp_seq=1 ttl=64 time=1.70 ms (DUP!) 64 bytes from fe80::62a4:4cff:fe7b:1c90: icmp_seq=1 ttl=64 time=2.95 ms (DUP!) 64 bytes from fe80::fac0:91ff:fe32:5bbe: icmp_seq=1 ttl=64 time=3.02 ms (DUP!) 64 bytes from fe80::226:18ff:fe9e:4b3a: icmp_seq=1 ttl=64 time=3.09 ms (DUP!) 64 bytes from fe80::ba70:f4ff:fe8b:8dda: icmp_seq=1 ttl=64 time=3.14 ms (DUP!) 64 bytes from fe80::62a4:4cff:fea2:aee0: icmp_seq=1 ttl=64 time=3.27 ms (DUP!) 64 bytes from fe80::224:54ff:fedb:d17d: icmp_seq=1 ttl=64 time=3.93 ms (DUP!) 64 bytes from fe80::2a1:b0ff:fe40:904: icmp_seq=1 ttl=64 time=4.21 ms (DUP!) 64 bytes from fe80::76d0:2bff:fe69:31d8: icmp_seq=1 ttl=64 time=6.09 ms (DUP!) Как мы видим, откликнулось 11 устройств. Кстати, этот адрес очень удобно использовать, если у вас, например, сервер настроен на получение адреса через DHCP, а DHCP упал, или если вы напрямую подключились к порту сервера, а DHCP поднимать не хочется. Вам остается просто зайти по fe80-адресу по ssh.

Если попинговать адрес ff02::2, то откликнутся все IPv6-роутеры в сети. К сожалению, в моем случае таких не было.

Сканируем роутеры
Я решил просканировать эти адреса через nmap, и вот что вышло:% nmap -6 -T4 --open -n -iL list.txtСкрытый текстStarting Nmap 6.46 ( http://nmap.org ) at 2014-06-07 16:53 MSK Nmap scan report for fe80::f2de:f1ff:fe27:3685 Host is up (0.0014s latency). Not shown: 999 closed ports PORT STATE SERVICE 53/tcp open domain Nmap scan report for fe80::fe8b:97ff:fe66:9100 Host is up (0.0012s latency). Not shown: 998 closed ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http Nmap scan report for fe80::226:9eff:fe6d:22a0 Host is up (0.0012s latency). Not shown: 998 closed ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http Nmap scan report for fe80::62a4:4cff:fea2:aee0 Host is up (0.00099s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::226:18ff:fe9e:4b3a Host is up (0.00094s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::62a4:4cff:fe7b:1c90 Host is up (0.00085s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::76d0:2bff:fe69:31d8 Host is up (0.00072s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::fac0:91ff:fe32:5bbe Host is up (0.00037s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::ba70:f4ff:fe8b:8dda Host is up (0.00059s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::2a1:b0ff:fe40:904 Host is up (0.00077s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap scan report for fe80::224:54ff:fedb:d17d Host is up (0.0012s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp open telnet Nmap done: 11 IP addresses (11 hosts up) scanned in 4.04 seconds По IPv4 все эти порты закрыты. Как мы видим, у многих роутеров открыт Telnet, веб-интерфейс и DNS извне по IPv6. Что же это значит? Все просто — разработчики прошивки роутера просто-напросто забыли про IPv6.

Роутеры с открытым telnet:

  • ASUS RT-N10 (2.0.3.2)
  • ASUS RT-G32
  • ASUS RT-G32.C1 (2.0.2.6)
  • Upvel UR-312N4G
Роутеры с открытым веб-интерфейсом:
  • D-Link DIR-615 (E4, 5.11NV)
  • D-Link DIR-615 (E4, 5.11RU)

На многих из них были стандартные пароли admin/admin. На большинстве этих роутеров ip6tables (iptables для IPv6) просто отсутствовал. Разработчики должны были либо вообще отключить поддержку IPv6 в ядре, либо убедиться, что http и telnet демоны слушают 0.0.0.0, а не :: но, по какой-то причине не стали этого делать.

А что, если…?
Если бы на роутере был каким-то образом настроен IPv6, и, соответственно, включена маршрутизация IPv6 пакетов (net.ipv6.conf.all.forwarding=1), а ip6tables либо вообще не настроен, либо настроен неправильно, то можно было бы точно так же, как в случае с IPv4, маршрутизировать пакеты через этот роутер.
Заключение
Некоторым компаниям я уже отправил письма об этих уязвимостях, а некоторым еще не успел. В любом случае, письма будут отправлены всем. Используйте IPv6, не забывайте о нем.
P.S.
Для меня стало неожиданностью, что браузеры не умеют открывать адреса с указанием интерфейса. У меня никак не получилось открыть ссылку вида http://[fe80::a:b:c:d%enp4s0] во всех браузерах. Говорят, что знак процента нужно экранировать, т.е. http://[fe80::a:b:c:d%25enp4s0], но у меня и так не вышло. Пришлось использовать проброс портов.

habr.com

Практика IPv6 — домашняя сеть / Хабр

Abstract: Рассказ про некоторые возможности IPv6 на примере конфигурации сложной домашней IPv6-сети. Включает в себя описания мультикаста, подробности настройки и отладки router advertisement, stateless DHCP и т.д. Описано для linux-системы. Помимо самой конфигурации мы внимательно обсудим некоторые понятия IPv6 в теоретическом плане, а так же некоторые приёмы при работе с IPv6. Вполне понятный вопрос: почему я ношусь с IPv6 сейчас, когда от него сейчас нет практически никакой пользы?

Сейчас с IPv6 можно возиться совершенно безопасно, без каких-либо негативных последствий. Можно мирно разбираться в граблях и особенностях, иметь его неработающим месяцами и nobody cares. Я не планирую в свои старшие годы становиться зашоренным коболистом-консерватором, который всю жизнь писал кобол и больше ничего, и все новинки для него «чушь и ерунда». А вот мой досточтимый воображаемый конкурент, когда IPv6 станет продакт-реальностью, будет либо мне не конкурентом, либо мучительно и в состоянии дистресса разбираться с DAD, RA, temporary dynamic addresses и прочими странными вещами, которым посвящено 30+ RFC. А что IPv6 станет основным протоколом ещё при моей жизни — это очевидно, так как альтернатив нет (даже если бы они были, их внедрение — это количество усилий бОльшее, чем завершение внедрения IPv6, то есть любая альтернатива всегда будет отставать). И что адреса таки заканчиваются видно, по тому, как процесс управления ими перешёл во вторую стадию — стадию вторичного рынка. Когда свободные резервы спекуляций и хомячаяния адресов закончится, начнётся этап суровой консолидации — то есть выкидывание всего неважного с адресов, перенос всех «на один адрес» и т.д. Примерно в это время IPv6 начнёт использоваться для реальной работы.

Впрочем, рассказ не про будущее IPv6, а про практику работы с ним. В Санкт-Петербурге есть такой провайдер — Tierа. И я их домашний пользователь. Это один из немногих провайдеров, или, может быть, единственный в городе, кто предоставляет IPv6 домашним пользователям. Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального (то есть в четыре миллиарда раз больше адресов, чем всего IPv4 адресов быть может — и всё это в одни руки). Я попробую не просто описать «как настроить IPv6», но разобрать базовые понятия протокола на практических примерах с теоретическими вставками.

Структура сети: (Оригиналы картинок: github.com/amarao/dia_schemes)

  • 1, 2, 3 — устройства в локальной сети, работают по WiFi
  • 4 — WiFi-роутер, принужденный к работе в роле access point (bridge), то есть коммутатора между WiFi и LAN
  • 5 — eth4 сетевой интерфейс, который раздаёт интернет в локальной сети
  • 6 — мой домашний компьютер (основной) — desunote.ru, который раздачей интернета и занимается, то есть работает маршрутизатором
  • 7 — eth3, интерфейс подключения к сети Tiera
Я пропущу всю IPv4 часть (ничего интересного — обычный nat) и сконцентрируюсь на IPv6.

Полученные мною настройки от Tiera для IPv6:

  1. Адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128 мне выдан для компьютера/шлюза
  2. Сеть 2a00:11d8:1201:32b0::/64 мне выдана для домашних устройств

У провайдера сеть 2a00:11d8:1201:32b0::/64 маршрутизируется через 2a00:11d8:1201:0:962b:18:e716:fb97 (то есть через мой компьютер). Заметим, это всё, что я получил. Никаких шлюзов и т.д. — тут начинается магия IPv6, и самое интересное. «Оно работает само».

Начнём с простого: настройка 2a00:11d8:1201:0:962b:18:e716:fb97 на eth3 для компьютера. Для удобства чтения все конфиги и имена файлов я оставлю на последнюю секцию.

Мы прописываем ipv6 адрес на интерфейсе eth3… И чудо, он начинает работать. Почему? Каким образом компьютер узнал, куда надо слать пакеты дальше? И почему /128 является валидной сетью для ipv6? Ведь /128 означает сеть размером в 1 ip-адрес и не более. Там не может быть шлюза!

Для того, чтобы понять, что происходит, нам надо взглянуть на конфигурацию сети (я вырежу всё лишнее, чтобы не пугать выводом):

# ip address show eth3 (обычно сокращают до ip a s eth3)

eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 (skip) inet6 2a00:11d8:1201:0:962b:18:e716:fb97/128 scope global valid_lft forever preferred_lft forever inet6 fe80::218:e7ff:fe16:fb97/64 scope link valid_lft forever preferred_lft forever

Упс. А почему у нас на интерфейсе два адреса? Мы же прописывали один? Наш адрес называется 'scope global', но есть ещё и 'scope link'…

Тут нас встречает первая особенность IPv6 — в нём определено понятие 'scope' (область видимости) для адреса. Есть следующие виды scope:
  • global — «обычный» адрес, видимый всему Интернету
  • local или link-local — адрес, видимый только в пределах сетевого сегмента. Ближайшим аналогом этого является configless IPv4 из диапазона 169.254.0.0/16, на который сваливается любая windows, которой сказали автоматически получить адрес, а DHCP-сервера вокруг нет. Эти адреса не могут быть маршрутизируемы (то есть тарфик с них не передаётся дальше своей сети). Подробнее про link-local address (wiki).
  • host, он же interface — видимость в пределах хоста. Примерный аналог — loopback адреса для IPv4 (127.0.0.0/8)
  • admin-local — в живую не видел, но какая-то промеждуточная стадия
  • site-local — видимость в пределах офиса. Аналог серых 192.168.0.0/16, то есть адреса, которые не должны выходить за пределы локальной сети
  • organization-local — адреса, которые не выходят за пределы организации.

В процессе проектирования IPv6 вопрос 'scope' много и тщательно обсуждался, потому что исходное деление IPv4, даже с последующими дополнениями, явно не соответствовало потребностям реальных конфигураций. Например, если у вас объединяются две организации, в каждой из которых используется сеть 10.0.0.0/8, то вас ждёт множество «приятных» сюрпризов. В IPv6 решили с самого начала сделать множество градаций видимости, что позволило бы более комфортно осуществлять дальнейшие манипуляции.

Из всего этого на практике я видел использование только host/interface, link/local и global. В свете /64 и пусть никто не уйдёт обиженным, специально возиться с site-local адресами будет только параноик.

Второй важной особенностью IPv6 является официальное (на всех уровнях спецификаций) признание того, что у интерфейса может быть несколько IP-адресов. Этот вопрос в IPv4 был крайне запутан и часто приводил к ужасным последствиям (например, запрос получали на один интерфейс, а отвечали на него через другой, но с адресом первого интерфейса).

Так как в отличие от IPv4 у IPv6 может быть несколько адресов на интефрейсе, то компьютеру не нужно выбирать «какой адрес взять». Он может брать несколько адресов. В случае IPv4 сваливание на link-local адрес происходило в режиме «последней надежды», то есть по большому таймауту.

А в IPv6 мы можем легко и просто с самого первого момента, как интерфейс поднялся, сделать ему link local (и уже после этого думать о том, какие там global адреса есть).

Более того, в IPv6 есть специальная технология автоматической генерации link-local адреса, которая гарантирует отсутствие дублей. Она использует MAC-адрес компьютера для генерации второй (младшей) половинки адреса. Поскольку MAC-адреса уникальны хотя бы в пределах сегмента (иначе L2 сломан и всё прочее автоматически не работает), то использование MAC-адреса даёт нам 100% уверенность в том, что наш IPv6 адрес уникален.

В нашем случае это inet6 fe80::218:e7ff:fe16:fb97/64 scope link. Обратите внимание на префикс — fe80 — это link-local адреса.

Как он делается?

Принцип довольно простой:

MAC-адрес eth3 — это 00:18:e7:16:fb:97, а локальный адрес ipv6 — F80:000218:e7ff:fe16:fb97. Да-да, именно так, как выделено жирным. Зачем было в середину всобачивать ff:fe — не знаю. Сам алгоритм называется modified EUI-64. Сам этот алгоритм очень мотивирован и полон деталей. С позиции системного администратора — пофигу. Адрес есть и есть. Интересным может быть, наверное, обратный алгоритм — из link-local узнать MAC и не более.

Итак, у нас на интерфейсе два адреса. Мы даже знаем, как появились они оба (один автоматически при подъёме интерфейса, второй прописали мы). Мы даже знаем, как система поняла, что адрес глобальный — он из «global» диапазона.

Но каким образом система узнала про то, кто его шлюз по умолчанию? И как вообще может жить /128?

Посмотрим на таблицу маршрутизации:

ip -6 route show (обычно сокращают до ip -6 r s, или даже ip -6 r):

2a00:11d8:1201:0:962b:18:e716:fb97 dev eth3 proto kernel metric 256 fe80::/64 dev eth3 proto kernel metric 256 default via fe80::768e:f8ff:fe93:21f0 dev eth3 proto ra metric 1024 expires 1779sec

Что мы тут видим? Первое — говорит нам, что наш IPv6 адрес — это адрес нашего интерфейса eth3. Второе говорит, что у нас есть link-local сегмент в eth3. У обоих источник — это kernel.

А вот третье — это интрига. Это шлюз по умолчанию, который говорит, что весь трафик надо отправлять на fe80::768e:f8ff:fe93:21f0 на интерфейсе eth3, и источником информации о нём является некое «ra», а ещё сказано, что оно протухает через 1779 секунд.

Что? Где? Куда? Кто? За что? Почему? Зачем? Кто виноват?

Но перед ответом на эти вопросы нам придётся познакомиться с ещё одной важной вещью — multicast. В IPv4 muticast был этакой технологией «не от мира сего». Есть, но редко используется в строго ограниченных случаях. В IPv6 эта технология — центральная часть всего и вся. IPv6 не сможет работать без мультикаста. И без понимания этого многие вещи в IPv6 будут казаться странными или ломаться в неожиданных местах.

Кратко о типах трафика, возможно кто-то пропустил эту информацию, когда изучал IPv4:

  • unicast — пакет адресуется конкретному получателю. Обычный трафик идёт юникастом.
  • broadcast — пакет адресуется всем, кто его слышит. Например, в IPv4 так рассылается запрос о mac-адресе для данного IP-адреса.
  • multicast — пакет адресуется некоторому множеству узлов, которые слушают специальный multicast-адрес. И если получают сообщение, то реагируют на него.
  • anycast — пакет адресуется на адрес, общий для кучи узлов. Кто к запрашивающему ближе (и готов ответить) — тот и отвечает

Так вот, в IPv6 НЕТ БРОДКАСТОВ. Вообще. Вместо них есть мультикаст. И некоторые из мультикаст-адресов являются ключевыми для работы IPv6.

Вот примеры таких адресов (они все link-local, то есть имеют смысл только в контексте конкретного интерфейса):

  • FF02::1 — все узлы сети. Считайте, старинный бродкаст канального уровня.
  • FF02::2 — все маршрутизаторы сети
Полный список адресов, вместе с нюансами link-local, site-local, etc, можно посмотреть тут: www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

В практическом смысле это означает, что мы можем отправить бродкаст пинг всем узлам, или всем маршрутизаторам. Правда, нам для этого придётся указать имя интерфейса, в отношении которого мы интересуемся cоседями.

ping6 -I eth3 FF02::2

64 bytes from fe80::218:e7ff:fe16:fb97: icmp_seq=1 ttl=64 time=0.039 ms 64 bytes from fe80::768e:f8ff:fe93:21f0: icmp_seq=1 ttl=64 time=0.239 ms (DUP!) 64 bytes from fe80::211:2fff:fe23:5763: icmp_seq=1 ttl=64 time=1.38 ms (DUP!) 64 bytes from fe80::5a6d:8fff:fef5:6235: icmp_seq=1 ttl=64 time=5.68 ms (DUP!) 64 bytes from fe80::cad7:19ff:fed5:25b8: icmp_seq=1 ttl=64 time=7.20 ms (DUP!) 64 bytes from fe80::22aa:4bff:fe1e:9e88: icmp_seq=1 ttl=64 time=8.19 ms (DUP!) 64 bytes from fe80::5a6d:8fff:fe4a:c643: icmp_seq=1 ttl=64 time=8.69 ms (DUP!) 64 bytes from fe80::205:9aff:fe3c:7800: icmp_seq=1 ttl=64 time=11.1 ms (DUP!) 64 bytes from fe80::20c:42ff:fef9:807a: icmp_seq=1 ttl=64 time=16.0 ms (DUP!)

Сколько маршрутизаторов вокруг меня… Первым откликнулся мой компьютер. Это потому, что он тоже роутер. Но вопрос маршрутизации мы рассмотрим чуть позже. Пока что важно, что мы видим все роутеры и только роутеры (а, например, ping6 -I eth3 FF002::1 показывает порядка 60 соседей).

Мультикаст-групп (группой называют все узлы, которые слушают данный мультикаст-адрес) много. Среди них — специальная группа FF02::6A с названием «All-Snoopers». Именно этой группе и рассылаются routing advertisements. Когда мы хотим их получать — мы вступаем в соответствующую группу. Точнее не мы, а наш компьютер.

В IPv6 придумали такую замечательную вещь — когда маршрутизатор рассылает всем желающим информацию о том, что он маршрутизатор. Рассылает периодически.

В отношении этого вопроса есть целый (всего один, что удивительно) RFC: tools.ietf.org/html/rfc4286, но нас интересует из всего этого простая вещь: маршрутизатор рассылает информацию о том, что он маршрутизатор. И, может быть, чуть-чуть ещё информации о том, что в сети происходит.

Вот откуда наш компьютер узнал маршрут. Некий маршрутизатор сказал ему «я маршрутизатор». И мы ему поверили. Почему мы выбрали именно его среди всех окружающих маршруштизаторов (см ответ на пинг на FF02::2 выше) мы обсудим чуть дальше. Пока что скажем, что этот «настоящий» маршрутизатор правильно себя анонсировал.

Таким образом, происходит следующая вещь:

У нас адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128, и ещё есть link-local. Мы слышим мультикаст от роутера, верим ему, и добавляем в таблицу маршрутизации нужный нам адрес как default. С этого момента мы точно знаем, что адрес в сети. Таким образом, отправка трафика в интернет больше не проблема. Мы генерируем пакет с src=2a00:11d8:1201:0:962b:18:e716:fb97 и отправляем его на шлюз по умолчанию, который в нашем случае — fe80::768e:f8ff:fe93:21f0. Другими словами, мы отправляем трафик не своему «шлюзу» в сети, а совсем другому узлу совсем по другому маршруту. Вполне нормальная вещь как для IPv6, так и для IPv4, правда, для IPv4 это некая супер-крутая конфигурация, а для IPv6 — часть бытовой повседневности.

Но как трафик приходит обратно? Очень просто. Когда маршрутизатор провайдера получает пакет, адресованный 2a00:11d8:1201:0:962b:18:e716:fb97, то у него на одном из интерфейсов написано, что он там 2a00:11d8:1201::/64 via (я не знаю, как там называется интерфейс, но пусть) GE1/44/12. Маршрутизатор спрашивает всех соседей (neighbor discovery) об их адресах, и внезапно видит, что адрес такой-то в сети. Что может быть проще — мак есть, адрес есть, отправляем в интерфейс. Ура, наш компьютер видит трафик. Двусторонняя связь установлена.

Въедливый читатель может спросить несколько вопросов: что значит «написано на интерфейсе»? И что значит «neighbor discovery»?

Вопросы справедливые. Для начала попробуем выяснить, какие узлы у нас есть в сети из подсети 2a00:11d8:1201::/64

Для того, чтобы посмотреть router advertisement на интерфейсе нам поднадобится программа radvdump из пакета radvd. Она позволяет печатать анонсы, проходящие на интерфейсах, в человеческом виде. Заметим, сам пакет radvd нам ещё пригодится (так как его демон — radvd позволяет настроить анонсирование со своих интерфейсах).

Итак, посмотрим, что аносирует нам Tiera:

radvdump eth3 (и подождать прилично, ибо анонсы не очень часто рассылаются)

# # radvd configuration generated by radvdump 1.9.1 # based on Router Advertisement from fe80::768e:f8ff:fe93:21f0 # received by interface eth3 # interface eth3 { AdvSendAdvert on; # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump AdvManagedFlag on; AdvOtherConfigFlag on; AdvReachableTime 0; AdvRetransTimer 0; AdvCurHopLimit 64; AdvDefaultLifetime 1800; AdvHomeAgentFlag off; AdvDefaultPreference medium; AdvSourceLLAddress on; AdvLinkMTU 9216; prefix 2a00:11d8:1201::/64 { AdvValidLifetime 2592000; AdvPreferredLifetime 604800; AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; # End of prefix definition }; # End of interface definition

Из всего этого важным является:

  • Адрес, с которого получен анонс (в нашем случае fe80::768e:f8ff:fe93:21f0) — это и есть адрес шлюза.
  • Указание на сетевой сегмент, в котором можно автоконфигурировать себе адреса
  • Флаг AdvAutonomous on, указывающий, что этот анонс имеет смысл. Если бы флаг был off, то его бы можно было смело игнорировать.

Таким образом всё просто — адрес мы указали, маршрутизатор нам «себя» прислал, ядро маршрут обновило. Вуаля, у нас IPv6 на компьютере заработал.

Получить IPv6 адрес для компьютера — этого маловато будет. Хочется так, чтобы каждое мобильное устройство сидело не за позорным NAT'ом, а голой задницей с белым адресом в Интернете. Желательно ещё при этом так, чтобы злые NSA/google не могли по хвостику моего адреса (в котором закодирован MAC) отслеживать мои перемещения между разными IPv6-сетями (хотя в условиях установленного play services эта параноидальность выглядит наивной и беззащитной).

Но, в любом случае, у нас задача раздать интернет дальше.

Tiera, выдавая мне ipv6, настроила у себя маршрут: 2a00:11d8:1201:32b0::/64 via 2a00:11d8:1201:0:962b:18:e716:fb97.

Так как fb97 уже является адресом моего компьютера, настройка машрутизации плёвое дело:

sysctl net.ipv6.conf.all.forwarding=1

… и у нас через пол-часика полностью отваливается IPv6 на компьютере? Почему? Кто виноват?

Оказывается, линукс не слушает routing advertisement, если сам является маршрутизатором. Что, в общем случае, правильно, потому что если два маршрутизатора будут объявлять себя маршрутизаторами и слушать маршруты друг друга, то мы быстро получим простейшую петлю из двух зацикленных друг на друга железных болванов.

Однако, в нашем случае мы всё-таки хотим слушать RA. Для этого нам надо включить RA силком.

Это делается так:

sysctl net.ipv6.conf.eth3.accept_ra=2

Заметим, важно, что мы слушаем RA не всюду, а только на одном интерфейсе, с которого ожидаем анонсы.

Теперь маршрутизация работает, маршрут получается автоматически, и можно на каждом мобильном устройстве вручную прописать IPv6 адрес и вручную указать IPv6 шлюз, и вручную прописать IPv6 DNS, и вручную… э… слишком много вручную.

Если мне выдали настройки автоматом, то я так же хочу раздавать их дальше автоматом. Благо, dhcpd отлично справляется с аналогичной задачей для IPv4.

Прелесть IPv6 в том, что мы можем решить эту задачу (раздачу сетевых настроек) без каких-либо специальных сервисов и в так называемом stateless режиме. Главная особенность stateless режима состоит в том, что никто не должен напрягаться и что-то сохранять, помнить и т.д. Проблемы с DHCP в IPv4 чаще всего вызывались тем, что один и тот же адрес выдавали двум разным устройствам. А происходило это из-за того, что злой админ стирал/забывал базу данных уже выданных аренд. А ещё, если железок много и они забывают «отдать аренду», то адреса заканчиваются. Другими словами, stateful — это дополнительные требования и проблемы.

Для решения тривиальной задачи «раздать адреса» в IPv6 придумали stateless режим, который основывается на routing advertisement. Клиентскую часть мы уже видели, теперь осталось реализовать серверную, дабы накормить IPv6 планшетик.

Для настройки анонсов используется специальная программа-демон — radvd. С утилитой из её комплекта (radvdump) мы познакомились чуть выше. Прелесть утилиты в том, что она выводит не просто полученные данные, а готовый конфиг radvd для рассылки аналогичных анонсов.

Итак, настраиваем radvd:

interface eth4 { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; prefix 2a00:11d8:1201:32b0::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; }; Главное тут — префикс и указание на AdvAutonomous.

Запускаем демона, берём ближайший ноутбук (обычная бытовая убунта с обычным бытовым network-manager'ом), рррраз, и получаем…

ip a show wlan0 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 10:0b:a9:bd:26:a8 brd ff:ff:ff:ff:ff:ff inet 10.13.77.167/24 brd 10.13.77.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 2a00:11d8:1201:32b0:69b9:8925:13d9:a879/64 scope global temporary dynamic valid_lft 86339sec preferred_lft 14339sec inet6 2a00:11d8:1201:32b0:120b:a9ff:febd:26a8/64 scope global dynamic valid_lft 86339sec preferred_lft 14339sec inet6 fe80::120b:a9ff:febd:26a8/64 scope link valid_lft forever preferred_lft forever Откуда у нас столько ipv6 мы поговорим в следующем разделе, а пока что отметим, что адреса сконфигурировались автоматически. И маршруты у нас такие: ip -6 r 2a00:11d8:1201:32b0::/64 dev wlan0 proto kernel metric 256 expires 86215sec fe80::/64 dev wlan0 proto kernel metric 256 default via fe80::5ed9:98ff:fef5:68bf dev wlan0 proto ra metric 1024 expires 115sec Надеюсь, читатель уже вполне понимает, что происходит. Однако… Чего-то не хватает. У нас нет dns-resolver'а. Точнее есть, но выданный dhcpd по IPv4. А у нас пятиминутка любви к IPv6, так то ресолвер нам тоже нужен IPv6.

Тяжело расчехляя aptitude ставим dhcpv6 и прописываем опции nameserver Как бы не так!

К счастью, IPv6 очень долго продумывался и совершенствовался. Так что мы можем решить проблему без участия DHCP-сервера. Для этого нам надо добавить к анонсу маршрута ещё указание на адреса DNS-серверов.

Описывается вся эта примудрость в RFC 6106. По сути — у нас есть возможность указать адрес рекурсивного DNS-сервера (то есть «обычного ресолвера») в анонсе, распространяемом маршрутизатором.

По большому счёту это всё, что мы хотим от DHCP, так что DHCP там тут не нужен. Компьютеры сами делают себе адреса непротиворечивым образом (то есть для исключения коллизий), знают адреса DNS-серверов. Интернетом можно пользоваться.

Для этого мы дописываем в конфиг radvd соответствующую опцию:

RDNSS 2001:4860:4860::8888 2001:4860:4860::8844 { }; (полный конфиг — см. в конце статьи).

Пробуем подключиться снова — и, ура, всё работает.

ping6 google.com PING google.com(lb-in-x66.1e100.net) 56 data bytes 64 bytes from lb-in-x66.1e100.net: icmp_seq=1 ttl=54 time=25.3 ms ^C --- google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 25.312/25.312/25.312/0.000 ms

google.com выбран был не случайно. Сервисы гугля (в немалой степени youtube) — это едва ли не основной источник IPv6 трафика в настоящий момент. Второй источник — торренты, где можно увидеть аж 5-10% пиров в IPv6 варианте.

На этом рассказ можно было закончить, если бы не ещё одна важная деталь — что за третий IPv6-адрес на интерфейсе ноутбука? И что это за temporary dynamic?

Как я уже упомянул выше, автоматическое конфигурирование IPv6-адреса на основе MAC-адреса сетевого адаптера хорошо всем, кроме того, что создаёт практически идеальное средство для отслеживания пользователей в сети. Вы можете брать любые браузеры и операционные системы, использовать любых провайдеров (использующих IPv6, так что это всё пишется с прицелом на будущее) — но у вас будет один и тот же MAC-адрес, и любой гугуль, NSA или просто спамер смогут вас отслеживать по младшим битам вашего IPv6 адреса. Старшие будут меняться в зависимости от провайдера, а младшие сохраняться как есть.

Для решения этой проблемы были придуманы специальные расширения для IPv6, называющиеся privacy extensions (RFC 4941). Как любое RFC, его чтение — это обычно признак отчаяния, так что по сути этот стандарт описывает как с помощью шаманства и md5 генерировать случайные автоконфигурируемые адреса.

Как это работает?

Хост, в нашем случае обычная убунта на обычном ноутбуке, генерирует штатным образом IPv6 адрес из анонса маршрутизатора. После этого она придумывает себе другой адрес, проверяет, что этот адрес не является зарезервированным (например, нам так повезло, и md5 хеш сгенерировал нам все нули — вместо того, чтобы трубить об этом на всех углах, этот изумительный md5 хеш будет выкинут и вместо него будет взят следующий), и, главное, проверяет, что такого адреса в сети нет. Для этого используется штатный механизм DAD (см ниже). Если всё ок, то на интерфейс назначается новосгенерированный случайный адрес, и именно он используется для общения с узлами Интернета. Хотя наш ноутбук с тем же успехом ответит на пинг и по основному адресу.

Этот адрес периодически меняется и он же меняется при подключении к другим IPv6-сетям (и много вы таких знаете в городе?.. вздох). В любом случае, даже если мы намертво обсыпаны куками и отпечатками всех браузеров, всё-таки маленький кусочек сохраняемой приватности — это лучше, чем не сохраняемый кусочек.

Последняя практически важная фича IPv6 — это DAD. Во времена IPv4 на вопрос «а что делать, если адрес, назначаемый на хост, уже кем-то используется в сети» отвечали «а вы не используйте адреса повторно и всё будет хорошо».

На самом деле все вендоры реализовывали свою версию защиты от повторяющегося адреса, но работало это плохо. В частности, линукс пишет о конфликте IPv4 адресов в dmesg, Windows — в syslog… Event… Короче, забыл. В собственную версию журнала и показывает жёлтенко-тревожненький попапик в трее, мол, бида-бида. Однако, это не мешает использовать дублирующийся адрес, если он назначен статикой, и приводит к головоломным проблемам в районе ARP и времени его протухания (выглядит это так: с одного компьютера по сети по заданному адресу отвечает сервер, а с другого, по тому же адресу, допустим, залётный ноутбук, и они ролями периодически меняются).

Многие DHCP-сервера (циски, например), даже имели специальную опцию «проверять пингом» перед выдачей адреса.

Но всё это были доморощенные костыли для подпирания «а вы не нажимайте, больно и не будет».

В IPv6 проблему решили куда более изящно. При назначении IPv6 адреса запускается прописаный в RFC алгоритм (то есть выполняемый всеми, а не только premium grade enterprise ready cost saving proprietary solution за -цать тысяч). Этот алгоритм называется Optimistic DAD (RFC 4429), и его суть сводится к простому: кто первый встал, того и тапки. Включая прилагающийся IPv6 адрес.

Сам DAD работает отлично, но у него есть мааааленькая подлость, с которой я как-то столкнулся. Если (дополнительный) адрес на интерфейс вешать простым ip -6 address add, то ip отработает раньше, чем закончится DAD. Так что если этот адрес используется дальше в скрипте или конфигах автостартующих демонов, то демоны могут отвалиться по причине «нет такого адреса» — линукс не экспортирует в список доступных для приложений те адреса, про которые нет уверенности, что их можно использовать.

Эту часть большинство пропустит не читая, ну, такова судьба конфигов — быть писанными, но не читанными.

/etc/network/interfaces:

auto lo eth3 eth4 iface lo inet loopback allow-hotplug eth3 eth4 iface eth3 inet static address 95.161.2.76 netmask 255.255.255.0 gateway 95.161.2.1 dns-nameservers 127.0.0.1 #У меня локальный ресолвер на базе bind'а iface eth3 inet6 static address 2a00:11d8:1201:0:962b:18:e716:fb97/128 dns-nameservers ::1 iface eth4 inet static address 10.13.77.1 netmask 255.255.255.0 iface eth4 inet6 static address 2a00:11d8:1201:32b0::1/64 /etc/sysctl.d/ra2.conf net.ipv6.conf.eth3.accept_ra=2 /etc/sysctl.d/ip_forwarding.conf net.ipv4.conf.all.forwarding = 1 net.ipv6.conf.all.forwarding = 1 /etc/radvd.conf interface eth4 { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; prefix 2a00:11d8:1201:32b0::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; RDNSS 2001:4860:4860::8888 2001:4860:4860::8844 { }; }; /etc/dhcp/dhcpd.conf ddns-update-style none; option domain-name "example.org"; option domain-name-servers ns1.example.org, ns2.example.org; default-lease-time 600; max-lease-time 7200; log-facility local7; subnet 10.13.77.0 netmask 255.255.255.0 { range 10.13.77.160 10.13.77.199; option routers 10.13.77.1; option domain-name-servers 10.13.77.1; } У меня обычный домашний компьютер. Чуть-чуть raid, LVM XFS, BTRFS, LUCKS, свой почтовый и веб-сервера, dns-сервер и т.д. Я подключен к обычному домашнему провайдеру с IPv6.

Вот статистика использования интернета за четыре дня. Собиралась она простым способом:

iptables -t filter -A INPUT ip6tables -t filter -A INPUT (смотреть счётчики - iptables -L -v, и ip6tables -L -v)

И вот какая она получилась:

  • 4.5% (2.7 Гб) IPv6
  • 95.5% (59 Гб) — представители прочих, устаревающих, версий IP
Таким образом, IPv6 занимает второе место по распространённости в Интернете (если Майкрософту с виндофонами так желтить можно, почему мне нельзя?).

Если серьёзно, то столь значительные достижения IPv6 (только представьте себе — почти гигабайт трафика в день) большей частью объясняются ютубом и прочими сервисами гугла. Ещё небольшую долю IPv6 принёс пиринг, причём там львиная доля людей — это всякие туннели и teredo (то есть ненастоящие IPv6, использующиеся от безысходности).

С другой стороны, этот показатель почти в три раза больше моего прошлого замера (полтора года назад), когда доля IPv6 едва-едва переваливала за полтора процента.

Десктопные линуксы, понятно, IPv6 поддерживают и используют. Андроиды (4+) тоже умеют и используют. Пока что найдена только одна забавная бага, это неответ на пинги по IPv6 (но ответ по IPv4) в deep sleep режимах. Насколько я знаю, IOS'ы IPv6 поддерживают и используют.

habr.com

IPv6 не нужен? / Хабр

Недавно прочитал заметку, смысл которой сводится к тому, что не мешало бы проверить, вдруг вы уже используете IPv6 и ничего не замечаете. Следствием этого, на мой взгляд, является другой смысл, что для подавляющего большинства IPv6 ничего нового не принесёт: сайты будут так же открываться, а телефоны так же звонить.

Последнее время IPv6 перестал быть новым, возможно это относится только к моей среде общения, но говорить об IPv6 как о новом протоколе — перестали. Читать о том как здорово поднимать туннели ради доступа к заветному и недоступному уже совсем неинтересно. IPv6 стал одним из… Казалось бы, наконец-то, можно кричать «Ура!», но став одним из, он потерял драйвер роста, превратившись в заурядный. Доказать потребителю что ему надо именно это стало сложнее, потребитель не готов платить за один из…

Под катом продолжение истории, о том, как мы купили билеты на поезд IPv6 и остались на перроне, в общем смысле история провала, надеюсь, не окончательного. Это именно история, как работает IPv6, я думаю, уже все знают, минимум технических деталей и настроек, максимум личных впечатлений. Примерно чуть больше года назад было решено отдать IPv6 нашим абонентам. После первых экспериментов прошло достаточно времени, мы смотрели на график Google и хотели не опоздать. Абоненты для нас это пользователи услуг регионального провайдера интернет, классический tirple play: доступ к интернет (без PPPoE и VPN), телевидение (мультикаст) и телефония. Предпосылки, если ссылаться на приведённый график очевидны — туннельные протоколы почти ушли, родного контента стало больше, все большие сайты и хостинги включили IPv6 по умолчанию, магистральные операторы не берут дополнительную плату за dualstack адрес на стыках. Фактически пользоваться интернет в IPv6 стало можно, а быть первым в регионе и перетащить к себе под крыло ещё чуть-чуть абонентов — заманчивая идея.

Начало

Сначала получили адреса с префиксом /32, совершенно свободно обычным для провайдера способом через RIPE или LIR. Предполагалось, что на время тестов хватит и /48, но потом во время проектирования стало понятно, что /32 самый раз.

С аплинками было чуть посложнее (сейчас, наверное, уже нет), но такой магистральный провайдер нашёлся, подняли BGP в IPv6 обменялись префиксами. На текущий момент BGP fullview в IPv6 порядка 22000 префиксов, что очень мало если сравнивать с IPv4 где их больше 500000. Нашёлся даже пиринг партнёр, который был не против поднять с нами IPv6 сессию.

Если вы строите сети хотя бы пять лет, у вас должно было смениться пару поколений устройств, если вы строите сети больше 10 лет, даже используя одного вендора, в сети должен был образоваться некоторый сумбур из устройств, которые исправно работают, но которые совершенно не подходят под новые реалии. Определённо было известно, что если на маршрутизаторе не заявлена поддержка IPv6, то IPv6 там не будет, никакого подвоха от коммутаторов мы не ожидали. Предполагаемая зона охвата на чистом IPv6 составляла примерно 30%, без замены оборудования.

Абонентские оконечные устройства. Здесь как оказалось совершенно неизведанная территория. Если с операционными системами всё более или менее ясно, то с домашними маршрутизаторами кто во что горазд. Решено было разбираться по ходу дела, главным казалось, настроить магистральную сеть.

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

Проект

Если на секунду покажется что /32 это много, следует отогнать от себя эти мысли — /32 это впритык. С таким количеством адресов появляется соблазн сделать всё правильно и структурно и на всю жизнь:
  • /60 — абоненту. Можно и /64, конечно, но /60 это же навсегда, и не надо будет что-то отдельно придумывать для тех кому надо будет побольше;
  • /52 — на узел, из расчёта 256 абонентов;
  • /40 — на район, из расчёта 4096 узлов, по количеству виланов на устройство;
  • остальное это районы, максимум 256 минус служебные сети.
Итого 256*4096*256 = 2^28 ~ около 268 миллионов абонентов у каждого из которых, ну очень много адресов. С этим всё в порядке.

Так как изначально было очевидно, что всем не получится отдать родной IPv6, то тем, кому не повезло, IPv6 решено было отдавать в туннелях. Хотелось чтобы всё происходило автоматически без дополнительной настройки. Идеальным вариантом мог бы стать teredo, но у него не было поддержки наших IPv6 адресов, только зарезервированный диапазон. Это касается и 6to4, реализация которого подразумевает наличие публичного IPv4 на интерфейсе. Поэтому основным туннельным протоколом был выбран чистый туннель, как в туннельных брокерах. Пусть это и требовало некоторой настройки, но однократной, и поддержка на устройствах была гораздо шире.

Реализация

Магистральные маршрутизаторы. Тут почти всё хорошо. Всё, что новее 5-ти лет и заявлено как маршрутизатор, или если это L3 коммутатор не самый младший в линейке, имеет поддержку IPv6. В разной степени проработанности, но базовые функции OSPFv3, ACL, ND, DHCPv6 включая snooping, диагностические утилиты, обычно присутствуют.

Конечно, некоторые устройства подвержены детским болезням:

  • Повышенная нагрузка на CPU (особенно это касается OSPFv3), хотя IPv6 как раз и должен был решить проблему недостатка вычислительной мощности;
  • Некоторые производители придумывают совершенно жуткие синтаксические конструкции, чтобы вписать настройку IPv6 в существующий интерфейс;
  • Базовые команды диагностики не всегда корректно работают. Даже попытка проверить что-то ping может завершиться печально.
Но это всё проходит и починится в ближайшее время, как я думаю. Единственно чего вдруг не стало хватать это wildcard mask, иногда было бы полезно, но такого не будет никогда — IPv6 другой протокол.

Коммутаторы удивили своим избирательным подходом. Возможно, если вы не используете мультикаст в своей сети и различные варианты его фильтрации, то всё будет хорошо. Но если используете, то с большой вероятностью мультикаст трафик IPv6 зафильтруется как неизвестный. Поэтому для коммутаторов также надо явно смотреть поддержку IPv6, чтобы не было сюрпризов. Зона охвата после этого открытия немного уменьшилась.

Туннели. Как ни странно, самое простое и самое эффективное решение. Поднятие серверов и настройка не отняла много времени. Поднимаем sit интерфейс и запоминаем маршруты на подключенных абонентов через него. Был написан интерфейс для абонентов позволяющий понять, пользуетесь ли вы туннелем, и если нет, что надо сделать, чтобы его настроить.

Дополнительно подняли teredo relay на miredo. Teredo сам по себе очень интересный протокол, даже если у вас только IPv6 сеть, но вы не забываете об обделённых вынужденных пользоваться teredo, поднятие teredo relay в вашей сети очень сильно улучшит им жизнь. Раз в 10, если судить по пингам. Конечно, это касается только ваших серверов, никакого транзитного трафика бежать через ваш релей не будет.

Устройства абонентов повели себя по-разному. Фактически Windows и Linux не принесли сюрпризов. В разных системах и версиях имеются разные приоритеты для IPv6, где-то на первом плане DHCPv6, где-то, даже если все адреса IPv6 получены, всё равно работаем через IPv4. Так как IPv4 выключать не собирались, то здесь решено было действовать по факту, если не работает чиним. Многие роутеры в свою очередь порадовали наличием возможности включения механизмов туннелирования и также достаточно умным поведением, даже без запроса DHCPv6-PD они смогли распределить выделенный им префикс /64 на свою локальную сеть.

А вот железный полисер нас подвёл. При всём своём авторитете марки и расписанном функционале, не смог переварить наши требования, просто отказался применять новые адреса. Но не всегда, а через раз, как бы я могу как и обещал, но не буду. Поэтому временно была пересмотрена стратегия выделения адреса, только /64 на абонента.

Заработало

Когда были готовы настройки магистральных узлов и серверы туннелей, мы разрешили абонентам пользоваться IPv6. Разрешили пользоваться, но самим абонентам не сказали. Таким образом у кого устройства были настроены на автоматическое получение IPv6 (все современные ОС), те должны были получить адреса и начать использовать новый протокол по назначению. Для всех тех, кто каким-то образом узнал об IPv6, но не смог настроить нативно, тем предлагалось перейти на сервер туннелей для настройки.

Так работало 3 месяца, за которые:

  • Нативный трафик IPv6 линейно рос и добрался примерно до отметки 1-2% от общего трафика;
  • Структурно: в основном web и видео через web, никакого торрента;
  • Количество абонентов тоже линейно росло до примерно такой же величины;
  • На сервере туннелей зарегистрировалось порядка 1000 абонентов, которые генерировали трафик сравнимый с нативным;
  • Даже трафик через teredo relay составил 50 Кбит/c.
А потом мы всем сказали что у нас есть IPv6. И вместо ожидаемого перехода к взрывному росту показателей, получили довольно странную картину. К нам стали звонить абоненты и просить им всё настроить не понимая зачем это надо, совсем не понимая, вообще. А мы внезапно для себя не смогли объяснить:
  • Много адресов. В среднем активных устройств на абонента, которым требуется доступ в интернет 2-3, может, побольше — гаджетомания побеждает. Но даже сейчас это покрывается с лихвой частным адресным пространством без IPv6. Хоть каждому абоненту до 2^24, хотя на всех абонентов 2^24 — сейчас этого более чем достаточно;
  • Каждый адрес публичный. Сейчас у нас все адреса при доступе к интернет получают уникальный публичный адрес через NAT. Да через NAT, но с точки зрения конечного абонента NAT как первичный фильтр очень хорош. IPv6 подставляет под удар каждое подключенное устройство;
  • IPv4 кончаются. Если перейти от NAT к PAT(NAPT) при мультиплексировании 1 к 2, экономия 2 раза — в два раза больше подключенных абонентов. Такое мультиплексирование незаметно вообще, никому, 1 к 10 более реальные значения. А для тех кому действительно нужны публичные адреса после такого перехода они легко найдутся. Это не отменяет того факта что IPv4 кончаются, но провайдеры с полностью понятной технологией NAT это заметят самые последние. Многие наверняка уже использую NAPT или уже cgNAT, но IPv4 ещё можно купить или арендовать, причём достаточно свободно. Цены выросли, список предложений сократился, но до ситуации «нету ничего» ещё минимум пару лет;
  • Автоматические настройки. Для провайдера stateless технологии ужасны, тотальный контроль залог успеха. Гигантское количество IPv6 адресов разных типов на одном интерфейсе, гигантские возможности потенциальной ошибки. Если не следить за адресами, большая часть сети превратится в ботнет и уже будет поздно что-то менять;
  • Multicast против Broadcast. Коммутаторам всё равно, даже иногда плохо, логика начинает сбоить при использовании различных фильтров. На сетевом уровне, вместо 192.168.0.255/24 такой же FF02::1, т.е. тоже всё равно.

Итого

Оставили работать только сервер туннелей, последняя регистрация на котором была 9 марта, через 7 месяцев как убрали новость об IPv6. Остальное выключили через пару дней после объявления, поняв что единственным результатом это больше звонков от тех кто хочет что-то сделать, но не знает зачем, и почти полную неготовность даже в ближайшей перспективе софтверной обвязки. Те, кто знал зачем, сделал это сам. Сейчас доделываем биллинг, обновляем прошивки и оборудование и приходим к понимаю что IPv6 такой же протокол как и IPv4, интернет к этому стал готов и поэтому сам по себе «новый» протокол стал неинтересен. Спешить никуда не надо. Ни один конкурент за это время не предложил ничего, хотя почти все зарезервировали себе IPv6 префиксы.

Для всех тех, кто думает что у его провайдера нет IPv6, попробуйте поискать — может быть, уже есть, просто вам это не нужно?

habr.com

IPv6 для домашних сетей / Хабр

В этой статье мы постараемся описать текущее состояние поддержки и варианты внедрения IPv6 в домашних сетях. Статья написана осенью 2012 года, вполне возможно, что уже через год она будет совершенно неактуальной, но всё-таки мы опишем статус IPv6 на сегодняшний день. Информация ориентирована в первую очередь на провайдеров домашних сетей, соответственно, под определение «провайдер» в данной статье магистралы не подпадают.

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

Из наиболее частых вопросов можно выделить: «А ваш биллинг поддерживает IPv6 адреса?». При этом ответ: «А всё ваше оборудование готово к его внедрению?» вызывает удивление: «А что там готовить надо?».

Не хочется заниматься переписыванием основ IPv6 из rfc (http://tools.ietf.org/html/rfc2460) или википедии (http://ru.wikipedia.org/wiki/Ipv6), поэтому на этот фундаментальный вопрос ответим двумя предложениями. IPv4 и IPv6 — это два разных протокола, совсем разных. Как, например, AppleTalk или IPX — совсем разные. Поэтому IPv6 — это не просто «другие адреса», это совершенно другой протокол.

Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет, протоколом заложены элементы маршрутизации уже в заголовке IPv6 пакета (http://tools.ietf.org/html/rfc3587), сети аггрегируются по умолчанию, IPv6 full-view не может превышать 8К префиксов. Соответственно, провайдерам прийдётся отвечать на волну вопросов абонентов: «А почему у меня нет 100М на UA-IX?».

Также, в настоящее время ни одна биллинговая система не поддерживает полноценное управление IPv6. Некоторые системы заявили о поддержке IPv6, но на практике эта «поддержка» представляет собой лишь модифицированное поле IP адреса. А по стандарту, конечному пользователю адрес не выделяется, конечному пользователю должна выделяться сеть, по старым рекомендациям — /48 сеть (http://tools.ietf.org/html/rfc6177), по новым рекомендациям RIPE — уже /56 сеть, т.е. 256 сетей по 18446744073709551616 адресов. Повторим — каждому абоненту. Ни один из известных биллингов в настоящее время не поддерживает данные стандарты.

Тем не менее, невозможность получить IPv4 адреса и неуклонное подорожание их аренды заставляет задумываться об использовании IPv6 протокола.

Мы рассмотрим два варианта внедрения IPv6: в Dual-Stack, и «чистого» IPv6.

Использование IPv6 в Dual-Stack

Dual-Stack — это параллельное использование IPv6 и IPv4. Пользователь получает оба варианта адресов. Очевидно, что выдавать реальный IPv4 адрес при этом никто не собирается, т.к. тогда смысла в IPv6 для провайдера нет, задача стоит экономить IPv4 адреса.

В настоящее время всё клиентское оборудование хорошо и качественно поддерживает получение адресов и маршрутов для обоих протоколов, со стороны пользователей Dual-Stack проблем не вызывает. Однако, со стороны провайдера всё несколько грустнее.

Начнём с коммутаторов доступа. Прекрасно показавшая себя связка dhcp snooping + opt82 имеется «из коробки» в IPv6 протоколе, только называется она opt37 (http://tools.ietf.org/html/rfc4649), но при этом сам коммутатор должен поддерживать IPv6 протокол, как минимум, уметь блокировать «чужие» RA, фильтровать ND, пр. Иначе ситуация будет подобна сети с DHCP на «тупых» свичах, где адреса раздаёт любой клиентский роутерчик.

На сегодняшний день подобная поддержка IPv6 известна только у последних D-Link, начиная с DES-3200, и более экстремальных вариантах типа коммутаторов SNR от уважаемого nag.ru, приобретая которые провайдер за собственные деньги подписывается в вечные бета-тестеры глюков прошивок. Но, надо отдать должное DCN (http://www.dcnglobal.com): а это и SNR, и Edge-Core, и многие другие торговые марки, — покупая коммутаторы D-Link, тоже немало времени будет потрачено администраторами на бета-тестирование и отлов багов.

Также, нельзя не отметить, что тестирование работы необходимого IPv6 функционала под реальной нагрузкой особо не проводилось, у подавляющего большинства провайдеров IPv6 существует только в тестовом виде, так что рискнувший на внедрение IPv6 в эксплуатацию, вполне может стать первопроходцем на этом поле.

Использование же VPN (PPTP, PPPoE) для выдачи адресов, несомненно, уменьшает запросы к коммутаторам доступа, однако увеличивает объём негатива среди абонентов.

Итого: в настоящее время поддержка необходимых функций защиты IPv6 сети имеется лишь у незначительного количества новых моделей коммутаторов «нестабильных» производителей.

Не лучше обстоят дела в центре сети. Мы не будем тщательно рассматривать вариант, где центром сети является сервер под FreeBSD/Linux, подобные сети обычно невелики, и имеющихся у них /22 или даже /23 IPv4 адресов с головой и надолго хватит на всех пользователей. Напомним только, что для FreeBSD dummynet пока ещё не научился использовать несколько ядер.

У «среднего» же провайдера в центре стоит какая-либо Cisco/Juniper/Extreme из среднего же диапазона оборудования. У нас для тестирования имелась Cisco 3750G, что является достаточно распространённым решением среди подобного размера провайдеров. Включаем поддержку IPv6, и видим, что ресурсы урезало даже не пополам:

  • number of unicast mac addresses: 1.5K
  • number of IPv4 unicast routes: 2.75K
  • number of directly-connected IPv4 hosts: 1.5K
  • number of indirect IPv4 routes: 1.25K
  • number of directly-connected IPv6 addresses: 1.5K
  • number of indirect IPv6 unicast routes: 1.25K
Напомним цифры для IPv4:
  • number of unicast mac addresses: 3K
  • number of IPv4 unicast routes: 11K
  • number of directly-connected IPv4 hosts: 3K
  • number of indirect IPv4 routes: 8K
Полторы тысячи абонентов — это уже мало кому подходит, но максимум в 1200 роутов — это совсем катастрофа, в настоящее время даже небольшие русские точки обмена трафиком присылают по 2000 префиксов, не говоря уже о точках типа DTEL-IX, UA-IX, или, тем более, MSK-IX.

Но самая главная проблема заключается в том, что пользователей необходимо NAT-ить под реальный IPv4. В условиях «средней» сети это совсем непростая задача. Необходимость прогонять пару гигабит через сервера приведёт к низкому качеству трафика, высоким задержкам, жалобам и оттоку абонентов.

Получается, что при объёме трафика в несколько гигабит возвращаться к «софтовым» шейперам на базе FreeBSD/Linux/Mikrotik уже невозможно, а приобретать оборудование уровня Cisco ASR1000 — нереально дорого.

Да и что делать с самим IPv6 трафиком, тоже вопрос. Отдавать аплинку? Почти все аплинки отдельно тарифицируют транзит IPv6 трафика. Заворачивать у себя IPv6 to IPv4? Тогда использование IPv6 вообще не имеет смысла. Поднять туннельный пиринг с кем-либо типа Hurricane Electric (http://www.tunnelbroker.net/new_tunnel.php?type=bgp)? Во-первых, трафик пойдёт через «мир» (у кого есть подобное разделение), во-вторых, при достижении определённых лимитов, Hurricane Electric тоже начнёт брать деньги за транзит. Получается, что кроме увеличения накладных расходов, внедрение IPv6 ничего положительного не даст. Если уж всё равно использовать NAT, то можно просто NAT-ить серые IPv4 адреса, и всё. Пользователи не заметят разницы.

Итого: типичное для «среднего» провайдера оборудование либо совсем невозможно использовать для работы пользователей в Dual-Stack, либо же оно будет нагружено сильнее в несколько раз (отдельная маршрутизация плюс NAT).

Использование «чистого» IPv6

С учётом нецелесообразности развёртывания Dual-Stack в домашних сетях, у провайдеров возникает вполне логичный вопрос: «А что, если мы только один сегмент сети переведём на «чистый» IPv6, а остальные пусть работают, как раньше?». В теории подобная схема выглядит неплохо: поставить отдельную железку под IPv6, раздать пользователям IPv6 адреса, докупить у аплинков IPv6 транзит — и пусть себе работают. Рассмотрим подробнее, как обстоят дела с поддержкой «чистого» IPv6 в настоящее время.

В этот раз опустим анализ коммутаторов доступа — всё аналогично описанному в разделе про Dual-Stack, разве что необходимо отметить, что коммутаторы D-Link при получении IPv6 по автоконфигурации не видят предлагаемых роутов, так что надо быть готовым к тому, что default gateway необходимо будет прописывать вручную.

В качестве примера «центра» сети мы опять использовали оборудование Cisco, IOS версии 15.1. К «настоящей» cisco претензий нет никаких: IPv6 адреса и маршруты как по автоконфигурации, так и по DHCPv6 получает корректно; сама в роли роутера выступает корректно; вариантов работы с RA, ND и пр. множество, всё функционирует согласно документации; адреса раздаёт как по автоконфигурации, так и по DHCPv6 тоже корректно. Тут провайдеры домашних сетей могут только позавидовать магистралам, у которых проблем с запуском IPv6 особо и нет.

Перейдём к клиентскому оборудованию. Об этом писалось много раз, например, самим IETF (http://tools.ietf.org/html/rfc6586), однако надежда на то, что поддержка IPv6 активно развивается производителями, заставила пробежаться по основным вариантам пользовательских подключений. А именно, мы проверили работоспособность «чистого» IPv6 подключения для Wi-Fi роутера Cisco (Linksys), а также компьютеров под управлением Debian/Ubuntu, Mac OS X, Windows 7. Всё вышеперечисленное имело последние версии ПО/обновлений/патчей/прошивок.

Wi-Fi роутер. Для тестирования мы использовали достаточно новый роутер Cisco SB RV110W. Это роутер уже не имеет маркировки Linksys, он выпущен Cisco Small Business подразделением. Заявлена полная поддержка IPv6, как на WAN, так и на LAN порту. Действительно, в меню имеется выбор различных комбинаций IPv4 и IPv6 для этих портов. Мы выбрали «чистый» IPv6 для обоих, роутер перезагрузился, попытались подключиться. К wi-fi сети компьютер подключился, получил «серый» IPv6 адрес из диапазона fc00:: (http://tools.ietf.org/html/rfc4193), и мы смогли зайти в админку роутера, но не далее — доступа в интернет на компьютере не было. На роутере мы увидели следующую картину:

  • На WAN порту роутер корректно получил IPv6 адрес и маршруты, однако не подхватил DNS. Вручную прописанный DNS корректно заработал.
  • Даже при отключенной поддержке IPv4 роутер пытается его использовать, так, например, ping на 2a00:1450:400d:804::1009 работает, а вот ping на google.com говорит, что не может найти А запись. Тоже относится к NTP: в поле ввода сервера прописать IPv6 адрес можно, но роутер пытается отрезолвить его А запись, и засыпает лог соответствующими ошибками.
  • Роутер не умеет делать IPv6 NAT. Никак не удалось настроить выход в интернет из локалки с использованием «серых» адресов. Единственное решение — это в настройках DHCPv6 на роутере прописать реальную IPv6 сеть для LAN и прописать соответствующие маршруты в разделе IPv6 роутинга.
Итого: заявленная производителем поддержка IPv6 существует, однако для её настройки необходимы знания, на два-три порядка превышающие уровень среднего пользователя, при этом возможность удачной настройки по телефону саппортом провайдера представляется весьма маловероятной. С оборудованием же менее известных брендов, можно быть уверенным, дело обстоит как минимум не лучше.

Debian/Ubuntu. Тестирование производилось с последними версиями ПО: Debian Wheezy и Ubuntu 12.10. С учётом одинакового поведения, в дальнейшем мы их объединим под определением Debian. Здесь ситуация получше:

  • При инсталяции Debian корректно получает IPv6 адрес по автоконфигурации, маршруты и DNS работают корректно, однако при переполучении адреса теряются все маршруты, включая default gateway. Соответственно, доступ в интернет пропадает, что может привести к остановке инсталляции при коротком таймауте DHCP lease.
  • При запуске установленной системы IPv6 адрес и DNS Debian получает корректно как по автоконфигурации, так и по DHCPv6, однако default gateway упорно отсутсвует, его необходимо прописывать вручную. Радует только то, что в дальнейшем он не затирается при переполучении адреса.
Итого: с одной стороны, полноценной безглючной поддержки «чистого» IPv6 в Debian пока нет, с другой стороны, уже сам выбор Debian как ОС подразумевает умение пользователя без особых проблем прописать вручную маршрут на шлюз.

Mac OS X. Несмотря на то, что мы ожидали полную поддержку IPv6, по факту мы получили следующее:

  • IPv6 адрес и маршруты получает корректно как по автоконфигурации, так и по DHCPv6, однако DNS не подхватывается. При прописывании DNS вручную всё работает корректно.
  • Несмотря на то, что сеть полностью функционирует, для сетевых подключений выводится значок ошибки с восклицательным знаком. Чтобы его убрать, необходимо зайти в настройки сети, выбрать получение адреса вручную, и прописать любой IPv4 адрес.
Итого: полноценной безглючной поддержки «чистого» IPv6 в Mac OS X пока нет, а с учётом полного отсутствия знания данной ОС типичной поддержкой провайдера, можно ожидать негатив и снижение лояльности со стороны пользователей продукции Apple.

Windows 7. К нашему удивлению, данная ОС, которая «из коробки» организует поддержку IPv6 через Teredo (http://technet.microsoft.com/en-us/network/cc917486.aspx), показала следующие особенности использования IPv6 протокола:

  • IPv6 адрес получает как по автоконфигурации, так и по DHCPv6, однако маска устанавливается /48, вне зависимости от того, какую выдаёт сервер. Вспомним рекомендации RIPE о выдаче /56 сетей, получается, что в случае Windows автоматическая раздача адресов невозможна.
  • DNS не подхватывается. При прописывании DNS вручную его параметры сохраняются.
  • Предложенные маршруты в таблицу маршрутизации заносятся, но с приоритетом меньшим, чем туннели Teredo. Для того, чтобы заработало IPv6 подключение, необходимо остановить и отключить связанные с туннелями службы и настройки, из которых бОльшая часть требует прав администратора. Более того, часть операций возможно осуществить только (!) через командную строку, используя утилиту netsh.
  • Даже после упомянутых выше операций «чистая» IPv6 в данной ОС не функционирует, выводится значок ошибки «Подключение ограничено или отсутствует». Необходимо прописать любой IPv4 адрес, без шлюза и DNS, после чего IPv6 сеть начинает полноценно функционировать.
Итого: полноценной безглючной поддержки «чистого» IPv6 в Windows 7 нет, настроить IPv6 возможно, однако это требует знаний уровня среднего Windows-администратора, что в условиях домашней сети не представляется возможным.

Однако, даже если преодолеть технические трудности в получении и настройке IPv6 пользователем, то что ожидает его сегодня в этой «сети будущего»? К сожалению, его там не ожидает почти ничего. Пробежавшись по популярным сайтам, видим, что:

  • по IPv6 работают: google, youtube, facebook, vkontakte
  • по IPv6 не работают: skype, icq, yandex, odnoklassniki, steam, ex.ua и почти все остальные, включая новостные, развлекательные и игровые ресурсы.
Даже microsoft.com не имеет АААА записи. Да и остальные сервисы Microsoft лишены поддержки IPv6, поэтому, например, ОС установить и запустить возможно, а вот обновить её — уже нет. Кроме того перестанет работать Microsoft Security Essentials, который не сможет обновить сигнатуры.

Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.

Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива. Да и очевидно, что более 90% клиентского трафика будет уходить в IPv4 сеть, а вопросы необходимых мощностей для Dual-Stack рассматривались выше.

Итоги

Подводя итоги, можно сделать следующие выводы:

  • В настоящее время провайдерам домашних сетей протокол IPv6 можно рассматривать как вспомогательный, ожидать скорого перехода на IPv6 в мире не имеет смысла по причине не очень широкого наполнения IPv6 сети пользовательскими ресурсами.
  • Не представляется практически возможным развернуть «чистую» IPv6 сеть: ни оборудование доступа, ни абонентское оборудование не поддерживает полноценную сеть без IPv4 протокола.
  • Использование Dual-Stack не имеет смысла, т.к. представляет из себя всё тот же NAT, но отягощённый необходимостью обновить всё оборудование доступа и центра на поддерживающее IPv6, а также отдельно приобретать полосу для транзита IPv6 трафика.
  • Фактически в настоящее время использовать IPv6 сеть будут только сервисы google и торренты, остальной трафик будет уходить в IPv4. Вопрос: менять ли всё оборудование доступа ради улучшенной поддержки торрентов? — надо полагать, для провайдеров имеет только один ответ.

UPD: Приношу извинения andrewsh, что не заметили собранного им пакета tayga для Debian Wheezy.

habr.com

Пробуем IPv6 в домашней сети / Хабр

image

Давно хотел пощупать что это такое. Много новостей связанных с ipv6 мелькает в интернете. Близится всемирный день запуска, прошлогодний день тестирования я как-то пропустил. Да и вообще за ним будущее и я считаю лучше быть впереди чем потом догонять. А недавняя статья на хабре окончательно сподвигла меня изучить этот вопрос на собственном опыте.

Дано: домашний сервер-роутер на Ubuntu Server 11.10, стационарный компьютер и нетбук на Kubuntu 11.10 и мобильный телефон на Android. Теоретически всё это умеет ipv6, посмотрим что будет на практике.

Установку и настройку тоннеля через Hurricane Electric можно сделать по множеству инструкций в интернете, например по упомянутой выше статье. В итоге имеем: полностью настроенный сервер имеющий связь как с ipv4 так и ipv6. Устройства в сети получают префикс от radvd и сами настраивают себе адрес, но адрес DNS сервера приходится прописывать ручками и самое главное «но» — все устройства в сети переподключаются раз в 1-2 минуты, что на web-серфинге не сказывается, а вот аську тут же банят за слишком частые попытки подключения. Будем искать решение, а так же разбираться как это всё работает.

Попытаюсь пересказать принцип работы назначения адресов ipv6 человеческим языком:

Адреса link-local, которые хосты ipv6 сети сами себе назначают используя свой MAC адрес и стандартный префикс fe80::, это понятно и нам в данный момент не интересно.

Далее хост используя этот link-local адрес отправляет в сеть запрос в поисках роутера (Router Solicitation) и если роутер там есть то он отвечает (Router Advertisement), а вот тут есть два пути: 1. Если роутер просто роутер, то он присылает в ответ префикс сети. Далее хост сам себе назначает адрес используя этот префикс и свой MAC адрес и добавляет маршрут по умолчанию на этот роутер.2. А если роутер еще и DHCPv6 то запускается другой процесс назначения адреса, аналогичный DHCPv4.

На это влияет бит Managed Address Configuration Flag (M) в ответе Router Advertisement. Так же там есть бит Other Stateful Configuration Flag (O) который говорит нужно ли еще другие параметры получать, например маршруты, адрес DNS сервера, адрес NTP и т.д.

Radvd умеет только первый вариант, для всего остального нужен полноценный DHCPv6 сервер. В моей сети уже есть dnsmasq который занимается раздачей адресов и пересылкой dns запросов. Но к сожалению он не умеет ipv6. Или умеет? Самая свежая версия dnsmasq 2.60 умеет и Router Advertisement и DHCPv6. Отлично! В репозиториях Ubuntu свежей версии нет, только 2.59, качаем из репозитория Debian Unstable. Там добавляется одна новая зависимость, её можно поставить из родного репозитория.

sudo apt-get install libnetfilter-conntrack3 sudo dpkg -i dnsmasq-base_2.60-2_i386.deb Отключаем radvd, а лучше совсем удаляем. Читаем man и добавляем в конфиг /etc/dnsmasq.conf следующее:

enable-ra dhcp-range=2001:470:aaab:aaaa::2, 2001:470:aaab:aaaa:ffff:ffff:ffff:ffff, 64, 12h Можно конечно не всю /64 подсеть использовать, а поменьше, но пусть резвится, тем более алгоритм генерации адресов другой, более хитрый, а не подряд как в DHCPv4.

Перезапускаем dnsmasq, перезапускаем сеть на клиенте и вуаля, всё получили и адрес и маршрут и адрес DNS равный адресу роутера. Проверяем, всё работает, aaaa.test-ipv6.com открывается. DNS на роутере доступен по обоим v4 и v6 адресам. Отлично!

Берем в руки телефон с Android. Печаль. IPv6 он не получает. Выясняем что Android не умеет получать адрес от DHCPv6, совсем, никакой версии. Читаем man дальше и в конфиг dnsmasq.conf добавляем следующее: dhcp-range=2001:470:aaab:aaaa::, ra-only, 64, 12h Теперь наш dnsmasq отвечает двумя Router Advertisement один с установленными флагами M и O, а другой со сброшенными. Android телефон воспринимает только второй, а вот linux клиенты воспринимают оба, и по этому получают по два адреса. Но это не страшно, я считаю. Один из них dnsmasq запоминает (выданный DHCPv6) и можно получать доступ к клиентам по имени. А вот телефон, увы, получит только адрес, DNS он будет знать только с ipv4 именем (192.168.1.1). Кстати, теоретически существует конфигурация M=0, O=1, так называемая DHCPv6 stateless, когда адреса назначаются автоматически, а другие параметры получаются от DHCPv6, но я не уверен, что dnsmasq так умеет, Android такое примет, да и имена внутри сети не помешают. Есть ещё «костыль» RDNSS (Router Advertisement Options for DNS Configuration). Его умеет radvd на стороне сервера, а на клиентов нужно устанавливать rdnssd, в том числе и на Windows. Для Android всё равно не поможет, он его тоже не умеет.

Отключаем ipv4 и ищем где у нас проблемы с конфигами сервисов. Либо адреса заменяем на имена, либо к ipv4 адресам добавляем ipv6. Со стационарного компьютера все сервисы доступны по ipv6, а вот на нетбуке возникли проблемы. NFS шара монтируется с помощью autofs, а видимо в нем баг и он не разрешает имя сервера по ipv6. Если просто mount делать, то успешно монтируется. Возвращаем обычный интернет, ибо ipv6 пока скуден, google только поиск, википедия только через sixxs.net, несколько радиостанций, несколько трекеров. Ждем 6 июня.

Настройка фаервола ip6tables ничем не отличается от iptables, только отсутствует -t nat POSTROUTING. Ну и я себе добавил пропуск некоторых ICMPv6 пакетов внутрь, чтоб можно было пинговать снаружи.

Что мы получили? Готовность №1 к World IPv6 Launch домашней сети и бесценный опыт.

habr.com

IPv6 против IPv4: какая разница и что безопасней?

IP — это сокращенное название интернет-протокола. Устройства, подключенные к Интернету, обнаруживают друг друга и обмениваются между собой данными. Каждому устройству, подключенному через Интернет к компьютерам, смартфонам, серверам, автомобилям, интеллектуальным холодильникам, присваивается хотя бы один IP-адрес. IP-адрес идентифицирует устройство и его местоположение в любой точке мира. IPv6 — последняя версия этой технологии.

Для примера, представьте, что IP-адрес, это например, номер телефона. Он имеет код области, указывающий на общее местоположение. Телефонные номера обычно связаны с конкретными людьми или предприятиями, поэтому они являются надежным, но несовершенным способом идентификации кого-то.

IPv4 был создан в 1983 году, прежде чем интернет стал глобальной сетью, и все же он остается основным средством маршрутизации интернет-трафика между устройствами сегодня. Открытый IPv4-адрес, назначенный для любого устройства состоит из цифр, и выглядит примерно так:

192.168.0.101

Адрес IPv4 может быть любой комбинацией из 4-ех отдельных чисел от 0 до 254. Это четыре байта с общим диапазоном в 4,3 миллиарда возможных адресов.

Похоже, что это много, правда?

Но массовый всплеск устройств, выходящих в онлайн, исчерпал систему. У нас заканчиваются номера. В конце концов мы достигнем предела, который может испортить интернет и не позволит новым устройствам выходить в Интернет.

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

2001: db8 :: ff00: 42: 8329

Адрес IPv6 содержат по 128 бит, и они используют шестнадцатеричные цифры. Это означает, что вместо нуля до 10 (основание 10) они могут использовать от нуля до 10 плюс «а» до «F» (базовая цифра 16). Это дает нам огромный диапазон в 340 миллионов возможных комбинаций.

В ближайшее время нам не придется беспокоиться о том, что не хватит адресов IPv6.

Так почему бы нам просто не перейти на IPv6?

Процесс перехода был медленным. Узкое место в первую очередь связано с поставщиками интернет-услуг, а также с центрами обработки данных и конечными пользователями.

Управление IP-адресами осуществляется пятью глобальными реестрами — по одному для каждого континента / региона, которые раздают 16,8 миллиона адресов IPv4 за раз. В период с 2011 по 2015 год все, кроме одного из пяти реестров, исчерпали свои адреса верхнего уровня.

Для решения этой проблемы большинство интернет-провайдеров назначают пользователям динамические IP-адреса. Это означает, что ваш IP-адрес меняется периодически, каждый раз, когда вы подключаетесь к другой сети. Устройства, которые переходят в автономный режим, отказываются от своих IP-адресов, чтобы их могли использовать другие. В принципе, вы арендуете, но не владеете своим IP-адресом. Это значительно замедляет истощение адресов IPv4.

Переход происходит, но пока IPv4 и IPv6 работают одновременно. Стадия развертывания в разным странах разная. Около половины пользователей США уже используют IPv6.

Это самый большой фактор, сдерживающий развертывание IPv6. Требуется время и деньги для обновления всех серверов, маршрутизаторов и коммутаторов, которые так долго зависели исключительно от IPv4. Хотя большинство этих инфраструктурных устройств можно гипотетически модернизировать, многие компании предпочитают ждать, пока их нужно будет заменить. Этот процесс истощения замедлил ситуацию.

Что более надежнее IPv6 или IPv4?

Когда IPv6 был впервые запущен, компании требовали шифровать интернет-трафик с помощью IPSec, довольно популярного (но не так широко распространенного, как SSL) стандарта шифрования. Шифрование скремблирует содержимое интернет-трафика, поэтому любой, кто его перехватывает, не может его прочитать.

Но для того, чтобы привлечь больше компаний, это требование превратилось в более сильное предложение. Для шифрования и дешифрования данных требуются вычислительные ресурсы, для которых требуется больше денег. IPSec также может быть реализован на IPv4, что теоретически означает, что IPv6 в равной степени безопасен как IPv4. Вероятно, мы увидим увеличение использования IPSec в целом, по мере перехода, хотя это необходимо не всем потребителям.

Пока мы находимся на переходном этапе, некоторые эксперты утверждают, что пользователи IPv6 на самом деле более подвержены риску, чем те, кто придерживается IPv4. Некоторые интернет-провайдеры используют, в частности, технологии перехода — туннели IPv6, которые делают пользователей более уязвимыми для атаки.

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

Другая потенциальная проблема безопасности связана с новой функцией IPv6 — автоконфигурация. Это позволяет устройствам назначать себе IP-адреса без необходимости в сервере. Эти адреса генерируются с использованием уникального MAC-адреса устройства, который имеет каждый телефон, компьютер и роутер. Создается уникальный идентификатор, который сторонние пользователи могут использовать для отслеживания конкретных потребителей и определения их оборудования.

Что быстрее IPv6 или IPv4?

IPv6 не будет оказывать существенного влияния на скорость интернета по сравнению с IPv4.

При этом некоторые методы перехода, такие как туннели IPv6, создадут дополнительную задержку, когда запросы будут преобразованы в IPv4 и наоборот.

Есть ли еще отличия между IPv4 и IPv6?

Создание большего адресного пространства является основной целью IPv6, но также включает и некоторые другие отличия от IPv4. Большинство этих обновлений не будут вам интересны, если вы не являетесь сетевым администратором, но мы все равно перечислим их тут:

  • Многоадресная рассылка позволяет передавать один пакет нескольким адресатам в одной операции отправки.
  • Автоконфигурация позволяет устройствам автоматически настраивать свой IP-адрес и другие параметры без необходимости в сервере.
  • Безопасность сетевого уровня добавляет шифрование IPSec ко всем узлам, хотя это уже не строгое требование.
  • IPv6 будет работать лучше на мобильных устройствах, устраняя треугольную маршрутизацию.
  • Обработка, требуемая обработчиками запросов роутеров, намного эффективнее и упрощена.

Как IPv6 влияет на VPN?

К сожалению, почти все VPN работают исключительно на IPv4. Если вы отправляете запрос на веб-сайт, который по умолчанию соответствует IPv6-адресу, он будет разрешен с использованием DNS-сервера IPv6, который находится за пределами вашей VPN сети. Это называется утечкой IPv6, и оно может показать ваше истинное местоположение на сайте или приложении с привязкой к местоположению. Если веб-сайт настроен для обнаружения таких утечек, он может заблокировать вас от просмотра содержимого.

Как переключиться на IPv6?

Вы можете переключиться на IPv6, просто включив его на своем компьютере или смартфоне. Большинство новых устройств будут включены по умолчанию. Если нет, вы можете включить его в настройках.

Когда интернет-провайдеры, веб-компании и производители Wi-Fi-роутеров видят, что больше клиентов используют IPv6, они естественно отреагируют на изменение рынка.

Кстати, 6 июня — является ежегодным Всемирным днем ​​IPv6 .

routers.in.ua

Плавный переход сети компании на IPv6 / Хабр

Здравствуйте, хабрасообщество.

Хотелось бы осветить переход сети на IPv6, так как эта теме слабо освещена, тем более на русском языке. Сначала посмотрим на то, как выглядит наша сеть до перехода:

image Что мы имеем? Маршрутизатор, подключенный к сети интернет, выполняющий функции NAT для внутренних сетей. Сети находятся в vlan10 и vlan20.

Конфигурация маршрутизатора следующая:Router(config)#int fa0/0 Router(config-if)#ip address 192.0.2.2 255.255.255.252 Router(config-if)#ip nat outside Router(config)#int fa0/1.10 Router(config-if)#encapsulation dot1Q 10 Router(config-if)#ip address 192.168.1.1 255.255.255.0 Router(config-if)#ip nat inside Router(config)#int fa0/1.20 Router(config-if)#encapsulation dot1Q 20 Router(config-if)#ip address 192.168.2.1 255.255.255.0 Router(config-if)#ip nat inside Router(config)#ip nat pool natpool 192.0.2.2 192.0.2.2 netmask 255.255.255.252 Router(config)#ip nat inside source list 100 pool natpool overload Router(config)#ip access-list extended 100 Router(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any Router(config-ext-nacl)#permit ip 192.168.2.0 0.0.0.255 any

Для того, чтобы перейти на IPv6 – необходимо получить блок адресов. Переговоры с двумя провайдерами, к которым подключен офис компании, завершились не так, как хотелось бы – один провайдер тестирует IPv6 внутри своей сети и клиентам пока не выдает блоки, второй же еще даже не задумывался об использовании IPv6. Недолгие поиски привели на TunnelBroker от Hurricane Electric. Из предлогаемых возможностей после регистрации – до 5 блоков /64 или /48 (на выбор). Тем, кто еще не сталкивался с IPv6 довольно таки трудно представить себе сколько это адресов. Для сравнение – весь IPv4 блок – 232=4,2×109 адресов. В IPv6 блок /64 – это 264=1,8×1019 адресов. На 10 порядков больше, нежели весь блок IPv4.

Для получения блока IPv6-адресов необходимо заполнить одну форму, в которой указать внешний IPv4-адрес и выбрать один из серверов (на момент написания статьи всего 18 серверов – 3 в Азии, 6 в Европе и 9 в Северной Америке).

image

После получения блока вносим изменения на маршрутизатор. Включаем поддержку ipv6 маршрутизации:Router(config)#ipv6 unicast-routing Router(config)#ipv6 cef

Создаем тунельный интерфейс с провайдером-IPv6 (TunnelBroker):Router(config)#interface Tunnel0 Router(config-if)#description Hurricane Electric IPv6 Tunnel Broker Router(config-if)#no ip address Router(config-if)#ipv6 address 2001:470:18:11A::2/64 Router(config-if)#ipv6 enable Router(config-if)#tunnel source GigabitEthernet0/0.510 Router(config-if)#tunnel destination 216.218.221.6 Router(config-if)#tunnel mode ipv6ip

Добавляем маршрут по-умолчанию:Router(config)#ipv6 route ::/0 Tunnel0

Если на вашем маршрутизаторе настроен DNS, то можно уже насладиться работой через IPv6:Router#ping ipv6.google.com Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2A00:1450:4008:C00::6A, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/69/84 ms

На этом этапе у меня возник вопрос – как перенести старую адресацию, чтобы не пришлось запоминать для каждого компьютера по два IP адреса – IPv4 и IPv6. Выход есть. Для начала необходимо перевести IPv4 в hex, чем и займемся:192.168.1.0 → C0.A8.1.0 192.168.2.0 → C0.A8.2.0

Запишем в виде, более соответствующем IPv6: C0A8:0100 и C0A8:0200. Ведущие нули можно опускать, поэтому C0A8:100 и C0A8:200.

Наши сети 192.168.1.0 и 192.168.2.0 имели маску 255.255.255.0 (или более коротко — /24). Вспомним немного теории – маска /24 говорит о том, что начальные 24 бита не меняются в пределах сети, а могут меняться лишь оставшиеся 8 бит (IPv4 адрес состоит из 32 бит – 4 разряда по 8 бит). Нам необходимо сделать аналогичную маску для новой IPv6-сети, однако IPv6 адрес состоит из уже 128 бит. Последние 8 бит могут меняться, первые 120 бит – не могут. Маска: /120.

Когда мы определились с нужной маской – необходимо ввести старые сети в новый IPv6-блок. 192.168.1.0/24 → 2001:470:18:11A::C0A8:100/120 192.168.2.0/24 → 2001:470:18:11A::C0A8:200/120

Настраиваем маршрутизатор:Router(config)#int fa0/1.10 Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:470:18:11A::C0A8:101/120 Router(config)#int fa0/1.20 Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:470:18:11A::C0A8:201/120

Настройка маршрутизатора окончена.

Осталось на компьютерах включить поддержку IPv6, прописать адрес, маску и шлюз. Для примера настроим компьютер, с адресом 192.168.2.189:192.168.2.189 → C0.A8.2.BD → C0A8:2BD → 2001:470:18:11A::C0A8:2BD Маска: /120 Шлюз по-умолчанию: 2001:470:18:11A::C0A8:201

Отключаем Teredo (если включен):>netsh interface teredo set state disabled OK.

Проверяем работу через IPv6:>ping ipv6.google.com Обмен пакетами с ipv6.l.google.com [2a00:1450:4008:c00::6a] с 32 байтами данных: Ответ от 2a00:1450:4008:c00::6a: время=80мс Ответ от 2a00:1450:4008:c00::6a: время=65мс Ответ от 2a00:1450:4008:c00::6a: время=81мс Ответ от 2a00:1450:4008:c00::6a: время=76мс

Статистика Ping для 2a00:1450:4008:c00::6a: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 65мсек, Максимальное = 81 мсек, Среднее = 75 мсек

Вдобавок можно насладиться анимированой черепахой на www.kame.net (если у Вас черепаха не анимирована – значит Вы попали на сайт через IPv4).

Хотелось бы подвести итоги. Нет необходимости настраивать проброс портов, можно зайти с помощью ssh или удаленного рабочего стола на любой компьютер/сервер внутри локальной сети. Однако очень открыто стоит вопрос безопасности – понятие внутренней сети пропадает, теперь это часть интернета.

habrahabr.ru


Смотрите также