Начал использовать VPS с /48 подсетью. Правка ядерного модуля

Что: f1dc900ba79ee0d1f87977c16bfbf61c574bbcdf

Когда: 2023-11-21 21:46:22+03:00

Темы: bsd dns hate ipv6

Начал использовать VPS с /48 подсетью. Правка ядерного модуля

У меня такое впечатление, что последние недели я как-будто только сетью
своей домашней и занимаюсь. Но просто совпадение, что то одно, то другое.
Вчера вот перестал работать IP4Market туннельный брокер, уже больше
суток, не первый раз (aaf1553890450f4cf9ad2364d8f5f00341d3ef10). Причём
его сайт и endpoint работают, но IPv6 трафик никакой не проходит. Они
бесплатны, никаких обязательств нет, поэтому их и не поругать. Но сидеть
без огромной части Интернета не вариант.

Больше туннельных брокеров в РФ я не знаю. Из зарубежных только
Hurricane Electric, который по понятным причинам аналогично рискованно
использовать в плане стабильности. А все VPS что я видел: дают только
/64 сети, что жутко неудобно.

Но во время поиска, в каком-то где-то из комментариев увидел упоминание
VPSville.ru, который даёт /48 сети. Сайт без JavaScript не везде
работает, но чисто информацию полистать можно и без него. Они не то что
/48, но даже /32 могут выдать. Конечно не за бесплатно. Reverse DNS явно
говорят что могут выдать. Явно пишут что "чистые" адреса выдают, хотя
подешевле могут и использованные. Среди вариантов установленных ОС есть
и FreeBSD. Выглядело нормально.

Заказал себе самый простой их VPS и /48 подсеть. Знакомый помог с
оплатой через карточку (а то их офис находится где Коммунарка, далеко),
а мне пришлось доставать из под кровати ноутбук для запуска Knoppix, в
котором из коробки есть какой-то Chromium, ибо под surf-ом клавиатура
для RDP плагина их не работала, да и оплата через карточку вряд ли бы
заработала тоже.

Всё завелось через их web-интерфейс, в том числе и заявка на /48. При
создании предлагают пароль для root-а сразу задать, что мне понравилось.
Но потом он в открытом виде отсылается на почту всё равно, что
нивелирует пользу. Могу сравнить с HexCore.ru, на котором у меня сейчас
исходящий почтовый сервер. Среди пакетов есть ровно один: Zabbix клиент.
На HexCore был даже Bash, что лично мне очень не понравилось, конечно
же. На HexCore настройка IPv4 адреса происходила через... DHCP, а IPv6
через SLAAC. Ну come on! Тут же чисто статически настраиваемые адреса. В
HexCore у меня никак не работала загрузка ISO образа, до загрузки и не
доходил. Тут же и загрузка и установка и вообще всё создание с чистого
листа прошли без проблем или неожиданностей. В общем, как VPS, с точки
зрения конфигурации предварительной -- всё хорошо.

Но конечно же, я это и подозревал, читая их документацию: они выдадут
/48 сеть просто на виртуальный Ethernet интерфейс. Если бы я знал
сколько же это добавляет геморроя. Ну вот почему туннельные брокеры
нормально просто маршрутизируют в тебя -- никаких проблем, никакого
геморроя? Что тут то мешает, тем более когда выдаётся /48? Какой смысл в
такой огромной сети если предполагается что вся она не будет
маршрутизироваться?

Из коробки у них идёт древняя FreeBSD 11.0. Да пофиг, ладно. Установил
ndproxy, сделал gif IPv6-over-IPv4 туннель (как и туннельные брокеры
делают), просто статически маршрут прописал до части /48 адресного
пространства используемого у меня через этот интерфейс. И всё
заработало.

А потом перестало. Дёргаешь ndproxy (выгружаешь, загружаешь, меняешь
настройки) -- временами всё начинает работать, а потом снова прекращает.
Смотрел на tcpdump, но с ходу так и не понял в чём дело. Подумал что
возможно древняя ОС и последний ndproxy возможно как-то не штатно
работают вместе или баги имеются.

Решил поновее поставить версию. Нечаянно скачал FreeBSD 14.0, только на
днях вышедшую. Хотел 13.2, чтобы везде всё одинаково было. Но понял это
только когда уже вошёл в новую переустановленную систему. И... ndproxy в
ней просто не собирается вообще из-за смены API и какая-то структура
стала другие поля содержать. В портах ndproxy тоже помечен как не
собирающийся под этой версией. Пошёл закачивать 13.2 уже. Каждый такой
шаг это минимум полчаса времени потраченного, ибо и много данных
передавать и всё очень не шустрое в их VPS (не быстрый CPU).

