IPv6, не дожидаясь провайдера
Держу пари: немногие из читателей обратили внимание на то, что 8 июня 2011 г. прошел так называемый World IPv6 Day. В этот день многие сетевые операторы, интернет-провайдеры и владельцы сайтов перевели свои ресурсы в режим работы, предполагающий полноценную одновременную поддержку и привычного нам IPv4 (который мы до сих пор знали как просто IP), и нового IPv6. Отсутствие громких сообщений и широкого резонанса свидетельствует о том, что достаточно масштабный эксперимент завершился вполне удачно и в дальнейшем мы по-прежнему можем рассчитывать на гладкую работу Интернета. Отвлеченному человеку вышесказанное может показаться пустяком, но с World IPv6 Day действительно были связаны определенные переживания.
Прежде всего, давайте разберемся, что же именно в этот день произошло, и каким образом это касается (или нет) каждого из нас. Дело в том, что по сей день подавляющее большинство веб-сайтов доступны исключительно по протоколу IPv4, т. е. даже если их инфраструктура формально и поддерживает IPv6, то символьное имя разрешается DNS именно в IPv4. Для заведомого использования IPv6-ресурсов, как правило, нужно указывать специальные имена — к примеру, ipv6.google.com (хотя сама по себе комбинация символов «ipv6» ни о чем не говорит).
Рис. 1. Отсутствие доступа к Интернету по IPv6 пока еще не сулит никаких проблем, в каком-то смысле без него даже спокойнее. Однако постепенно уже стоит начинать разбираться с новым протоколом.
Так вот, 8 июня одни и те же имена сайтов участников (а это порядка 400 официально зарегистрированных крупнейших компаний и, наверняка, некоторое количество более мелких) разрешались как в IPv4, так и в IPv6 — в недалеком будущем именно таким образом будет функционировать весь Интернет. При этом надо иметь в виду, что все современные ОС не только поддерживают IPv6, но и отдают ему предпочтение как более прогрессивному, обращаясь к IPv4 лишь в случае неудачи. Соответственно, у тех, кто не заметил никаких проблем, либо IPv6 был настроен корректно, либо по старинке использовался только IPv4. Признаком неправильной конфигурации IPv6 на пользовательских компьютерах либо у провайдера должны были стать ощутимые задержки при обращении к некоторым сайтам, связанные с обработкой тайм-аутов, которые составляют порядка:
- 4 секунды для Mac OS X;
- 20 секунд для Windows;
- 0—180 секунд для Linux.
Причем если конкретный сайт доступен по нескольким IPv6-адресам, то задержка вырастает в соответствующее число раз. Как при этом поведут себя различные программы, предсказать довольно сложно. Но в любом случае, эта проблема не должна была стать массовой, эксперты оценивали долю возможных «потерпевших» всего в 0,05% от общей Интернет-аудитории, хотя, конечно, любому было бы неприятно попасть в их число. Поэтому участники World IPv6 Day больше заботились не о нас, а о собственной репутации: ведь для непосвященного ситуация выглядела бы так, будто их ресурс «лежит». Это, кстати, и есть основная причина, по которой никто не торопится обеспечивать доступ по IPv6.
Впрочем, определенная забота о простых смертных все же имела место. Та же Google, к примеру, еще в Chrome 11.0.696.71 ограничила таймауты при работе по IPv6 величиной всего 300 мс. В свою очередь, Microsoft выпустила специальный FixIt-апплет для тех пользователей Windows, у кого все-таки возникли бы проблемы с доступом к популярным Интернет-ресурсам; он просто делает приоритетным протокол IPv4.
С подобными проблемами, конечно, можно будет столкнуться и в будущем — крупнейшие интернет-компании настолько вдохновились успехами World IPv6 Day, что оставили часть второстепенных ресурсов функционировать в «экспериментальном» режиме. В качестве примеров — www.xbox.com или developers.facebook.com, а в дальнейшем таких сайтов будет становиться все больше.
Рис. 2. Сайт www.xbox.com отзывается и по IPv4, и по IPv6 — чтобы убедиться в этом, достаточно использовать в команде ping ключи -4 и -6 соответственно. Без ключей ping использует приоритетный протокол, которым по умолчанию является IPv6 — если он, конечно, активен.
Также специалисты опасались, что World IPv6 Day привлечет внимание хакеров, которые могут поставить собственный эксперимент — к примеру, попытаться атаковать какие-то узлы сетевой инфраструктуры. Аргументом служило то, что поддержка IPv6, особенно его новых возможностей, еще недостаточно отлажена и вполне может оказаться легко уязвимой. Но ведь хакеры находятся в аналогичном положении, им тоже нужно адаптировать свои инструменты и методы. Кроме того, с их стороны это был бы чисто «научный» эксперимент, так как пользователи все еще предпочитают не задумываться о IPv6: хотя у некоторых крупных сетевых операторов 8 июня IPv6-трафик удваивался (причем львиная доля его приходится на P2P), в абсолютных цифрах он все равно не поднялся выше доли процента. Так или иначе, но ни о каких инцидентах информации не поступало, хотя, опять же, исключить их в будущем нельзя.
Почему IPv6?
В этом месте у многих наверняка возникнет закономерный вопрос: зачем вообще внедрять IPv6, если без него все прекрасно работает, а с ним могут быть связаны различные проблемы? Однако ответ на него не менее очевиден для тех, кто хоть немного в курсе дела: адресов IPv4 очень мало, свободных практически не осталось — занимающаяся их распределением организация IANA (Internet Assigned Numbers Authority) раздала последние блоки еще 3 февраля 2011 г. Естественно, в распоряжении региональных интернет-регистраторов (RIR) какое-то количество адресов еще имеется, но предположительно через год по крайней мере один из них тоже останется с пустыми руками. Также свободные адреса имеются у локальных провайдеров и крупных организаций (вроде Google и Microsoft), которые в свое время запрашивали их с большим запасом. Последние даже нашли юридические лазейки, чтобы выкупать остатки друг у друга (хотя в принципе это не было предусмотрено). Но так или иначе — ясно одно: 30 лет назад создатели IPv4 слишком самонадеянно посчитали 4 миллиарда (232) достаточно большим числом.
Западные журналисты склонны излишне драматизировать сложившуюся ситуацию, называя ее не иначе как IPcalypse или ARPAgeddon (от названия организации ARPA, или Advanced Research Projects Agency, чья сеть ARPAnet была прообразом Интернета). На самом деле все не так страшно, особенно в ближайшей перспективе. Во-первых, World IPv6 Day подтвердил состоятельность идеи так называемого «двойного стека», подразумевающей длительное сосуществование протоколов IPv4 и IPv6, которое позволит постепенно решить все возникающие технические проблемы. Во-вторых, в нашем распоряжении имеется технология NAT, позволяющая прекрасным образом пользоваться «фиктивными» адресами.
Однако долгосрочная перспектива, если не приложить достаточных усилий, выглядит не такой уж радужной. После реального исчерпания IPv4-адресов новые ресурсы будут работать уже только по IPv6, так что никакой «двойной стек» сам по себе не поможет добраться до них по IPv4. Далее, масштабное внедрение NAT провайдерами и сетевыми операторами таит в себе целый ряд неприятных моментов — и ограничения в работе с P2P-системами на самом деле еще мелочь. Массовая трансляция адресов существенно увеличит нагрузку на сетевую инфраструктуру, а кроме того может вызвать неадекватные реакции со стороны систем безопасности, которым, к примеру, будет сложно отличить наплыв пользователей из-за NAT от настоящей DDoS-атаки.
Справиться с этими и подобными явлениями как раз и призван протокол IPv6: давайте разберемся, за счет чего.
Что нового в IPv6
Главная новость для конечных пользователей состоит в том, что IPv6 оперирует 128-битными адресами против 32-битных в IPv4. Типичный IPv6-адреc записывается шестнадцатеричными цифрами таким образом:
2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d
В каждой группе, отделенной двоеточиями, ведущие нули могут опускаться, а двойное двоеточие (которое может встречаться только один раз) обозначает последовательность нулевых групп, обеспечивающую корректную длину всего адреса. Т. е. нулевой адрес может выглядеть просто как «::». Хотя в общем случае пытаться запоминать такие конструкции практически бесполезно, их все же можно использовать — к примеру, в адресной строке современных браузеров, заключая в квадратные скобки.
Даже если не вдаваться в математические подсчеты, понятно, что количество IPv6-адресов измеряется в полном смысле астрономическим числом. На самом деле, на текущий момент бо́льшая часть адресного пространства, порядка 85%, зарезервирована на будущее (к примеру, если нынешняя система распределения окажется не совсем удачной, будет возможность быстро ее скорректировать), но все равно ясно, что оперировать каждым конкретным адресом невозможно — слишком велики будут таблицы маршрутизации. Поэтому система задумана иерархической: в частности, адреса будут распределяться подсетями /48, т. е. первые 48 бит формируют так называемый глобальный идентификатор (префикс), следующие 16 бит будут определять подсеть, а следующие 64 — интерфейсы. С одной стороны, это обеспечит все разумные и неразумные потребности, с другой — существенно упростит маршрутизацию. Понятно, что префикс длиной в 64 бита позволяет зашить довольно много информации — так, если глобальные («обычные») IPv6-адреса выделяются в диапазоне 2000::/3, то, забегая несколько вперед, 2001::/32 обозначают Teredo-адреса, а 2002::/16 — 6to4. Соответственно, с корректным выявлением и обработкой двух последних не должно возникнуть никаких проблем.
Кроме того, в IPv6 имеются так называемые «уникальные локальные» адреса (диапазон fc00::/7) — по сути, аналоги зарезервированных в IPv4 для организации NAT. Они автоматически выделяются каждому интерфейсу, причем специальный алгоритм генерирует их на основе MAC-адреса таким образом, чтобы с высокой вероятностью действительно обеспечить их уникальность. В частности, это свойство означает априори готовность любой локальной сети к работе по IPv6 без дополнительной настройки и даже без DHCP, что, к примеру, очень удобно для организации так называемых спонтанных (ad-hoc) сетей.
Как видите, IPv6 — вовсе не «расширенный IPv4», тем более что обратной совместимости между ними нет. Разрабатывать IPv6 (первоначально его называли IPng, IP next generation) начали еще в 1992 г., первые спецификации появились в 1996 г., и только в 2004 г. началось, по сути, его реальное использование — с добавления соответствующих DNS-записей (обычно их условно обозначают AAAA, против A для IPv4) для японского и корейского национальных доменов. Кстати, нет никакой тайны и в том, почему за IPv4 следует сразу IPv6 — номер 5 успели задействовать для еще одного экспериментального протокола, предназначавшегося для передачи аудио и видео.
Соответственно, IPv6, как более прогрессивный и созданный с пониманием реальных ограничений своего предшественника, содержит немало и функциональных улучшений, прежде всего в области маршрутизации. Кроме уже упоминавшейся иерархической системы сюда же можно отнести освобождение маршрутизаторов от разбиения пакетов (теперь этим должна заниматься передающая сторона, что при определенных обстоятельствах как раз и может стать одним из источников уязвимостей) и подсчета контрольных сумм (на уровне IP они просто исчезли за ненадобностью). При этом максимальный размер пакетов может достигать 4 ГБ (так называемые «джамбограммы»), что, впрочем, найдет применение только в каких-то специальных случаях — к примеру, в суперкомпьютерах. Появились также многоадресное вещание, новые возможности QoS (к примеру, специальное поле срочности доставки, что особенно пригодится при потоковой передаче аудио и видео), IPSec стал обязательным и пр.
Таким образом достоинства IPv6 очевидны. Исключив необходимость в NAT и упростив маршрутизацию на уровне корневой инфраструктуры, он должен обеспечить даже лучшую производительность Интернета, а выделение «белых» адресов любым сетевым устройствам (обычно в качестве примера приводятся холодильники, но более интересно выглядят всевозможные счетчики и сенсоры, которые благодаря автоконфигурации смогут легко объединяться в локальные сети) наверняка откроет какие-то совершенно новые возможности. При этом теоретически должна улучшиться и ситуация с безопасностью — «белые» адреса усложнят жизнь спамерам и владельцам ботнетов, сканировать адресное пространство IPv6 не в пример сложнее IPv4, да и обнаруживаться такая деятельность будет легко.
Откуда берутся проблемы с IPv6
Но раз все должно быть хорошо, то почему мы говорим о каких-то проблемах? Действительно, на сегодняшний день можно считать, что сам по себе Интернет (на уровне корневой инфраструктуры) к IPv6 вполне готов, и то же самое, скорее всего, можно сказать о крупных сетевых операторах. Гораздо хуже дело обстоит с провайдерами доступа — вот они совсем не торопятся: тех, что официально начали поддерживать IPv6 на просторах СНГ, можно пересчитать по пальцам. Хотя отчасти их можно понять — на самом деле мало кто из их абонентов может полноценно воспользоваться IPv6. Дело в том, что подавляющее большинство пользовательского оборудования (модемы, маршрутизаторы, беспроводные точки) IPv6 не поддерживают. Соответствующие устройства непросто найти даже среди новых моделей — что уж говорить о тех, что были выпущены несколько лет назад.
При этом не факт, что ситуацию можно исправить обновлением их микропрограмм. Во-первых, это серьезная работа, на которую решится не всякий производитель; во-вторых, это не всегда возможно в силу аппаратных ограничений; в-третьих, очевидно, что гораздо выгоднее продать нам новое устройство, чем с непонятным результатом возиться со старым. Кое-что, конечно, можно предпринять и самостоятельно. К примеру, популярная альтернативная микропрограмма для беспроводных маршрутизаторов DD-WRT поддерживает IPv6, и ею можно воспользоваться на свой страх и риск (хотя, как известно, делается это не всегда просто). Правда, мне не встречалась информация о том, насколько надежно она работает.
И все же, снова утешу читателей — не все плохо. Описанные выше проблемы ни для кого не тайна, и IPv6 содержит целый ряд стандартных механизмов для своего использования даже без поддержки со стороны провайдера. К тому же, все сравнительно современные ОС и значительная часть прикладного ПО прекрасно работают с IPv6.
Как приобщиться к IPv6
Итак, очевидно, что ситуация, когда и провайдер, и ваше оборудование поддерживают IPv6 — все еще редкость. Поэтому придется обратиться к дополнительным ухищрениям, благо о них предусмотрительно позаботились и сетевые операторы, и разработчики ПО. Все они построены на технологиях туннелирования, т. е. инкапсуляции IPv6-трафика в IPv4-пакеты, которые, соответственно, где-то и кем-то должны быть расшифрованы и переданы по назначению.
Все дальнейшее относится к Windows 7, в которой IPv6 по умолчанию включен. В Windows Vista отличий быть не должно, в Windows XP с последним сервис-пакетом IPv6 необходимо предварительно установить, к примеру, таким образом:
netsh interface ipv6 install
Эта и другие команды должны выполняться от имени администратора, в Windows 7 для этого проще всего запустить с административными полномочиями командную строку.
Вариант первый — 6to4. Использование возможно в том случае, если у компьютера статический «белый» IPv4-адрес. Это принципиально, так как именно на его основе должен быть сформирован уникальный глобальный IPv6-адрес. Для активации достаточно выполнить всего одну команду:
netsh int ipv6 6to4 set relay 192.88.99.1 enabled 1440
Здесь 192.88.99.1 представляет специальный широковещательный (anycast) адрес, посредством которого находятся шлюзы 6to4. Один из них, независимо от своего размещения (маловероятно, что у отечественного провайдера), и будет задействован в результате, и на него будет маршрутизироваться весь 6to4-трафик. Соответственно, возможны проблемы с производительностью, хотя, учитывая малую распространенность IPv6, ни о чем подобном пока не сообщалось.
На случай, если компьютер находится за NAT, имеется другой способ под названием Teredo (аналог в Linux и Mac OS X — Miredo). Он более универсален, но требует и дополнительной настройки. Прежде всего, в Windows 7 Teredo присутствует, но в основном предназначен для самостоятельного использования различными сетевыми приложениями. Поэтому, в частности, в отсутствие IPv6-трафика ОС его быстро деактивирует. Соответственно, вначале нужно изменить такое положение дел в редакторе групповых политик (gpedit.msc): найти в разделе Computer Configuration → Administrative Templates → Network → TCPIP Settings → IPv6 Transition Technologies параметр Teredo Default Qualified и установить его в значение Enabled.
Рис. 3. Во избежание недоразумений и дополнительных действий, Teredo лучше сразу сделать постоянно активным.
Затем нужно в сетевых настройках назначить явный IPv6-адрес, к примеру 2002:c0a8:102:: (это аналог 192.168.1.2; при желании другие можно вычислить здесь), и указать длину префикса подсети — 48.
Затем — выполнить команду
route print
и в разделе Interface List выяснить номер интерфейса Teredo. Допустим, он равен 21, тогда осталось выполнить последнюю команду
netsh interface ipv6 add route ::/0 interface=21
подождать несколько секунд и проверить работоспособность IPv6:
ping ipv6.google.com
В некоторых случаях, впрочем, и после этого Teredo остается неактивным, тогда его нужно активировать принудительно:
netsh int teredo set state type=client
netsh interface ipv6 delete route ::/0 interface=21
netsh interface ipv6 add route ::/0 interface=21
Если внешний IPv4 выделяется динамически, две последние команды придется повторять после каждого выключения/включения маршрутизатора/модема либо при каждой смене адреса (обычно раз в сутки), для чего лучше всего создать пакетный файл.
Также в зависимости от настроек вашего маршрутизатора в первой команде иногда нужно указать другой тип клиента:
netsh int teredo set state type=enterpriseclient
Вообще-то он предназначен для доменной среды, но, по не вполне ясным причинам, иногда требуется и в других ситуациях.
Teredo имеет ряд особенностей, о которых следует знать. Во-первых, его поддержку формируют два типа серверов: вспомогательные, которые нужны только на этапе конфигурирования (один из них развернут самой Microsoft), и шлюзы, обеспечивающие обращение к реальным IPv6-адресам путем расшифровки инкапсулированного трафика (взаимодействие между Teredo-адресами происходит напрямую). Соответственно, производительность может зависеть от загрузки последних. Во-вторых, надо иметь в виду, что Teredo позволяет принимать входящие соединения, что создает потенциальную брешь в защите. На текущий момент это вряд ли является большой угрозой, т. к. сканировать IPv6-адреса (а Teredo даже сложнее, чем реальные) бесперспективно, да и мало какие приложения «слушают» IPv6. Но в принципе стоит предусмотреть дополнительную защиту с помощью брандмауэра — Windows Firewall будет достаточно.
В некоторых случаях, однако, Teredo также не будет работать. Например, из-за симметричного NAT или в случае фильтрации UDP. Кроме того, Teredo позволяет задействовать только один IPv6-адрес, т. е. раздать с его помощью IPv6 в локальной сети не удастся. На эти случаи имеется еще один вариант — так называемые туннельные брокеры. Сегодня их уже немало, причем многие поддерживаются сетевыми операторами, т. е. предположительно с их производительностью не должно быть больших проблем. При этом данные услуги предоставляются бесплатно, хотя взамен от пользователя обычно требуется регистрация.
Одни брокеры предполагают определенную ручную настройку, другие предлагают специальные клиентские утилиты, выполняющие все необходимые действия автоматически, но принцип остается неизменным — необходимо соответствующим образом настроить оба конца туннеля. Каждый из вариантов имеет свои преимущества и недостатки. В первом на самом деле также не придется слишком вникать в подробности — скорее всего, всё, что понадобится, это выполнить на своем компьютере предложенный набор готовых команд. Однако имейте в виду, что эту процедуру придется повторять при каждой смене внешнего IPv4-адреса (к примеру, создав пакетный файл и назначив с помощью планировщика его запуск при каждом старте системы). Во втором почти наверняка придется установить дополнительный драйвер, который зато сможет достаточно интеллектуально выполнять автоконфигурирование при каждой перезагрузке.
В общем случае второй вариант кажется более простым и потому предпочтительным. В случае сервиса gogo6 он реализуется следующим способом:
- Чтобы скачать клиентское ПО, придется зарегистрироваться. Хотя, забегая вперед, в дальнейшем регистрационные данные не являются обязательными. Более того, gogoCLIENT вроде бы распространяется с некоторыми дистрибутивами Linux.
- Установка клиентского ПО проходит достаточно традиционно, поэтому англоязычный интерфейс не является большим ограничением. Как обычно, придется согласиться с лицензией и при необходимости выбрать инсталляционную папку.
Рис. 4. Инсталляционная процедура ориентирована на наиболее стандартное применение, так что вмешиваться в настройки нет необходимости
- По умолчанию для установки отмечены все необходимые компоненты, рекомендую так и оставить. Tunnel Driver необходим для «пробивания» NAT (а также для более экзотического и совершенно не актуального сегодня туннелирования IPv4 через IPv6).
- Драйвер подписан, но его установку все равно необходимо подтвердить.
Рис. 5. Сетевой драйвер будет делать за вас всю техническую работу.
- Перезагрузка не потребуется, можно автоматически запустить gogoCLIENT с последнего инсталляционного экрана.
Рис. 6. Как правило, нет необходимости вникать в настройки gogoCLIENT, не обязательно даже вводить свои регистрационные данные — достаточно нажать кнопку Connect
- Вкладки Basic достаточно в подавляющем большинстве случаев; она предполагает, что клиентское ПО самостоятельно выберет оптимальные параметры. Advanced и Log нужны разве что для экспериментов и решения проблем (с которыми мне столкнуться ни разу не довелось). Подключаться можно анонимно или со своими регистрационными данными. Во втором случае вы получите статический IPv6-адрес и возможность использования своего компьютера в качестве IPv6-маршрутизатора. Для обычного доступа к Интернету по IPv6 все это лишнее. Флажок «Launch the gogoCLIENT service at system startup» также следует оставить включенным, это обеспечит автоконфигурацию, необходимую, если IPv4-адрес вам назначается динамически.
Рис. 7. При желании можно поэкспериментировать с настройками — к примеру, чтобы добиться лучшей производительности соединения.
- Через несколько секунд после нажатия кнопки Connect связь с сервером gogo6 будет установлена и IPv6 активизирован (напомним, теперь при обращении к Интернету приоритет будет отдаваться именно ему).
Рис. 8. Вуаля! Все работает без малейших усилий с вашей стороны.
Проверка
На сегодня существуют множество ресурсов, позволяющих проверить корректность функционирования IPv6. Самое простое — зайти в любом современном браузере на сайт, заведомо доступный только по IPv6 — к примеру, на ipv6.google.com. Также несложно убедиться в приоритетности нового протокола:
ping www.xbox.com
При этом адрес должен разрешаться именно по IPv6.
На сайте www.kame.net вы должны увидеть «пляшущую» черепашку (в случае использования Teredo она обычно остается неподвижной).
Более подробную диагностику соединения можно выполнить на сайте test-ipv6.com:
Рис. 9. Полная готовность к использованию обоих протоколов.
Наконец, уже имеются и специальные ресурсы для проверки производительности IPv6-соединения, хотя туннелирование вносит слабо предсказуемые флуктуации. Speedtest на ipv6.wcclan.net слишком нестабилен и дает чересчур большой разброс результатов, но среднее значение скорости загрузки в моем случае составляет около 10 Мбит/с:
Рис. 10. К сожалению, адекватно провести тест в Интернете крайне сложно. К примеру, ipv6.wcclan.net как правило показывает для IPv6 пропускную способность, вдвое меньшую, чем она есть в реальности для IPv4.
Примерно такие же результаты и на другом ресурсе — ipv6-test.com/speedtest (скорость по IPv4 соответствует действительности):
Рис. 11. На ipv6-test.com картина похожая, лучший результат, которого удалось добиться в одном из повторов — потеря 25% пропускной способности по сравнению с IPv4. Вероятно, несколько улучшить ситуацию можно, поэкспериментировав с выбором сервера в gogoCLIENT.
Понятно, что потери производительности будут всегда — как минимум, они обусловлены накладными расходами на туннелирование пакетов. Однако значительную роль играют расположение и загрузка туннельного сервера, который можно явно выбирать на вкладке Advanced утилиты gogoCLIENT.
В заключение еще раз обращу внимание читателей на то, что туннелирование является потенциально опасной операцией и ее стоит использовать при включенном локальном брандмауэре, благо IPv6 поддерживают как Windows Firewall, так и многие сторонние продукты.
www.ixbt.com
IPv6 — он рядом. Часть 1 / Habr
Сегодня идет множество дискуссий насчет сроков по внедрению IPv6 везде и всюду. Но очевидно одно: без телодвижений крупных компаний ничего не выйдет. Google уже использует IPv6, существуют сети, которые предоставляют IPv6, в том числе некоммерческие.
В этом посте я хотел бы рассказать не только как приобщиться к миру IPv6, но и некоторые тонкости, связанные с ним, о которые мне пришлось споткнуться.
В данном случае рассматривается не самый тривиальный сценарий настройки, в котором используется домашний сервер и вы полностью распоряжаетесь выделенным вам адресным пространством.
Про нужность протокола IPv6, про нехватку адресов IPv4 писалось сотни раз. Я не буду сто первым, почитайте сами.
Дайте мне новые интернеты!
А кто их даст? — спросите вы? Но не все так плохо, так как существуют компании, которые предоставляют доступ к IPv6 совершенно бесплатно, через туннель поверх IPv4 соединения. То есть вы получаете «завернутый» трафик IPv6 по вашему существующему IPv4 соединению.- Hurricane Electric (у нее много сервисов, нас в первую очередь tunnelbroker.net)
- Freenet6 (удобно для тех, кто хочет «в один клик», также полезно для пользователей за NAT-ом)
- SixXS (тоже популярная сеть, но про нее ничего не знаю)
Прежде чем начать
Пусть у вас есть:1) Доступ в IPv4 интернет и статический белый IP адрес
2) Домашний сервер с установленным Linux (показано на примере Debian)
3) Клиентские машины (Windows, Linux, Mac — не важно)
Позже этот список будет расширен, но для минимальной конфигурации достаточен.
Регистрируетесь на TunnelBroker.net ничего заумного тут нет, но не кидайтесь сразу создавать туннель, успеете.
Выберите сервер, для этого в помощь Looking Glass, он вам попингует ваш сервер с серверов, предоставляющих туннели. Чем короче пинг — тем лучше, можно еще traceroute посмотреть и выбрать вариант с меньшим числом маршрутизаторов по пути.
Начнем
Теперь время настроить туннель и получить доступ к IPv6 на вашем домашнем сервере.Зарегистрируйте туннель. Для этого выберите Create Regular Tunnel в личном кабинете TunnelBroker, введите IPv4 адрес вашего сервера, укажите сервер, который вы выбрали.
Ваш конец будет сразу протестирован на получение пакетов с протоколом номер 41, доступность которого необходима для работы туннеля.
Обратите внимание, что для быстрого старта уже готовы примеры настроек для разных операционных систем (1 на скриншоте), ваш клиентский IPv6 адрес отличается (2 от 3) по префиксу от подсети Routed /64 одной цифрой, часто это не замечают. А также можете сразу заполнить rDNS (4) как на скриншоте, пока будет обновляться вы успеете настроить все остальное.
Проверьте работу туннеля. Для этого скопируйте конфигурацию для Linux-route2 и выполните в терминале из под root. Попробуйте ping6 ipv6.google.com, если заработало, поздравляю, туннель работает. Можно для достоверности попинговать ваш Client IPv6 address из Looking Glass (который использовали при выборе сервера).
Сделайте его статическим. В мире IPv6 навсегда отпала потребность в динамических адресах, поэтому значения, которые вы видели никогда не поменяются (если конечно у вас статический IPv4 адрес, да даже если сменится, то поменяется только Client IPv4 address).
Откройте в текстовом редакторе (например nano) файл /etc/network/interfaces (может быть другим, зависит от дистрибутива, но это так на Debian, Ubuntu и многих других)
Добавьте в конец файла описание нового интерфейса примерно так:
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:470:abcd:abcd::2
netmask 64
gateway 2001:470:abcd:abcd::1
endpoint 216.11.22.33
local 11.22.33.44
ttl 255
Назначение полей:
1) address — ваш Client IPv6 address
2) gateway — ваш Server IPv6 address
3) endpoint — ваш Server IPv4 address
4) local — ваш Client IPv6 address
Теперь при перезагрузке у вас туннель будет подниматься автоматически.
Но не спешите перезагружать сервер, так как туннель у вас запущен (когда вы его проверяли). Теперь нужно проверить такую вещь как MTU. MTU — это максимальный размер пакета, передаваемого над канальным уровнем модели OSI. В случае нашего туннеля этот размер совпадает с максимальным размером пакета IPv6 поверх туннеля. В силу того, что происходит инкапсуляция пакетов IPv6 в пакеты IPv4, к нему добавляются заголовки пакетов IPv4, следовательно MTU туннеля (максимум 1480) как минимум на 20 меньше MTU интерфейса, по которому вы выходите в интернет по IPv4 (как правило это 1500, но может быть меньше). Если у вас работает
Но вылетает с ошибкойping6 ipv6.google.com
wget -6 -O /dev/null http://he.netВычисляем MTU. Так как IPv4 пакеты можно фрагментировать, то есть если он слишком большой для передачи по какому-нибудь каналу, то он может быть порезан на кусочки. Однако к каждому такому куску добавляются заголовки и эффективность сильно снижается. А если пакет не влезает в интерфейс на сервере — то и вовсе работать не будет. Для вычисления MTU с учетом промежуточных узлов будем пинговать сервер нашего туннеля пакетами, которые фрагментировать нельзя.
Делается это так (где в конце должен стоять ваш Server IPv4 address):
ping -M do -s 1472 216.66.84.46 From 11.22.33.44 icmp_seq=1 Frag needed and DF set (mtu = 1488)Тогда пытайтесь уменьшить размер пакета до достижения успеха. Потом увеличивать его до тех пор, пока будет пинговаться.Исправляем MTU. Пусть у вас максимум при ping -M do -s 1464 … Тогда берем 1472 — 1464 = 8 потом 1480 — 8 = 1472 И так мы получили, что в этом случае ваш MTU туннеля должен быть равен 1472. Теперь идем обратно в Tunnel Details, вкладку Advanced и выбираем MTU не больший вашего, но ближайший к вашему. Перезапускаем туннель (либо опускаем, поднимаем интерфейс, либо перезагружаем систему). Проверяем снова:
wget -6 -O /dev/null http://he.netРаздача интернетов
Да, на сервере уже есть работающий IPv6, но мы же хотим предоставить его всем компьютерам в доме. Считается, что сервер находится в той же локальной домашней (офисной) сети, что и клиенты и в том же широковещательном домене Ethernet.Редактируем файл /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1sysctl -pУстанавливаем демон анонсирования подсети. Для этих целей (stateless autoconfiguration отличается от DHCPv6 тем, что адреса назначаются машинами самостоятельно в соответствии с MAC адресом, что хорошо в борьбе с ARP спуффингом) предназначен демон radvd (с DVD дисками не имеет ничего общего).
Установим его:
apt-get install radvd/etc/init.d/radvd stopНастраиваем radvd
. Тут все просто. Сначала найдите в Tunnel Details ваш префикс Routed /64.Редактируем файл /etc/radvd.conf
interface eth0
{
AdvSendAdvert on;
AdvLinkMTU 1480;
prefix 2001:470:abcd:abcd::/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Автоматическая настройка DNS не рассматривается, так как требуются дополнительные действия на всех клиентских машинах под Linux, а Windows вообще не поддерживает получение DNS через Router Advertisement, только через DHCPv6 (который весьма неудобен). Поэтому проще прописать на всех клиентских машинах DNS сервера Hurricane Electric (ваш Anycasted IPv6/IPv4 Caching Nameserver). В Windows это делается в параметрах сетевого подключения, в Linux редактируется файл /etc/resolv.conf
Настраиваем сетевой интерфейс
Находим в файле /etc/network/interfaces настройки интерфейса (смотрящего в локальную сеть), в моем случае eth0, которые выглядят примерно так:
allow-hotplug eth0
iface eth0 inet static
address 192.168.6.6
netmask 255.255.255.0
broadcast 192.168.6.255
allow-hotplug eth0
iface eth0 inet static
address 192.168.6.6
netmask 255.255.255.0
broadcast 192.168.6.255
iface eth0 inet6 static
address 2001:470:abcd:abcd::1
netmask 64
Для сиюминутного назначения адреса выполняем:
ip -6 addr add 2001:470:abcd:abcd::1/64 dev eth0Проверяем работу. Пришло время проверить свеженастроенную IPv6 сеть.
Запускаем radvd
/etc/init.d/radvd startНа клиентских машинах (мы же не забыли прописать DNS) открываем test-ipv6.com
Если у вас тоже все зеленькое — поздравляю! Вы приобщили свою сеть к миру IPv6.
Google, YouTube тоже должны работать через IPv6.
PROFIT !!!
Маленький бонус. Моя, например, подсеть размешена в Амстердаме, с пингами все хорошо. Но более высокая подсеть Hurricane Electric (2001:470::/32) зарегистрирована в США и все ее подсети распознаются как США вне зависимости от географии. Поэтому вы можете все сервисы Google, которые доступны только на территории США, не используя американский прокси и не жертвуя длиной пинга. Поэтому вместо абстрактной пользы мы имеет совершенно конкретные преимущества:- Глобальная доступность всех клиентов — прощай NAT
- Все думают, что вы американец
- Быстрее работают торренты, в основном за счет пиров с включенным Teredo
- Настраивая IPv6 сегодня, вы будете готовы к его наступлению завтра, а возможно сможете заработать на его настройке во время ажиотажа
- Выделенная подсеть — необъятный простор для извращений, причем бесплатный. Вам доступен rDNS, DNS неймсервер от того же Hurricane Electric, с поддержкой динамического DNS и с очень милым интерфейсом.
- Часть 2. Настройка фаервола. Борьба с NAT. Настройка конфигурации с несколькими серверами, объединение офисов. Настройка OpenVPN + IPv6, создание подсетей, Routed /48, Dualstack.
- Часть 3. Работа с DNS, rDNS. Размещение своих сервисов в IPv6, Native IPv6. Чем хорош и плох Native IPv6, предоставляемый хостерами. Собственный Native IPv6, как зарегистрировать сеть для своей фирмы, к чему подключить.
- Часть 4. Онлайн сертификация на навыки в области IPv6 от Hurricane Electric. Теория, необходимая для прохождения сертификации (step-by-step инструкции для читеров не ждите, хотя уже есть в интернетах). Будущее IPv6.
Будьте готовы к IPv6, его приход неизбежен.
habr.com
Скоро все сервисы Google будут доступны через IPv6 / Habr
Еще в январе, мы присоединились к Интернет Обществу и нескольким ведущим интернет-компаниям, чтобы объявить о Всемирном дне IPv6. Объявление станет призывом для принятия нового интернет-протокола. Менее чем через шесть месяцев, мы выросли до 400 организаций. Мы считаем, что IPv6 является единственным долгосрочным решением проблемы адресного истощения IPv4, и его развертывание имеет решающее значение для дальнейшего роста открытого интернета.Начиная с этого момента, на протяжении 24 часов, в полночь 8 июня (вторник днем в США, в среду утром в Азии), все участники общества включат поддержку IPv6 на своих сайтах. Для нас это будет означать практически все наши сервисы, включая Поиск, Gmail, YouTube и многое другое.
Вы даже не заметите перехода. У большинства (99,95%) людей будет доступ к сервисам без всяких проблем: либо они будут подключаться по протоколу IPv6, либо их системы будут успешно возвращены к IPv4. Однако, как и любая технология следующего поколения, может быть довольно болезненна при переходе. По нашим оценкам, 0.05% систем могут не вернуться к IPv4, так что для некоторых людей сайты Google, Facebook, Yahoo, Bing и другие могут открываться медленно или быть недоступными. Это может быть вызвано некорректно настроенным или неправильным сетевым оборудованием.
Последние несколько месяцев мы и другие игроки отрасли упорно готовились. Поставщики операционных систем и производители браузеров выпускали обновления для решения возможных проблем при, подключении по протоколу IPv6, например, Google Chrome теперь включает обходные пути для неисправностей в сети IPv6, и мы наблюдали за производителями маршрутизаторов которые проверяли свои устройства для надежной поддержки IPv6. Со своей стороны, мы много работали, добавляя поддержку IPv6 к услугам, которые еще его не имеют, и фиксировали с этим связанные незначительные проблемы. А так как лучший способ найти ошибки в своих услугах это «постучать по ним молотком самостоятельно», поэтому для сотрудников Google режим «Всемирный день IPv6» работает уже в течение нескольких месяцев.
Мы также думали о том, как лучше предупредить тех, у кого могут возникнуть проблемы. Поэтому мы сделали уведомления в поиске Google, направляя к тестовой страничке и справочной статье. Если вам интересно, вы можете проверить своё соединение на ipv6test.google.com.
habr.com
Cвой собственный IPv6 сервер брокер (6in4) / Habr
IPv6 шагает по планете, во многих странах поддерка IPv6 уже есть нативно от своего провайдера, если у вас еще нет IPv6 но вы хотите что бы у вас он был — вы сможете это сделать используя эту инструкцию.
Что важно — трафик мы будем пускать через свой собственный арендованный сервер, а не через непонятно какого брокера.
Для начала вам потребуется сервер который обладает IPv6 подключением, я буду использовать сервер от DigitalOcean за 5$ c OS Ubuntu последней версии.
Настраиваем сервер
Обратите внимание! часть ПО можно не устанавливать, оно отмечено как опциональное, его стоит установить, только если у вас динамический IP и вы хотите автоматически настраивать доступ при обновлении IP
После получения сервера вам надо обновить доступные пакеты на нем:
sudo apt-get update -y
sudo apt-get upgrade -yУстановить git, sipcalc, apache и php (2 последних — опционально)
sudo apt-get -y git sipcalcЕсли вы не планируете авто-настройку при смене IP адреса, данную команду можно пропустить.
sudo apt-get -y apache2 php libapache2-mod-php php-mcryptТеперь настала время скачать скрипт который поможет настроить туннель github.com/sskaje/6in4
git clone https://github.com/sskaje/6in4.gitcd 6in4Копируем скрипт в /bin для привычного нам вызова
sudo cp ./bin/6to4 /bin/6to4Выдаём права за на запуск
sudo chmod +x /bin/6to4Копируем файл настроек
sudo cp ./etc/config.ini /etc/config.iniРедактируем файл с настройками
ifconfig | grep 'inet6 addr:'
$ ifconfig | grep 'inet6 addr:'
inet6 addr: fe80::000:000:000:000/64 Scope:Link
inet6 addr: 2a03:000:0:000::00:0000/64 Scope:Global
Нам нужен тот который с препиской Global:
inet6 addr: 2a03:000:0:000::00:0000/64 Scope:Global
Открываем файл с настройками для редактирования:
sudo nano /etc/config.iniУбираем «;» у строчек:
IPV6_NETWORK=
IPV6_CIDR=
и указываем:
IPV6_NETWORK=2a03:000:0:000::
IPV6_CIDR=48
Нажимаем CNTRL+x, сохраняемся и переходим к добавлению сети:
sudo 6to4 add 1 8.8.8.8где 8.8.8.8 — ваш внешний IP, узнать его можно, например тут.
В ответ вы получите примерно это:
Please set up tunnel on your machine with following parameters:
Server IPv4 Address: 99.99.9.9
Server IPv6 Address: 2a03:000:0:000::1/64
Client IPv4 Address: 88.8.88.8
Client IPv6 Address: 2a03:000:0:000::2/64
Routed /64: 2a03:g0e0:00g0:3402::/64
Теперь осталось прописать данные настройки в вашем роутере
Пример ниже — настройка Apple Airport:
Другие роутеры настраиваются аналогично.
Настройка маршрутизации на сервере
Теперь вернемся к серверу и настроим маршрутизацию из виртуального интерфейса IPv6 — в основной:
sudo ip6tables -t nat -A POSTROUTING -s 22a03:g0e0:00g0:3402::/64 -o eth0 -j MASQUERADE2a03:g0e0:00g0:3402::/64 — это ваш Routed /64 или же любой IP который придет на любое ваше устройство с роутера после сохранения настроек
Разрешаем форвар трафика:
sudo sysctl -w net.ipv6.conf.all.forwarding=1Можно проверять
После этого, сохраните настройки на роутере, перезагрузите роутер. У вас должен был заработать IPv6. На подключенные устройства придут IPv6 адреса.
Проверить работу IPv6 можно тут — ipv6.google.com или ipv6-test.com
Обратите внимание — при смене IP адреса (внешнего), IPv6 у вас пропадет, обновления доступа после смены адреса будет рассмотрено в следующей статье (или же вы можете использовть инструкцию из репозитория github.com/sskaje/6in4)
После настройки IPv6 надо быть бдительным — все ваши устройства внутри вашей домашней сети получат публичный IPv6 адрес! если вы не уверены в защищенности устройств — включите блокировку входящих ipv6 подключений на вашем роутере.
PS Telegram/Youtube/Google сервера работают через IPv6 как и многие другие. Проверить это вы можете выполнив ping6 google.com
habr.com
Практика IPv6 — домашняя сеть / Habr
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:
- Адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128 мне выдан для компьютера/шлюза
- Сеть 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
Настройка публичных DNS-серверов Google в Windows / PROXY6.net
Причина, по которой пользователи чаще всего используют публичные DNS сервера — это обход примитивных блокировок сайтов провайдерами.DNS-сервера 8.8.8.8 и 8.8.4.4 — это публичные сервера DNS от Google (Google Public DNS) — альтернативные DNS-сервера с закрытым исходным кодом, которые разработаны и поддерживаются корпорацией Google. Помимо IP-адресов TCP/IPv4, публичные DNS-сервера Google имеют ещё и IPv6 адреса, которые в скором времени станут очень актуальными:
2001:4860:4860::8888
2001:4860:4860::8844
Давайте приступим к настройки:
1. Нажать «Пуск», выбрать пункт «Панель управления»:
2. В панели управления слева в разделе «Сеть и Интернет» кликнуть по ссылке «Просмотр состояния сети и задач»:
3. В открывшейся странице перейти по ссылке «Изменение параметров адаптера»:
4. На подключении, для которого вы хотите задать DNS, нажать правой кнопкой мыши. Выбрать пункт «Свойства»:
5. В списке компонентов найти пункт «Протокол Интернета версии 4 (TCP/IPv4)», кликнуть по нему один раз, а потом нажать на кнопку «Свойства», или кликнуть двойным кликом:
6. В открывшемся окне выбрать «Использовать следующие адреса DNS-серверов» и ввести в поля адреса 8.8.8.8 и 8.8.4.4 Нажать «OK» в этом окне и предыдущем:
После этого сразу начнут использоваться новые адреса DNS-серверов.
proxy6.net
IPv6 для домашних сетей / Habr
В этой статье мы постараемся описать текущее состояние поддержки и варианты внедрения 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