МГТС/IPv6-2, на модеме HG8245T

lexa - 25/Апр/2018 15:06

Скорее записки для памяти, но пусть будут.

Если у вас МГТС-GPON и модем ПлохойПуть HG8245T, то конфигурирование IPv6 (если убрать все тупиковые пути по которым я ходил) сводится к:

  1. Входим как telecomadmin (пароль admintelecom)
  2. WAN - Wan configuration, кликаем в интернетовский VLAN
  3. Скриншотим его на предмет всех параметров.
  4. Удаляем описание VLAN
  5. Создаем такой же, но в режиме IPv4/IPv6
  6. Ставим все параметры так же как были (Vlan ID, MTU, биндинг к LAN-портам, NAT)
  7. IPv6 параметры оставляем по умолчанию.

Все. Дальше все просто работает, если тот, кто за этим роутером, IPv6 понимает.

Поскольку у меня за ним FreeBSD (и v6 *пока* нужен только на ней, нет планов раздавать в дом), то там понадобилась такая настройка в rc.conf:

ipv6_activate_all_interfaces="YES"
ifconfig_igb3_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"

(igb3 - интерфейс, который смотрит в роутер)

Дальше оттуда ipv6.google.com пингается (и нужные мне места - тоже).

Дальше не для памяти, а скорее вот вопрос:

  • Выдаваемый провайдером адрес может, понятное дело, меняться (как и IPv4)
  • Разумно ли будет, если я захочу раздать v6 по дому, сделать так:
    • Раздать приватные адреса
    • Занатить IPv6->IPv6 эти приватные в выданные мне?

UPD: банальный ipnap нормально NAT-ит link-local в публичные. Пока написал в один адрес, но надо как-то в 0.0.0.0/32 по аналогии со старым, но пока не понял синтаксис (синтаксис понятен в pf, но я исторически ipnat использую).

UPD3: синтаксис простой:

map igb3 inet6 fdaa:dead:c000::0/40 -> ::/128
 

UPD2: чтобы Chrome ходил исходно по v6 нужно иметь v6 DNS похоже.

UPD4: и все едино не помогает, даже если v4 DNS убрать из настроек, и хром и FF ходят IPv4 first, судя по тестам. Ну и хрен с ним.

 

Comments

dtwo (not verified) - 25/Апр/2018 17:40

Может быть меня кто-то поправит, но в в6 нет ната и нет "приватных адресов"
только немаршрутизируемые наружу link-local и нормальные "белые"

так что во всю локальную сеть надо дать /64 и правилами зарезать лишний входящий трафик

lexa - 25/Апр/2018 20:41

А что мне может помешать замэпить link local в внешние?

Раздавать (настоящие) /64 не очень удобно, потому что на внешний интерфейс оно прилетает автоматом и что маску там руками потом менять?

Dimez (not verified) - 25/Апр/2018 19:10

Вся проблема в том, что при перезагрузке HG8245 (а это может инициировать OLT по OMCI при обновлении прошивки или ещё чего-нибудь) прилетят те, что прописаны на станции через OMCI..

lexa - 25/Апр/2018 20:43

Те изменения что я вносил раньше: выключение wifi, смена раздаваемых DHCP-адресов и прочее подобное - остается.

Перезагрузить попробую конечно.

Dimez (not verified) - 26/Апр/2018 12:41

> Те изменения что я вносил раньше: выключение wifi, смена раздаваемых DHCP-адресов и прочее подобное - остается.

Это не настройки подключения :)
Слетают кастомные настройки подключения (точнее, прилетают соединения по omci и становятся выше кастомных)

lexa - 25/Апр/2018 20:44

Вообще, народ который их в бридж переключает - вроде не жалуется на слет настроек?

Dimez (not verified) - 26/Апр/2018 12:40

У меня в бридже стоит хуавей. Сбрасывает настройки подключения, зараза. Повесил на бесперебойник.

lexa - 27/Апр/2018 14:37

Сохранил конфигурацию в system tools.
Передернул питание.
IPv6 на месте.

Владимир Вознес... (not verified) - 22/Июн/2018 01:41

Бесперебойник не нужен. Мне и моим родственникам оказалось достаточно вставить в разрыв (штекер и розетка уже распаяны) маленький аккумулятор с Алиэкспресса.

Anton (not verified) - 25/Апр/2018 19:23

> Раздать приватные адреса
самой удобный вариант - DHCP Prefix Delegation. Я бы поставил dhcp клиент из портов (штатный не умеет ipv6) и посмотрел бы не работает ли у провайдера DHCP PD - если работает - использовать его, если не работает, искать другие варианты.