И всё равно оно то работает, то нет. Очень внимательно пошёл читать не
маленькую документацию по ndproxy, чтобы понять какой куда IP в его
конфигурации надо засовывать. Убедился что точно всё правильно делаю,
без сомнений. Снова пошёл смотреть на tcpdump и стал замечать, что
вообще-то я отвечаю на запросы для хостов которые вообще не в моей сети
находятся. Маршрутизатор один, а вот запрашивает он множество ещё других
адресов. Я притворяюсь что их знаю и через какое-то время после всего
этого -- всё перестаёт работать. Причём даже сама VPS-ка не в состоянии
кого-то PING-ануть.

В ndproxy есть настройка ndproxyconf_exception_ipv6_addresses, в которой
можно игнорировать адреса. Но чем больше я смотрел на tcpdump, тем
больше убеждался что это не парочка каких-то служебных устройств в сети,
а вообще их количество уже на десятки шло. Указать несколько штук в
ndproxy ещё можно бы было, но тут вообще разные сети. ndproxy для такой
задачи вообще не подходит, судя по документации, не предполагающей
подобное.

Косяк ли это провайдера, который шлёт меня не касающиеся NDP? Думаю что
да. Ибо достучаться из своей сети до этих хостов я всё же не могу. Но
и маршрутизатор я своими ответами "сбиваю" на какое-то время.

Пошёл я править сам ndproxy. Он умеет игнорировать адреса по заданному
списку. А мне надо вообще-то прямо противоположное: отвечать только вот
на эти чётко указанные сети. С десяток строчек Си кода поправил и сделал
простое сравнение элементов списка: если первые 48-бит совпадают, то
значит можно. Вижу что перестал отвечать на не свои адреса. Но потом всё
снова перестало работать, и на самой VPS-ке. Увидел что я и перестал на
NDP пакеты link-local адреса отвечать. Усложнил логику проверки адреса:
если это link-local адреса (прям макросы для этого есть в ОС), то
проверить на равенство последние 64-бита. А противном случае: первые 48.
Ещё добавил логирование явное: на что мы ответили, а что
проигнорировали -- в dmesg можно увидеть.

Стало всё сильно лучше: прям многие минуты все хосты работают (ping до
Интернета) через всё это прокидывание. Но... иногда всё равно
отрубается, но сильно реже. Снова tcpdump, рассматривание уже dmesg-а и
вижу что почему-то advertisement о link-local адресе совсем перестаёт
через какое-то время отправляться. Да и запроса о нём нет. Устал уже,
поэтому проблему "решил" cron-ом и явным убиранием/добавлением этого
адреса на интерфейс, чтобы форсированно инициировать посылку unsolicited
advertisement-а.

Бля, вообще это всё к концу уже порядком начало выбешивать. Не, мне
понравилось с первого раза править Си код, который загружается и
работает в ядре, делает что я от него хочу. Но какого хера провайдеры
делают такую подлянку пользователям? Неужели у них это существенно
что-то упрощает в инфраструктуре, чем просто тупо (раз всё равно для
себя они статический адрес для шлюза используют)? Или это специально
увеличивают порог вхождения и геморроя чтобы /48 сеть не могли
использовать с удобством полноценно? Костыли в виде ndproxy уже
написали, но даже они не рассчитаны на такую архитектуру как у этих вот
(или это всё же просто бага их маршрутизатора, который шлёт мне то, что
не должно).

И ведь наверняка из-за подобного многие люди и считают что IPv6 это
сложно, геморрой и ад. А всё потому что делают не по best practices, без
грамотного проектирования сетей. Короче, сами себе создают проблем.

PTR запись ещё не пробовал себе заводить. Видел что это тоже делается
через обращение в техподдержку. Причём было упомянуто, что они не прочь
проверить есть ли у меня права владения доменом. Это очень удивило (в
хорошем смысле): ведь никогда прежде никто этим не интересовался ни из
домашних провайдеров, ни из VPS.

Если с PTR проблем не будет, то тогда окончательно избавляюсь и от
Hurricane Electric, который до сих пор у меня всё ещё остался для
входящей IPv6 почты. Причём реально только для неё: используется
отдельная таблица маршрутизации (884f5eb6a88411f947a0d6c3fecd37c612a51654)
для трафика почтовика.

Во время запроса на создание /48 сети, по электронной почте связывался с
техподдержкой. В конце они попросили меня предоставить какой-нибудь
альтернативный адрес, а то у них что-то там в их системе не работает
из-за плюсиков в адресе (stargrave+vpsville@). Хотя я и логинился и все
остальные действия без проблем выполнял. Эх...

