Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 54
Спасибо. Никак не могу собраться с силами прочитать правила и спецификации всей этот IPv6 кухни.
А тут доступно и с примерами.
Жду продолжений.
А тут доступно и с примерами.
Жду продолжений.
На здоровье! Продолжение уже скоро, плюс есть более далёкая цель — несколько заметок по безопасности для IPv6 — ради которой на самом деле всё это и затевалось.
Да, я тоже жду нетерпением заметку о безопасности!
Кстати, одна уже была: habrahabr.ru/post/233153/
Я тоже писал, но вряд ли мой пост можно назвать заметкой о безопасности
habrahabr.ru/post/225539/
habrahabr.ru/post/225539/
Совсем недавно была статья про угрозы и уязвимости IPv6
http://habrahabr.ru/company/xakep/blog/244383/
http://habrahabr.ru/company/xakep/blog/244383/
У меня на свежеустановленной 7 винде при пинге любого сайта выдавался ipv6 адрес.
При этом блокировки работали исправно. Отключил Ipv6 в настройках сетевого подключения, пинг стал выдавать обычный ipv4 адрес.
Пара вопросов:
1. Лучше отключить ipv6 или оставить?
2. Можно ли использовать ipv6 для обхода блокировок сайтов?
Провайдер банит по ip + самописный тормозной dpi.
При этом блокировки работали исправно. Отключил Ipv6 в настройках сетевого подключения, пинг стал выдавать обычный ipv4 адрес.
Пара вопросов:
1. Лучше отключить ipv6 или оставить?
2. Можно ли использовать ipv6 для обхода блокировок сайтов?
Провайдер банит по ip + самописный тормозной dpi.
Вопрос с предпочтением между IPv4 и IPv6 тонкий. В DNS у сайтов с IPv6 будут две записи — А и АААА, соответственно дальше уже ПО на компьютере решает, что использовать. Сейчас общая тенденция такая: либо IPv6 предпочитается, либо соединения отправляются одновременно, а там смотрим, кто ответил и кто быстрее.
По глобальным настройкам в Windows 7 есть вот такой KB. В частности там два «фиксика» — на приоритет IPv6 и наоборот IPv4.
По вопросам:
1. Общая рекомендация — если не используем, то отключаем, но это по соображениям безопасности. А так можете в те же торренты зайти и посмотреть, что там IPv6-пиры есть.
2. Для представителей Рос-трам-парам-надзоров — нельзя, и точка, и дальше читать не нужно. Для остальных — в IPv6 можно много чего, и в том числе многие ограничения не работают.
Могу посоветовать подключить себе домой IPv6-туннель, через того же Hurricane Electric — бесплатно и познавательно. Статьи где-то в округе были, но ссылки под рукой нет. Если будет нужно, могу и об этом написать.
По глобальным настройкам в Windows 7 есть вот такой KB. В частности там два «фиксика» — на приоритет IPv6 и наоборот IPv4.
По вопросам:
1. Общая рекомендация — если не используем, то отключаем, но это по соображениям безопасности. А так можете в те же торренты зайти и посмотреть, что там IPv6-пиры есть.
2. Для представителей Рос-трам-парам-надзоров — нельзя, и точка, и дальше читать не нужно. Для остальных — в IPv6 можно много чего, и в том числе многие ограничения не работают.
Могу посоветовать подключить себе домой IPv6-туннель, через того же Hurricane Electric — бесплатно и познавательно. Статьи где-то в округе были, но ссылки под рукой нет. Если будет нужно, могу и об этом написать.
Побочный эффект: возникает двусмысленность. Если мы говорим «Отправь пакет на FE80::101», то встречный вопрос будет «На который из интерфейсов?», потому что данный адрес может быть на любом из интерфейсов. Поэтому для link-local адресов обязательно уточняется интерфейс, который будет использоваться. В Windows используется записи вида FE80::1%5, где после символа "%" идёт ID интерфейса. В Linux применяется название (FE80::1%eth0).
Вот этот момент остаётся для меня не совсем понятным. Почему link-local адрес может быть на любом из интерфейсов? Он же генерируется на основе MAC адреса, а MAC у интерфейса, ведь, уникальный. И сразу понятно от какого интерфеса MAC и, соответственно, link-local адрес.
Я, похоже, упускаю что-то очевидное, но что? Можете пояснить этот момент?
MAC-адрес у интерфейса уникальный в пределах сегмента сети. В других сегментах такой же MAC может быть на любом устройстве.
Простой пример: ваш провайдер привязывается к MAC-адресам, а вы хотите поставить беспроводной роутер для раздачи трафика.
Способ 1: звоним в техподдержку, просим перепривязать.
Способ 2: заходим с компьютера на веб-интерфейс роутера, находим функцию «Clone MAC», делаем «тынц», и всё работает. На внешнем интерфейсе роутера будет такой же MAC, как у вашего компьютера.
Простой пример: ваш провайдер привязывается к MAC-адресам, а вы хотите поставить беспроводной роутер для раздачи трафика.
Способ 1: звоним в техподдержку, просим перепривязать.
Способ 2: заходим с компьютера на веб-интерфейс роутера, находим функцию «Clone MAC», делаем «тынц», и всё работает. На внешнем интерфейсе роутера будет такой же MAC, как у вашего компьютера.
А правильно ли я понимаю, что можно и руками поставить адрес? Приснопамятный FE80::1, к примеру? В этом случае у нас будет несколько LL-адресов на интерфейсе — автоматически созданные на основе MAC, и назначенные нами.
Сам себе отвечу — правильно, и это просто кайф:
user@grand:~$ ip -6 addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::211:76ff:fe21:325/64 scope link
valid_lft forever preferred_lft forever
user@grand:~$ ip -6 addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::1/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::211:76ff:fe21:325/64 scope link
valid_lft forever preferred_lft forever
Так. Допустим у меня в компьютере два сетевых интерфейса. Каждый из них подключен к своему L2 сегменту. В каждом отдельном L2 сегменте вполне могут существовать одинаковые link-local адреса. Следовательно, если я хочу попинговать узел, который находится в первом L2 сегменте я должен указать сетевой интерфейс к которому подключен этот L2 сегмент иначе возникает неопределённость.
Так, да?
Так, да?
Именно так. И если пишете, например, статический маршрут, то тоже обязательно указываете помимо link-local адреса ещё и интерфейс.
Вопрос даже не в возможных коллизиях адресов в разных сегментах. Неопределённость есть и без коллизий.
В таблице маршрутизации для всех интерфейсов с поднятым v6 есть запись про fe80::/64. Одинаковый префикс — выбрать исходящий интерфейс без подсказки невозможно.
В таблице маршрутизации для всех интерфейсов с поднятым v6 есть запись про fe80::/64. Одинаковый префикс — выбрать исходящий интерфейс без подсказки невозможно.
Тут на ipv4 с мультихомом проблемы зачастую (всё непрозрачно и через энное место).
Что ж на ipv6 будет O_O
Что ж на ipv6 будет O_O
Ну на IPv4 это выглядит, как чужеродная технология, а на IPv6 оно изначально так задумывалось. Думаю, все хорошо будет.
Не обязательно, но будем надеяться. Вообще в IPv6 на бумаге город-сад, развитой социализм и так далее. К сожалению, некоторые вещи на практике работают, а некоторые нет от слова «совсем».
В плане мультихоума как раз не всё гладко, потому что проблемы с ним фундаментальные. И в IPv6, если правильно помню, где-то до середины 2000-х была одна логика, а потом всё переосмыслили. Провайдеронезависимые (PI) адреса те же впихнули, хотя изначально планы были не допустить фрагментации адресного пространства как в IPv4.
В плане мультихоума как раз не всё гладко, потому что проблемы с ним фундаментальные. И в IPv6, если правильно помню, где-то до середины 2000-х была одна логика, а потом всё переосмыслили. Провайдеронезависимые (PI) адреса те же впихнули, хотя изначально планы были не допустить фрагментации адресного пространства как в IPv4.
Во-первых, с IPv4 можно прекрасно использовать кучу различных адресов на одном интерфейсе и PBR ни кто не отменял.
Во-вторых, IPv4 так же можно маршрутить через серые сетки (совсем не обязательно выделять 4 белые сетки под это дело), и более того, так оно и бывает в реальной жизни у некоторых провайдеров.
Во-вторых, IPv4 так же можно маршрутить через серые сетки (совсем не обязательно выделять 4 белые сетки под это дело), и более того, так оно и бывает в реальной жизни у некоторых провайдеров.
Абсолютно согласен, ну так ведь IPv6 к нам не из космоса прилетел. Просто в нём это «искаропки» и настраивается в полторы команды.
Перечитал и понял, что не понял глобально-уникального ;) смысла комментария.
Варианты трактования:
1) IPv6 не нужен. Безблагодатный холивор, и если так, то уточню — маркетингом IPv6 не занимаюсь. Цель статьи — рассказать про особенности и «странности» IPv6, а не давать ему оценки.
2) Тёртых спецов ничего не удивляет и не пугает. Ну да, на то они и специалисты. Чтобы не было обид со стороны специалистов, немного переписал вступление. С другой стороны, статья не совсем для них, потому что объясняются основы основ IPv6.
3) ???
Варианты трактования:
1) IPv6 не нужен. Безблагодатный холивор, и если так, то уточню — маркетингом IPv6 не занимаюсь. Цель статьи — рассказать про особенности и «странности» IPv6, а не давать ему оценки.
2) Тёртых спецов ничего не удивляет и не пугает. Ну да, на то они и специалисты. Чтобы не было обид со стороны специалистов, немного переписал вступление. С другой стороны, статья не совсем для них, потому что объясняются основы основ IPv6.
3) ???
)))
Смысл моего комментария в том, что не надо подавать материал в формате «IPv4 ни чего не умеет». Да, у IPv6 есть разные вкусности, но и IPv4 не пальцем деланный и прекрасно решает почти все возможные задачи.
Я сам за IPv6. На работе вот провайдер выдал нам блок /48, а мой домашний всё ещё не поддерживает, пришлось самому поднимать 6to4, благо белый IPv4 у меня есть. Так что в не любви к IPv6 меня обвинить нельзя.
Смысл моего комментария в том, что не надо подавать материал в формате «IPv4 ни чего не умеет». Да, у IPv6 есть разные вкусности, но и IPv4 не пальцем деланный и прекрасно решает почти все возможные задачи.
Я сам за IPv6. На работе вот провайдер выдал нам блок /48, а мой домашний всё ещё не поддерживает, пришлось самому поднимать 6to4, благо белый IPv4 у меня есть. Так что в не любви к IPv6 меня обвинить нельзя.
И заодно вопрос — как Вы собрались брать в IPv4 «сети» /31, это недорешение для экономии в PtP соединениях??? В таких ситуациях, обычно нарезают на сети /30.
Спасибо снова за цикл статей! Очень кстати, потому что разбираться самому времени нет, а инфы пока намного меньше, чем по в4…
Кстати, asch, что-нибудь слышно про Mobile IPv6 с Home agent? Это вообще где-нибудь работает, или хотя бы будет, или все так и останется на бумаге?
Скажу честно, что я это чудо тоже вживую не видел, пока только по диагонали просмотрел configuration guide. И кого спрашивал — тоже не видели. Но вопрос хороший, надо будет на досуге поразбираться.
Да-да, тоже очень хочется увидеть это вживую!
Читал описание вот здесь, но в рабочем состоянии так и не увидел.
Читал описание вот здесь, но в рабочем состоянии так и не увидел.
Что прикольно, для IPv4 тоже можно использовать link-local адреса в схеме как на картинке в п. 3. Настраивается и работает абсолютно так же, как для IPv6. Ведь маршрутизируемые пакеты не используют эти адреса (у них-то нормальные маршрутизируемые адреса), а на маршрутизаторах указание next hop используется только для определения интерфейса, через который выйдет пакет, и физического адреса следущего маршрутизатора — тут без разницы, link-local, глобально уникальные или приватные там будут адреса.
То есть, для IPv4 потребуется две сети — между компом и маршрутизатором, и между маршрутизатором и сервером. Остальные адреса будут локальными.
Только это не принято, считается, что нужно обязательно использовать там подсеть /30 и белые адреса (если речь об интернете).
То есть, для IPv4 потребуется две сети — между компом и маршрутизатором, и между маршрутизатором и сервером. Остальные адреса будут локальными.
Только это не принято, считается, что нужно обязательно использовать там подсеть /30 и белые адреса (если речь об интернете).
Раз пошла такая пьянка…
Ну во-первых, можно, да. Но в RFC по Link-local для IPv4 написано, если правильно помню, что не следует использовать эти адреса при наличии нормальных и допускается их использовать, если приспичило.
Во-вторых, берём две циски и делаем следующий трюк:
А ещё Деда Мороза не существует
Что касается приватных адресов, то да, можно, см. выше.
Ну во-первых, можно, да. Но в RFC по Link-local для IPv4 написано, если правильно помню, что не следует использовать эти адреса при наличии нормальных и допускается их использовать, если приспичило.
Во-вторых, берём две циски и делаем следующий трюк:
R1#ping 10.0.0.2 source 169.254.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 169.254.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#ping 169.254.0.1 source 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 169.254.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Что касается приватных адресов, то да, можно, см. выше.
Хорошо, что вы про циску вспомнили. Циска вообще не знает, что такое 169.254, она их маршрутизирует (проверял специально). У неё нет понятия ipv4 link-local. Это как бы намекает нам на то, что разработчики там клали на RFCшки.
Ну не шмогла отдельно взятая контора его осилить. Что вовсе не отменяет факта наличия стандарта и того, что никто не запрещал его применять другим вендорам, кто способен реализовать.
Ну не шмогла отдельно взятая контора его осилить. Что вовсе не отменяет факта наличия стандарта и того, что никто не запрещал его применять другим вендорам, кто способен реализовать.
Также узел может быть доступен одновременно сразу через двух провайдеров безо всяких BGP: по одному адресу через одного, по другому адресу — через второго.
Не совсем понял этот момент. Разве есть какие-то отличия от IPv4? Как в случае IPv4, так и в случае IPv6 нам нужно добавить правила маршрутизации (ip rule в Linux) и сделать несколько таблиц маршрутизации. Если этого не сделать, то пакет, пришедший с любого интерфейса, будет уходить через default gateway какого-то одного провайдера. Или я ошибаюсь?
Эффект примерно такой же, как и в случае двух провайдеров и сервера, который спрятан за NAT. Со стороны провайдера А он виден со своим префиксом, а со стороны провайдера Б — со своим. В зависимости от того, какой адрес выдаёт DNS — через такой линк клиент к вам и будет отправлять запрос.
Маршрутизация обратного трафика настраивается чуть проще, потому что в IPv6 для ответного трафика уже по адресу источника понятно, через какого из провайдеров отправлять. В случае с NAT тоже обходится: транслируем в разные приватные адреса или в разные порты.
Маршрутизация обратного трафика настраивается чуть проще, потому что в IPv6 для ответного трафика уже по адресу источника понятно, через какого из провайдеров отправлять. В случае с NAT тоже обходится: транслируем в разные приватные адреса или в разные порты.
Не понимаю вас.
Есть у нас сервер и два провайдера. Оба выдают по одной /64-подсети. Ставим какой-то default gateway (например, через первого провайдера). При запросе по IP второго провайдера, ответ пойдет через первого, т.к. он указан как default gateway.
Поведение не отличается от IPv4.
Я где-то заблуждаюсь?
Есть у нас сервер и два провайдера. Оба выдают по одной /64-подсети. Ставим какой-то default gateway (например, через первого провайдера). При запросе по IP второго провайдера, ответ пойдет через первого, т.к. он указан как default gateway.
Поведение не отличается от IPv4.
Я где-то заблуждаюсь?
Не совсем так. В теории было обновление RFC 3484, в котором, среди прочего, добавляется правило «Ходи через того, кто тебе дал этот префикс». Однако судя по дате (2011), ждать, что это работает здесь и сейчас, не приходится. Поэтому используем запасной вариант — PBR по адресу источника.
Есть ещё одна тонкость, что выдаваемый провайдером префикс в случае сбоя нужно старить (рекламировать с нулевым lifetime), и с этим тоже могут быть проблемы.
Есть ещё одна тонкость, что выдаваемый провайдером префикс в случае сбоя нужно старить (рекламировать с нулевым lifetime), и с этим тоже могут быть проблемы.
PBR по адресу источника
то есть, точно так же, как IPv4, как писал ValdikSS — в линуксе это ip rule from адрес-источника lookup таблица-с-соответствующим-nexthop
Нашёл более свежие RFC на данную тему, и… в общем, ваша правда, ValdikSS описал единственный работающий способ, который как в IPv4.
Пункт в RFC 3484 bis про выбор адреса на основании некст-хопа так никуда и не ушёл.
Судя по RFC 7157, время прошло, а проблема так и не решена. Один из подходов — ввести таблицы маршрутизации с source-destination. Т.е. то, что сейчас делает PBR. Но опять, статус сугубо экспериментальный, и даже если это будет, то не скоро.
Есть другие подходы — LISP, например, но идеальных нет. У некоторых есть большое желание сделать NPT (NAT66), но это всё обычно отметается по религиозным соображениям.
В общем, прошу прощения за дезинформацию, обещанный простой multihoming так и не запилили. Жаль.
Пункт в RFC 3484 bis про выбор адреса на основании некст-хопа так никуда и не ушёл.
Судя по RFC 7157, время прошло, а проблема так и не решена. Один из подходов — ввести таблицы маршрутизации с source-destination. Т.е. то, что сейчас делает PBR. Но опять, статус сугубо экспериментальный, и даже если это будет, то не скоро.
Есть другие подходы — LISP, например, но идеальных нет. У некоторых есть большое желание сделать NPT (NAT66), но это всё обычно отметается по религиозным соображениям.
В общем, прошу прощения за дезинформацию, обещанный простой multihoming так и не запилили. Жаль.
del
Растаращить )
Давно использую. Туннель 6in4 из домашнего роутера в Huricane Electric. Отладочный сервер с несколькими ipv6 адресами с разными JavaEE серверами на разных ip адресах. Miredoo, в офисе и других местах. DynDNS, чтобы не запоминать адреса.
Это не так хорошо, как если бы провайдер выдал мне /64 ipv6 адрес, но очень близко к этому.
Это не так хорошо, как если бы провайдер выдал мне /64 ipv6 адрес, но очень близко к этому.
Вы погрязли в легаси ifconfig'а. Линукс уж лет 10 умеет несколько ipv4 равноправных адреса на интерфейсе.
ip addr add — и делайте сколько понадобится.
ip addr add — и делайте сколько понадобится.
а теперь попробуй заставить локальное приложение прибинденное на 0.0.0.0:949 отправить с него UDP пакет через второй дефолтгейтвей, а не через первый.
а я попкорн рядом пожую.
а я попкорн рядом пожую.
iptables -t mangle -A OUTPUT -p udp --sport 949 -j MARK --set-mark 0x1
ip route add default via второй-гейт table special
ip rule add fwmark 0x1 lookup special
ip route add default via второй-гейт table special
ip rule add fwmark 0x1 lookup special
Ага. Уходит при этом через правильный интерфейс, но с неправильным source address.
… и SNAT не отрабатывает.
… хотя да, забыл сказать, что это при разных интерфейсах. разные адреса на одном интерфейсе работают при этом корректно, да.
… и SNAT не отрабатывает.
… хотя да, забыл сказать, что это при разных интерфейсах. разные адреса на одном интерфейсе работают при этом корректно, да.
Неправда ваша. Всё правильно будет. В таблицу маршрутизации вместе с командой add default добавится и dev интерфейс (само, хотя можно и руками указать). А если интерфейс point-to-point, то via nexhop можно не указывать, только интерфейс — типа ip route add default dev ppp1 table N — и это работает. И всё пойдёт через правильный интерфейc.
А чтобы NAT работал — это вопрос отдельный, но тоже реализуемо.
Собственно, подобная цепочка правил — это миллион раз пройденный путь — habrahabr.ru/post/117620/
Работает безотказно.
А чтобы NAT работал — это вопрос отдельный, но тоже реализуемо.
Собственно, подобная цепочка правил — это миллион раз пройденный путь — habrahabr.ru/post/117620/
Работает безотказно.
Я не идиот, и подобную систему тоже составлял уже десяток раз. Вот только фактически уходит через правильный интерфейс но с неправильным source addr.
Впрочем, я ниосилятор, и возможно это выкрутасы астериска; хотя он НЕ ставит saddr при отправке если забинден на вилдкард.
То есть схема именно такая: mangle/output => ip rule fwmark =>default via xxx dev yyy src zzz
ходит через правильный интерфейс, но с неправильным source address.
Впрочем, я ниосилятор, и возможно это выкрутасы астериска; хотя он НЕ ставит saddr при отправке если забинден на вилдкард.
То есть схема именно такая: mangle/output => ip rule fwmark =>default via xxx dev yyy src zzz
ходит через правильный интерфейс, но с неправильным source address.
вероятно, в таблице маршрутизации тогда нужно было ещё src добавить как подсказку «какой адрес подставлять пакету»
маршрутизация в линуксе действует по порядку: netfilter OUTPUT (здесь мы ставим метку) -> routing (выбирается интерфейс по метке с помощью ip rule и тут же подставится адрес из src) -> POSTROUTING (а тут всевозможные NATы)
маршрутизация в линуксе действует по порядку: netfilter OUTPUT (здесь мы ставим метку) -> routing (выбирается интерфейс по метке с помощью ip rule и тут же подставится адрес из src) -> POSTROUTING (а тут всевозможные NATы)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IPv6: Сколько адресов нужно для счастья?