Что: 982b29ed90d9c1e8e39ebb4398e0a4b0f26ad927
Когда: 2022-08-25 21:18:46+03:00
Темы: bgp ipv6
Использую 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 сеть) и
обменивается этим.
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;
}
что удобно, если "клиентов" много, и им динамически выделяются адреса из
некоторого пула.
From: Sergey Matveev Date: 2022-08-26 13:04:22Z
From: Sergey Matveev Date: 2022-08-26 14:05:52Z
Сгенерирован: SGBlog 0.34.0