В общем, целый день был убит. Три переустановки (в первый раз установка
обломилась, и я явно нашёл баг в ней). tcpdump, tshark, ещё больше
tcpdump. Правка везде всех конфигов (что в общем-то заняло не более
10мин наверное). Возня с ndproxy, его изменение. Но в конце всё же уже
более надёжная (не как у бесплатных туннельных брокеров) /48 сеть.

VPS-ка что-то типа 350руб/мес стоит, а /48 аж тысяча. Плюс плата за
домашний провайдер и за статический IPv4 адрес. Почти ровно две тысячи в
месяц выходит доступ в полноценный нормальный Интернет.

Закончились ли мои приключения на сегодня? Отнюдь! Ведь нужно же ещё
glue records поправить для DNS серверов. А это ёбаный (да, да, именно
такой уже) reg.ru (14f327a48c97f751dc12e30b993afb2e66171805). Взял за
сегодня проверенный и отработанный Chromium, залогинился у них. Тыкнул
на свои домены... и ничего. Тыкаю на другие вкладки... и ничего. Но
увидел какую-то плашку самого броузера что он там чего-то
назаблокировал. Оказалось, что в Knoppix штатно из коробки стоит uBlock.
Никогда в жизни подобными штуками не пользовался, а тут оказалось что
всё это время он был включён. И я подумал что наверное из-за этого
reg.ru и не работает. Удалил его. Перезапустил броузер. Ура, вкладки
начали открываться! А вот тыкание на сам домен, чтобы мне показали
возможно поменять список DNS серверов -- не работает. Видимо с 90-х у
меня ещё остались какие-то инстинкты Windows пользователей и я решил
перелогиниться и снова перезапустить броузер. И да: меню для правки
доменов появляются. Из drill NS вывода копирую доменное имя первого
сервера, помня что мне должны предложить, видя что этот от же самый
домен (а значит к нему можно сделать glue record), но мне не предлагают.
Методом тыка я понял что точка на конце всё портит. Хотя перед этим я
оставит только "....nsX", ведь в нормальном DNS софте если не указать
точку в конце, то это будет "относительное" имя, а значит
"ns.stargrave.org" станет "ns.stargrave.org.stargrave.org.". Срать
reg.ru хотел на это -- нужно чтобы остался "stargrave.org" в конце и
никак иначе. Предложили в итоге glue record. Если попытаться набрать с
клавиатуры там что-то, то после любого символа всё что-то мигает и фокус
с поля ввода пропадает! Ввёл символ -- а дальше заново нацеливайся
мышкой на поле ввода и тыкай на него. Где там курсор/фокус, куда он
уходит -- понятия не имею. Пиздец. Это просто на нитроглицерине
полнейший un-usability! Поэтому в консоли я полностью формирую полную
строчку для вставки, как Windows пользователь правой кнопкой мышки
копирую в буфер обмена, чтобы в броузере вставить. Shift-Ins или третья
кнопка почему-то на reg.ru не срабатывают, хотя из терминала испокон
веков так вставляли без проблем. Я реально наверное потратил 20-30мин на
всё это дело, которое прежде занимало наверное минуту, из которой
большая часть времени это было бы копирование логина/пароля и IP адресов.

оставить комментарий

комментарий 0:

From: kmeaw
Date: 2023-11-22 00:22:50Z

Года полтора назад решал похожую задачу - уметь утаскивать кусок (от /64
до /96) IPv6 сети с произвольной машины, где у меня нет контроля над
окружающей сетевой инфраструктурой - например VM instance в каком-нибудь
облаке.

В итоге написал NDP responder на Go для Linux - открывает IPv6
RAW-сокет, вешает на него BPF-программу, подписывается на multicast и с
помощью gopacket разбирает и собирает NDP. Для BPF никакой компилятор не
использовался - в момент запуска настройки брались из флагов и
BPF-программа из инструкций собиралась прямо в слайсе. Вместе с клиентом
для control plane, откуда приходили события об изменениях достижимости
IPv6-адресов в сети и траслировались в trie. Итого получилось около 500
строк.

комментарий 1:

From: Sergey Matveev
Date: 2023-11-22 11:06:31Z


>Года полтора назад решал похожую задачу [...]

Здорово! Вчера тоже посещали мысли о том, чтобы на Go (и тоже вспомнил
про gopacket, который уже использовал) подобное написать, хотя бы просто
уже ради интереса. Но ndproxy изменённый пока меня удовлетворил, хотя он
уже и не собирается на последней версии FreeBSD.

Сгенерирован: SGBlog 0.34.0