lexa - 25/Апр/2018 20:46

Провайдерский адрес (/64) чудесным образом доехал с провайдерского роутера на мой. Теперь у меня на внешнем роутерном интерфейсе - /64.

Раздать ее дальше можно - но чтобы вменяемо работало нужно префикс поменять на более длинный. Я боюсь что сделать это ничего не сломав (т.е. не прописывая адрес руками - это ж каждый раз придется делать когда провайдер захочет его сменить) - нельзя.

Anton (not verified) - 25/Апр/2018 21:59

DHCP PD работает следующим образом - к провайдеру делается запрос "хочу сетку (префикс)" - если провайдер это поддерживает он отвечает префиксом, который можно прописать на внутреннем интерфейсе роутера и раздать домашним клиентам. Адрес (префикс) который есть на внешнем интерфейсе при этом остается, но используется только для связи домашнего между маршрутизатором ISP и домашним шлюзом.
---
Если PD у провайдера нету, то самый простой вариант - отказаться от маршрутизации и сделать для ipv6 бридж. Во фре в теории можно бриджевать только ipv6 не трогая остальные протоколы (ipfw+ng_bridge).

lexa - 26/Апр/2018 10:24

Если бы у меня провайдерский роутер раздавал бы адреса по дому - то все бы как вы пишете.

Но моя проблема в том, что вот эти адреса - они попали в единственный сабнет, который линк между моим роутером и провайдерским.

Дальше раздавать
а) или вручную пилить /64 на куски
б) или по домашней сети раздать приватные и nat (как было сделано для IPv4)

Sergey Cheban (not verified) - 26/Апр/2018 11:28

Но моя проблема в том, что вот эти адреса - они попали в единственный сабнет, который линк между моим роутером и провайдерским.

Вот это вряд ли. По идее, линк между роутером и провайдером должен использовать link-local адреса, а сетка предназначена именно для внутридомовой сети. Вот туда её и надо раздать. Желательно - одним куском (здесь уже предлагали настроить freebsd, которая, насколько я понимаю, разделяет Вашу внутреннюю сеть на сегменты, в режим ipv6 bridge, звучит неплохо).

lexa - 26/Апр/2018 11:40

Ну вот схема МГТС - Роутер_МГТС - FreeBSD < домашние подсети.

Роутер_МГТС получил по PrefixDelegation блок /64. Анонсировал его по SLAAC. FreeBSD его получила и присвоила адрес оттуда своему интерфейсу "в мир" с prefixlen = 64.

Дальше я вижу два пути
1:
а) руками поменять prefixlen на "внешнем интерфейсе FreeBSD" на, скажем, 72
б) руками же присвоить адреса из выданной /64 интерфейсам "в домашние подсети"
в) ну и руками же (прописыванием адресов в rtadv.conf) раздать их по дому.

2: а) раздать по дому что-то локальное (fdaa)
б) никогда не менять эту раздачу
в) за-NAT-ить их.

Но я не вижу способа автоматизировать способ 1 (ну понятно можно обскриптовать, но оно не становится менее ручным от этого).

И я не вижу ничего плохого в способе 2. Наоборот, только хорошее, NAT заодно сработает файрволлом.

Sergey Cheban (not verified) - 26/Апр/2018 14:43

А если так: роутер получил блок /64 и каким-то образом целиком отдал его freebsd. Freebsd анонсировала его в "домашние подсети". При этом, правда, сам роутер остаётся без IPv6 адреса (только link-local).

> NAT заодно сработает файрволлом.
Может, пусть файрволлом работает файрволл? У него это лучше получается, и он, в отличие от NAT, не мешает P2P.
Btw, мы вообще подключаем домашнюю сеть к интернету, или изолируем? Если изолируем, это уже другая история.

lexa - 26/Апр/2018 14:52

"каким-то образом отдал" - каким? Какие стандартные (!) способы предлагается использовать?

lexa - 26/Апр/2018 15:15

Заметим что и стандартного метода автоматического деления
"нам тут с аплинка прилетело /64, у нас 3 сабнета, раздаем дальше /66"
Что-то я не наблюдаю. (эдакое рекурсивное prefix delegation)

Что я упускаю?

lexa - 26/Апр/2018 11:42

Да, понятно что можно FreeBSD в режим bridge, но мне эта история не нравится. В режиме роутера (с фильтрами и так далее) - я понимаю что происходит и что надо делать, а отдавать это все на ПлохойПуть - мне кажется плохим путем.

