Использую BGP для домашней сети

Год назад (79484c1dc99bf5d6204202ce27f471a1a88f34c9) трогал BIRD2 демон
и игрался с OSPFv3. Сегодня снова вспомнил про эту тему и уже на практике
начал использовать у себя BGP. Лютый overengineering конечно же, но хочется
что-нибудь подобное поиспользовать.

На втором сервере и на моём NUC используется dual-stack IP. Статические
IPv6 и IPv4 адреса. На трафик между ними и основным сервером я хочу
чтобы был зашифрован в Ethernet сети. Поэтому поднимаю IPsec между ними.
Настраивать отдельные туннели/транспорты по отдельности на IPv6 и IPv4
трафик не хочу. Поэтому делаю gif-туннели, которые передаются поверх
fc00:: IPv6 сети Ethernet-а (link-local адреса тут не поддерживает
strongSwan, поэтому использую site-local сеть). Указать для каждого gif
туннеля что он является point-to-point link-ом между IPv4 адресами можно
без проблем:

    gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1420
            tunnel inet6 fc00::98f1 --> fc00::2752
            inet 192.168.20.2 --> 192.168.20.1/32

и на сервере можно указывать 192.168.20.1 на всех gif-ах. А с IPv6
указанием одного и того же адреса не выходило уже не помню по какой
причине. Из-за этого я делал link-local адреса и создавал статические
маршруты: такой то IPv6/128 доступен через такой то интерфейс. Для дома,
учитывая что у меня считанное число подобных туннелей, это конечно
сойдёт, но мне эстетически не нравилось.

Позже я решил просто указывать надуманный IPv6 адрес на сервере для
каждого туннеля, типа:

    inet6 2a03:e2c0:2663:2::53 --> 2a03:e2c0:2663:2::3/128

Это уже было экономией строчек в rc.conf файлах касающихся маршрутов.
Хотя и эстетически неприятно что я вынужден какой-то надуманный адрес
использовать просто чтобы указать что он в этой же сети.

Другой "проблемой" стало то, что мой NUC бывает на работе и подключается
к дому через WireGuard туннель. Но так как на gif-туннелях IP адрес
NUC-а уже "занят", то на wg-туннеле его не прописать уже. А (опять же,
чисто эстетически) хочется чтобы я мог через разные VPN (IPsec или
WireGuard) подключаться и иметь один и тот же адрес. А сервер просто
должен будет знать где именно сейчас мой IP находится.

OSPF, помню, нравился тем, что никаких явно endpoint-ов демонов
маршрутизации не нужно настраивать -- он по multicast-у сам договорится
и всех найдёт. Но через WireGuard multicast-ы не работают и его на
завести в подобную систему. Поэтому завёл BGP.

Помню комментарии в своей прошлогодней записи о том, что можно и более
простые протоколы использовать, и то, что и статические маршруты, more
than good enough. И ни с чем я тут не поспорю -- всё так и есть. Но
хочется потрогать что-то "боевое". Тем более, что IP4Market туннельный
брокер выдаёт /48 сеть, так что у меня тьма /64 доступно для любых задач.

В отличии от OpenBSD, в FreeBSD из коробки не ставятся никакие BGP
демоны. Поэтому на каждый сервер пришлось явно доставить BIRD2. Опыта по
сути со всем этим никакого, как и понимания есть ли у меня понимание
хотя бы основ. Но моих минимальных познаний хватило чтобы это почти без
проблем всё поднять.

На каждом gif/wg-туннеле у меня link-local адреса только, но среди
которых в обязательном порядке выставлен fe80::1 для удобства на
сервере. BGP демоны связываются поверх этих link-local и обмениваются
всеми своими 2000::/3 сетями. Понравилось что в BIRD2 из коробки шаблоны
поддерживаются, которые мне как-раз пригодились, ибо всё однообразно и
однотипно настраивается. Так как BGP трафик всё равно пойдёт по
аутентифицированным IPsec/WireGuard сетям, то дополнительной
аутентификации не делаю и полностью доверяю переданным маршрутам.

Демон BIRD везде автоматически запускается при старте системы. Когда
какой-либо из туннелей готов работать, то BIRD, время от времени,
пытаясь связаться с противоположной стороной, подключится и все маршруты
установит. Адреса, кроме основного сервера, у меня навешиваются прямо на
loopback интерфейс. А маршрут по умолчанию можно просто указать, сказав
что он идёт не через определённый адрес, а просто через интерфейс.

В итоге, строчек в rc.conf файлах и ручных скриптах поднятия туннелей на
NUC-е стало ещё меньше, плюс исчезли глобальные IPv6 адреса из
туннельных интерфейсов. Исчезли надуманные IPv6 адреса используемые
исключительно для туннелей. Если я добавлю новый адрес: то BGP
автоматически оповестит мой центральный сервер (он же и маршрутизатор) о
нём. Если я добавлю целую /64 сеть, то, опять же, все остальные смогут
до неё сразу же автоматом ходить. Причём самих IP адресов (кроме
статичных link-local) в конфиге BIRD-а нет вообще: он собирает всё что
относится к 2000::/3 (что например исключает Yggdrasil сеть) и
обменивается этим.

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

From: kmeaw
Date: 2022-08-26 12:50:54Z

> Причём самих IP адресов (кроме статичных link-local) в конфиге BIRD-а
> нет вообще

Можно и link-local выкинуть с одной стороны BGP, если явным образом
настроить одну сторону, как принимающую соединения:

protocol bgp clients {
        description "clients";
        local 10.240.0.1 as 4242423239;
        neighbor range 10.240.0.0/16 as 64001;
        direct;
        passive yes;
        strict bind no;
}

а другую - как устанавливающую:

protocol bgp {
        local as 64001;
        neighbor 10.240.0.1 as 4242423239;
}

что удобно, если "клиентов" много, и им динамически выделяются адреса из
некоторого пула.

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

From: Sergey Matveev
Date: 2022-08-26 13:04:22Z

*** kmeaw [2022-08-26 15:50]:
>neighbor range 10.240.0.0/16 as 64001;

Я буквально сегодня утром, ещё до завтрака, попробовал использовать
range (как-раз чтобы пассивная принимающая сторона (а у меня passive
явно как-раз стоит) только о себе знала), но что-то не вышло. Видимо
руки кривые и надо будет попробовать снова.

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

From: Sergey Matveev
Date: 2022-08-26 14:05:52Z

*** Sergey Matveev [2022-08-26 16:04]:
>руки кривые и надо будет попробовать снова.

Не, у меня просто не самый свежий bird2 был, который range не
поддерживал. С обновлённым всё заработало. Так что ещё одно упрощение
конфигурации, здорово!