Что-то не возьму в толк. Вот поднимаю я туннель с Wireguard. После этого у
меня создается линк, допустим wg0, если в конфиге есть PostUp-скрипт, то он
выполняется. Но фактически нет никакого события, которое, кладёт линк,
если, например, peer умер. В результате, если я, например, хочу настроить
default route для зарубежного трафика в этот туннель, то если peer умрет,
зарубежный трафик не будет ходить. Хотелось бы это событие как-то
отлавливать и менять правила разметки трафика и policy forwarding'а, когда
peer оживает или пропадает. Но как-то готовых средств я не нахожу.
Кто-нибудь решил эту задачу в каком-то более менее промышленном виде, а не
на коленке написанным скриптом, который с заданной периодичностью дергает
wg show?
[-- text/plain, encoding base64, charset: UTF-8, 20 lines --]
А поскольку wireguard это переусложнённый ipip туннель, то выбор тут
небольшой - наскриптовать ping/wg show или уже промышленно так, завести
bird2 с bgp и анонсить себе маршруты с удалённой стороны.
У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
потому они переодически шлют нестандартный KeepAlive, который Линукс неЯ тебе один страшный секрет открою - весь магический KeepAlive кривотика -
умеет, и народ решает пингом в кроне: микрот видит траффик, и
тоннель не кладет:)
У циски есть BFD для быстрого детекта упавших линков.BFD - это когда у тебя с обоих сторон что-то, умеющее этот BFD. Впрочем, сам
https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection
Под Линукс есть его реализация тут: https://frrouting.org/Я не зря сказал - bird2. В нём оно тоже есть. И про BGP я тоже говорил не
Возможно, это поможет. Но я не пробовал.О, ты как настоящий блоггер - всё знает, но сам ничего не пробовал. Или
IL Ka <[email protected]> wrote:
У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
инженегры накостыляли GRE со всеми его проблемами.
[-- text/plain, encoding base64, charset: UTF-8, 19 lines --]
Ты эти газеты не читай больше, для здоровья вредно ибо бред написан.Я тебе один страшный секрет открою - весь магический KeepAlive кривотика -
это пакет с 0-byte payload. Которые успешно режут некоторые виды
корпоративных фаирволов.
Всё гораздо хуже:
"
A GRE Keepalive is a "host to router" GRE packet encapsulated inside a "router to host" GRE packet. The idea being the host (in this case Linux) receives the packet, sees the packet is actually a GRE packet for the
router, and sends it back out. The router receives this packet and knows
the remote end is still responding.
The Linux FIB code is such that if it receives traffic where the source is
a local unicast address, the traffic is considered invalid.
"
Так что режет его сам линукс, когда видит пакет со своим адресом в качестве
source.
Можно включить "accept_local", но это дыра, и потому используют пинг.А можно подумать головой, понять, что микротик тупее пробки от шампанского и
On Sun, Aug 07, 2022 at 05:57:03PM +0300, Andrey Jr. Melnikov wrote:Тут вопросов нет. Но только вот мозгом никто не подумал, что между двумя
IL Ka <[email protected]> wrote:
У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
инженегры накостыляли GRE со всеми его проблемами.
GRE это протокол, который с точки зрения payload'a является программным
аналогом 2-го уровня модели OSI, то есть это уровень изернетовских фреймов.
Если посмотреть на номера пейлоадов в исходном RFC1701 (1994 год), там
значения совпадают с изернетовскими номерами. А 2-му уровню нет дела
до доступности получателя. Его задача -- упаковать пришедший пакет и
отправить дальше. Примерно так, наверное, рассуждали авторы GRE.
Спецификация GRE не регламентирует поведение инкапсулятора, которыйДа оно вообще ничего не регламентирует. Как и прохождение через кривые
может мониторить состояние туннеля, либо нет, по своему усмотрению.
Так что вендоры вольны реализовать над GRE любые модели поведения:
как голый GRE (stateless), так и l2tp (например) со своими таймерами.
Но задача, которая обсуждается здесь, более высокого уровня: что делать,В оригинале автор сомневался, что решение "скриптик с wg show" это не
если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
И даже если он мониторит состояния линка и может передать его на уровень
дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
Eugene Berdnikov <[email protected]> wrote:
Спецификация GRE не регламентирует поведение инкапсулятора, которыйДа оно вообще ничего не регламентирует. Как и прохождение через кривые
может мониторить состояние туннеля, либо нет, по своему усмотрению.
Так что вендоры вольны реализовать над GRE любые модели поведения:
как голый GRE (stateless), так и l2tp (например) со своими таймерами.
провайдерские NAT'ы и прочие перелести современных инетрнетов.
Но задача, которая обсуждается здесь, более высокого уровня: что делать,В оригинале автор сомневался, что решение "скриптик с wg show" это не
если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
И даже если он мониторит состояния линка и может передать его на уровень
дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
профессионально и всё такое, а дальше - понеслось.
On Sun, Aug 07, 2022 at 11:01:16PM +0300, Andrey Jr. Melnikov wrote:
Eugene Berdnikov <[email protected]> wrote:
Да нету там этих событий. В выводе wg show можно только гадать по наличиюНо задача, которая обсуждается здесь, более высокого уровня: что делать,В оригинале автор сомневался, что решение "скриптик с wg show" это не
если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
И даже если он мониторит состояния линка и может передать его на уровень
дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
профессионально и всё такое, а дальше - понеслось.
В общем, он правильно сомневается: bgpd или ospfd отслеживают события
"link up/down" гораздо надёжнее, чем самопальные скрипты. Хотя бы потому,
что между двумя poll-ами вида "wg show" можно пропустить события
link down-up, скрипт этого не заметит, а вот ядро маршрутик-то через
могнувший дивайс аккуратно удалит. С push-ами через netlink таких пропусков
не будет. У quagga с этим всё вроде нормально, про bird не скажу, но
думаю что у него аналогично.
Задача: в некоторой сети за рубежом необходимо сделать так, что трафик на[ ... неважно]
российские IP заворачивается в туннель, который выныривает на сервере
внутри России, и чтобы всё это не зависело от настроек хостов в этой сети.
Для чего? Для того, чтобы не страдал user experience в отношении
российских сервисов анально отгородившихся от остального мира - это как
многие государственные сервисы, так и коммерческие (например, Авито).
Почему не заворачивать весь трафик? Out of scope. Так надо сделать.
Сейчас задача решается следующим способом: между роутером в этой сети и
Проблема: если туннель ложится (причины не обсуждаем сейчас), то
отваливается весь рунет.
То есть, понятно, что можно анонсировать со стороны российского сервера в
туннель маршруты на весь рунет, но как это сделать с т.з. конфигурации - я
хз.
[-- text/plain, encoding base64, charset: UTF-8, 66 lines --]
пн, 8 авг. 2022 г. в 01:19, Eugene Berdnikov <[email protected]>:
Проблема: если туннель ложится (причины не обсуждаем сейчас), то
отваливается весь рунет. То есть нужна некоторая активная сущность, которая
будет отключать классификатор пакетов, либо менять правила policy routing.
Я не совсем понимаю, как эту задачу можно решить с помощью ospfd. То есть,
понятно, что можно анонсировать со стороны российского сервера в туннель
маршруты на весь рунет, но как это сделать с т.з. конфигурации - я хз.
вт, 9 авг. 2022 г. в 08:46, Eugene Berdnikov <[1][email protected]>:
решать
задачу не в плоскости ip, а в плоскости прокси и доменных имён, то
завернуть
домены ru/su/рф/рус и ещё пяток через российский parent очень просто.
Не приходит в голову сходу как можно заворачивать трафик по DNS, тем паче,
Коллега, а как вы думаете - без списка российских сетей модуль geoip как
трудится? Никак. Список очевидно есть. В пожатом виде это 70Кб в некотором
бинарном виде. Можно, конечно, написать тул, который перегоняет это в вид,
понятный OSPF'у. Но тут надо понять, что проще - писать тул или писать
демона, который будет следить за keepalive-статистикой wireguard и дёргать
нужные хуки.
[-- text/plain, encoding base64, charset: UTF-8, 70 lines --]
Проблема в том, что инструмент надо использовать по назначению. Модули
netfilter с geoip списками сетей были придуманы для того, чтоб можно было
распихивать пакеты в разные стороны исходя из SRC.
Такая проблема имеется у вас в мозгу в виде ненужного догмата. UNIX way не
предполагает ограничения списка задач для того или иного инструмента, если
он разрабатывался под решение одной проблемы, но также работает и для
другой проблемы. И в данном случае свою задачу этот инструмент решает.
Проблема с другим инструментом.
Более того, в nftables нет вообще никакого geoip модуля, там это работает
просто из коробки благодаря тому, что там есть более высокоуровневые
сущности, которых нет в iptables, из-за чего приходилось решать гораздо
более частные задачи написанием целых модулей для iptables. Отвлеклись от
темы, но от того, что ваш кругозор расширится, вреда не будет.
Исходя из DST, родной. Из DST. И на эту задачу этот инструмент ложится -А тут стильно-модно-молодёжно они используются ровно в обратном виде, с
кучей проблем.
Здесь нету никаких проблем в использовании его в обратном виде. Если в том
сценарии, о котором пишите вы, ложится одна из дырок, куда надо было
запихать, исходя из SRC, то решение так же не будет работать, но не из-за
того, что решение не правильное, а из-за проблем другого порядка. Как
собственно и у меня.
Просто. Берёшь базы от geoip и вливаешь их в таблицу роутинга и через bgp
их в свой туннель экспортируешь.
Мои сомнения в предыдущем письме как раз связаны с отсутствием готовогоЯ тебе один умный вешь скажу, только ты не обижайся - эти данные есть
инструмента, который подобную базу конвертирует в вид, пригодный для
использования демоном того или иного протокола распространения маршрутов. А
у вас всё "просто". Однако, вы сейчас выполняете роль чукчи из анекдота
ниже )
К вопросу об OSPF, BGP и иже с ними. Допустим мы решили задачу
конфигурации и получения базы маршрутов. Если это девайс уровня домашнего
роутера с OpenWRT, он потянет такую большую таблицу маршрутизации?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 158:55:07 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,759 |