Sergey Cheban (not verified) - 25/Апр/2018 21:26

1. Уточнение. Наверное, провайдер всё-таки выдаёт не один адрес, а сетку?
2. В моём понимании, выданный адрес (или диапазон) меняться не должен. Ни v6, ни v4. Т.е. он может, конечно, но это должно быть примерно таким же редким событием, как смена провайдера или MAC-адреса.
3. Использование NAT в IPv6 - идеологически неправильно: одной из задач IPv6 был уход от всяких NAT'ов.
4. Last but not least. С IPv6 и так проблемы бывают. А тут ещё и NAT дополнительных проблем может добавить.
Поэтому городить NAT лично мне кажется неправильным. Впрочем, я программист, а не админ, и легко могу ошибаться.

> Дальше оттуда ipv6.google.com пингается
IPv6 уже давно включен на самом google.com. Поэтому имеет смысл раздать его по дому хотя бы ради обхода Роскомцензуры, которая IPv6 [пока] не умеет.

lexa - 25/Апр/2018 21:43

Провайдер, конечно, выдает /64
Я ничего не понимаю в IPv6, но вот начитался всяких faqs - и вычитал там, что это есть минимально возможная доза вообще. Т.е. предназначено как бы для одного устройства.

Теперь следите за руками
1) Это 2a00..../64 - приезжает ко мне на роутер само, чудом и конфигурируется интерфейс (тоже чудом).
2) Я, конечно, могу переписать на бумажку этот адрес и разложить его по своим интерфейсам (числом, скажем, 4) с /66 или /72, и того и другого не жалко.

Но пройдер время - и от провайдера приедет другая /64
И что, опять руками?

Andrey Melnikov (not verified) - 26/Апр/2018 02:06

NAT в v6? Тебе адресов не хватает??? Или фаирвол не настроить?

>1) Это 2a00..../64 - приезжает ко мне на роутер само, чудом и конфигурируется интерфейс (тоже чудом).
Так оно так рекомендованно -выдавать на линк /64. EUI64 во все поля. Если EUI неннать - то можно хоть /127 выдавать. И да, для большенства откровение что в v6 нет броадкастов :)

> Но пройдер время - и от провайдера приедет другая /64
Воистину МГТС. Могли бы и прибить один раз и навсегда.
Возьми себе туннель у брокера и будет тебе /64 на стык + /64 или /48 вовнутрь. Пинг правда большеват, но зато мимо всяких композоров.

lexa - 26/Апр/2018 10:10

Могли бы прибить, но гарантии нет же.

Ну и главное - чему противоречит nat то? Внутри fdaa:dead:c0de, дальше натим во внешние /64.

У меня правда не получилось пока в 64, получилось в один адрес, но вроде все работает.

Andrey Melnikov (not verified) - 26/Апр/2018 12:44

>Ну и главное - чему противоречит nat то?
Самой идее IPv6. У тебя есть /64 на любой интерфейс. Зачем там нат?

Луддизм прям какой-то..

lexa - 26/Апр/2018 14:53

Да мне плевать на идею, я не идейный.

Выше описано что есть. Предложения по раздаче этого дальше *стандартными путями*?

Sergey Cheban (not verified) - 25/Апр/2018 23:04

1. /64 предназначена не для одного устройства, а для одной сети. В принципе её можно нарезать и мельче, но тогда могут сломаться stateless address autoconfiguration и пр. Так что если у Вас дома что-то более сложное, чем одна сеть, в которой все всех видят, то /64 Вам, по-хорошему, маловато.
2. В сети IPv6 у каждого устройства может быть несколько адресов. Во-первых, постоянный адрес, основанный на префиксе и MAC-адресе, который никогда не меняется и используется для входящих соединений. Во-вторых, бывают временные адреса, которые создаются, например, раз в сутки и используются для исходящих соединений. Их задача - чтобы враги, к которым Вы зашли браузером, не узнали Ваш постоянный адрес и не начали его сканировать на уязвимости.
3. Вот представьте, что Вы поставили в своей сети веб-камеру, чтобы за аквариумом наблюдать, настроили DNS и уехали в отпуск. А провайдер внезапно взял да и поменял Вам префикс сети, а Ваш префикс отдал кому-то другому. И теперь Вы понятия не имеете, какой адрес у Вашей веб-камеры, и даже спросить не у кого. Ну не нормально это, не должен префикс меняться.
4. Насколько я понимаю, в сети IPv6 компы должны сами анонсировать свои имена. Попробуйте погуглить radvd, Neighbor Discovery Protocol и т.п.

