Как понимаю, вопрос на данный момент не актуален? Странно. И всё же, поделюсь своим изысканием.
Поднят Wireguard интерфейс. ВПН в сторону Cloudflare. Довольно скоро я узнал, что они дают только 1Гб трафика (на день? месяц? год? - ещё не понял) Но тут не об этом.
При настройке Wireguard наш интерфейс имеет адрес 172.16.0.2 и P-t-P:172.16.0.2
Почему то, этот адрес не нравится Bird'у и при следовании инструкциям тут и в этой теме я не получал заполнение таблицы маршрутами. Выяснилось, что ошибку вызывает строка
gw = 172.16.0.2; # override route nexthop
Гугление дало ещё пару вариантов её замены:
#bgp_next_hop = 172.16.0.2;
#ifname = "nwg0";
Но и они не работают.
В итоге, появилось неочевидное решение:
protocol static static_routes {
import all;
route 163.172.210.8/32 via 172.16.0.2;
}
И каким то образом это даёт желаемый эффект. НО
При таком раскладе в лог спамится строка вида:
bird4: KRT: Received route with strange next-hop
для КАЖДОГО маршрута. И спамится она туда ПОСТОЯННО. При каждом сканировании ядром таблицы, как я понимаю. Вроде бы, этот спам ни на что не влияет, потому можно просто указать scan time 0:
protocol kernel kernel_routes {
scan time 0;
import none;
export all;
kernel table 1000; # kernel routing table number
}
Пока трафик ещё оставался - вроде работало. По прошествии нескольких дней с момента настройки таблица на месте.
Может, кому то пригодится.
А может, кто то сможет это дело понять и подсказать что нужно. Вроде бы где то проскакивало что next-hop должен быть доступен via direct или как то так, и что бы bird и kernel были счастливы нужно указать что этот интерфейс всегда up или что то в этом духе. Прочитал это мельком, не придал значения в тот момент. И как это сделать тоже не знаю.