lexa - 26/Апр/2018 10:16

Я вот исхожу из практики: IPv4 адрес меняется периодически (на МГТС - где-то несколько раз в год). Соответственно, камера должна прямо из аквариума через Dynamic DNS стучать куда-то и свой IP обновлять.

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

nic_1996 (not verified) - 26/Апр/2018 10:07

Добрый (?) день, Алексей! Сегодня вывалилась рассылка от basiccolor вот такого содержания:
https://www.basiccolor.de/caution-monitor-profiles-in-mac-os-10-12-and-1...

Это они о чём?

lexa - 26/Апр/2018 10:12

Я видел но не вчитывался, потому что погружен в IPv6

Andrey Melnikov (not verified) - 26/Апр/2018 12:50

>и хром и FF ходят IPv4 first, судя по тестам.
У фри есть эквивалент линуксячего /etc/gai.conf ? Аааа... и тут ручечки вида ip6addrctl_policy в rc.conf

Винда сама предпочитает v6 (если никто ручками в реестре не ковырялся).

lexa - 26/Апр/2018 14:54

Ну вот я вижу как хром (виндовый) идет по большей части на v4, ручек нет (или я их не вижу)

Sergey Cheban (not verified) - 26/Апр/2018 21:13

Конкретно про хром не знаю. Но в целом - примерно так:
1. На многих компах по умолчанию включён IPv6. При этом IPv6 подключения к интернету - нет. Поэтому браузеры не пытаются ходить по IPv6, если видят, что у компа нет честного IPv6 адреса. Кстати, это одна из причин, почему IPv6 NAT может не заработать нормально.
2. Соединение с IPv6 зачастую неправильно настроено. Поэтому браузеры выключают IPv6, если видят, что он плохо работает.
Но если IPv6 настроен нормально, то браузеры его используют.

lexa - 26/Апр/2018 22:10

Ага, интересная мысль про (приватный) адрес.
Я http(s) трафик то вижу (от себя) - но его реально мало. За исключением, естественно, v6-only сайтов.

lexa - 26/Апр/2018 15:04

Про "винду саму" не вполне понятно причем тут она.

Вот некая программа порезолвила имя. Получила A и AAAA записи. Дальше там должна быть логика "а куды коннект".

Винда тут вроде не при делах?

Eugene Paniot (not verified) - 26/Апр/2018 16:06

Конфигурация для getaddrinfo, через которую как раз таки можно задать приоритет протоколу находится в /etc/gai.conf.
Я не уверен правда, используют ли вызов getaddrinfo Chrome и FF.

lexa - 26/Апр/2018 16:29

Особенно на винде, где нету gai :)

EugeneGrosbein (not verified) - 28/Апр/2018 08:07

И хром, и ff, и safari нынче делают примерно одно и то же - при отсутствии явных препятствий к подключению через v6 оно взводит таймер на небольшое время и делает попытку подключения сокета.

Если таймер сработал, а подключение всё ещё в процессе, оно запускает параллельно второе подключение по v4 и которое быстрее получилось, то и используется.

Эта логика называется fast fallback. В ff отключается переводом network.http.fast-fallback-to-IPv4 в falst в about:config

lexa - 28/Апр/2018 09:15

Оно как-то не так очевидно все.
Вот были у меня link-local адреса (+NAT) - и на http://ipv6-test.com/ оба (chrome/FF) ходили исходно на IPv4
Поправил на "очень похожие на настоящие" (+NAT): хром стал IPv6 first, FF - все еще IPv4. Это все было вчера.
Сегодня - оба IPv6 first.

Пока блокировки делаются баном больших сабнетов - меня это устраивает, мне без разницы каким транспортом ходить если все работает, а на заблокированный через blackhole v4-сайт я попаду по v6.
А вот в случае заглушки на v4 "не дадим" - заглушка же будет прилетать от локального ISP и явно быстрее.

Но с задачей "вернуть обратно гугловые сервисы" текущий сетап справляется OK

lexa - 28/Апр/2018 09:16

Проверил выключение fast fallback в FF - вроде работает. Ну и ок.

Kinz (not verified) - 04/Сен/2019 07:19

Ndp proxy норм пашет с мгтс, на openwrt решается переводом DHCP, ra и ndp в режим relay. После этого у каждого девайса есть норм ipv6