События с линком Wireguard

[Maksim Dmitrichenko]

Всем привет!

Что-то не возьму в толк. Вот поднимаю я туннель с Wireguard. После этого у меня создается линк, допустим wg0, если в конфиге есть PostUp-скрипт, то он выполняется. Но фактически нет никакого события, которое, кладёт линк, если, например, peer умер. В результате, если я, например, хочу настроить default route для зарубежного трафика в этот туннель, то если peer умрет, зарубежный трафик не будет ходить. Хотелось бы это событие как-то отлавливать и менять правила разметки трафика и policy forwarding'а, когда peer оживает или пропадает. Но как-то готовых средств я не нахожу. Кто-нибудь решил эту задачу в каком-то более менее промышленном виде, а не на коленке написанным скриптом, который с заданной периодичностью дергает wg show?

--

With best regards
  Maksim Dmitrichenko

[Andrey Jr. Melnikov]

Maksim Dmitrichenko <dmit...@gmail.com> wrote:

> Что-то не возьму в толк. Вот поднимаю я туннель с Wireguard. После этого у
> меня создается линк, допустим wg0, если в конфиге есть PostUp-скрипт, то он
> выполняется. Но фактически нет никакого события, которое, кладёт линк,
> если, например, peer умер. В результате, если я, например, хочу настроить
> default route для зарубежного трафика в этот туннель, то если peer умрет,
> зарубежный трафик не будет ходить. Хотелось бы это событие как-то
> отлавливать и менять правила разметки трафика и policy forwarding'а, когда
> peer оживает или пропадает. Но как-то готовых средств я не нахожу.

У wireguard невозможно достоверно определить - умер линк или нет. ибо:

"By default, WireGuard tries to be as silent as possible when not being
used; it is not a chatty protocol. For the most part, it only transmits
data when a peer wishes to send packets. When it's not being asked to
send packets, it stops sending packets until it is asked again."

> Кто-нибудь решил эту задачу в каком-то более менее промышленном виде, а не
> на коленке написанным скриптом, который с заданной периодичностью дергает
> wg show?

Флагман промышленности cisco со своим ip sla занимается тем-же самым -
костылянием условий вокруг ping & co. Только там это спрятано за ящиком
синтаксического сахара самобытного cli.

А поскольку wireguard это переусложнённый ipip туннель, то выбор тут
небольшой - наскриптовать ping/wg show или уже промышленно так, завести
bird2 с bgp и анонсить себе маршруты с удалённой стороны.

[IL Ka]

А поскольку wireguard это переусложнённый ipip туннель, то выбор тут
небольшой - наскриптовать ping/wg show или уже промышленно так, завести
bird2 с bgp и анонсить себе маршруты с удалённой стороны.

У микротов есть похожая проблема с GRE: определить смерть GRE невозможно, потому они переодически шлют нестандартный KeepAlive, который Линукс не умеет,

и народ решает пингом в кроне: микрот видит траффик, и тоннель не кладет:)

У циски есть BFD для быстрого детекта упавших линков.

https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection

Под Линукс есть его реализация тут: https://frrouting.org/

Возможно, это поможет. Но я не пробовал. 

 

[Andrey Jr. Melnikov]

IL Ka <kazakev...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 20 lines --]

> >
> >
> > А поскольку wireguard это переусложнённый ipip туннель, то выбор тут
> > небольшой - наскриптовать ping/wg show или уже промышленно так, завести
> > bird2 с bgp и анонсить себе маршруты с удалённой стороны.
> >

> У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,

Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
инженегры накостыляли GRE со всеми его проблемами.

> потому они переодически шлют нестандартный KeepAlive, который Линукс не
> умеет, и народ решает пингом в кроне: микрот видит траффик, и
> тоннель не кладет:)

Я тебе один страшный секрет открою - весь магический KeepAlive кривотика -
это пакет с 0-byte payload. Которые успешно режут некоторые виды
корпоративных фаирволов. Может лет через 10 микротик освоит geneve
инкапсуляцию и его кривую придумку eoip можно будет забыть как страшный сон.

> У циски есть BFD для быстрого детекта упавших линков.
> https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection

BFD - это когда у тебя с обоих сторон что-то, умеющее этот BFD. Впрочем, сам
BFD хоть и придуман в джунипере, но явно по заветам циски - такое-же
бесполезное изобретение.

> Под Линукс есть его реализация тут: https://frrouting.org/

Я не зря сказал - bird2. В нём оно тоже есть. И про BGP я тоже говорил не
просто так - у него есть Hold и Keepalive таймера. Которые уже по умолчанию
180/60 настроены. И не надо никаких плясок вокруг BFD и бесполезного
трафика от него-же.

> Возможно, это поможет. Но я не пробовал.

О, ты как настоящий блоггер - всё знает, но сам ничего не пробовал. Или
очередной адепт микротика?

[IL Ka]

Я тебе один страшный секрет открою - весь магический 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", но это дыра, и потому используют пинг.

 

[Eugene Berdnikov]

On Sun, Aug 07, 2022 at 05:57:03PM +0300, Andrey Jr. Melnikov wrote:
> IL Ka <kazakev...@gmail.com> wrote:
> > У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,
> Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
> инженегры накостыляли GRE со всеми его проблемами.

GRE это протокол, который с точки зрения payload'a является программным
аналогом 2-го уровня модели OSI, то есть это уровень изернетовских фреймов.
Если посмотреть на номера пейлоадов в исходном RFC1701 (1994 год), там
значения совпадают с изернетовскими номерами. А 2-му уровню нет дела
до доступности получателя. Его задача -- упаковать пришедший пакет и
отправить дальше. Примерно так, наверное, рассуждали авторы GRE.

Спецификация GRE не регламентирует поведение инкапсулятора, который
может мониторить состояние туннеля, либо нет, по своему усмотрению.
Так что вендоры вольны реализовать над GRE любые модели поведения:
как голый GRE (stateless), так и l2tp (например) со своими таймерами.

Но задача, которая обсуждается здесь, более высокого уровня: что делать,
если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
И даже если он мониторит состояния линка и может передать его на уровень
дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

IL Ka <kazakev...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 19 lines --]

Ты эти газеты не читай больше, для здоровья вредно ибо бред написан.
Микротик шлёт именно GRE пакет с 0-byte payload:

21:56:08.164777 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 255, id 4127, offset 0, flags [none], proto GRE (47), length 28)
192.0.2.1 > 192.0.2.254: GREv1, Flags [key present], payload szie 0, tunnel id 10
0x0000: 4500 001c 101f 0000 ff2f 2694 c000 0201 E......../&.....
0x0010: c000 02fe 2001 6400 0000 0a00 ......d.....
21:56:08.604068 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 255, id 41493, offset 0, flags [none], proto GRE (47), length 28)
192.0.2.254 > 192.0.2.1: GREv1, Flags [key present], payload szie 0, tunnel id 10
0x0000: 4500 001c a215 0000 ff2f 949d c000 02fe E......../......
0x0010: c000 0201 2001 6400 0000 0a00 ......d.....

вот тебе туда-сюда GRE keepalive пакет.

Вот тебе колхоз вокруг ipip туннеля - тут да, у них фантазии нету:

21:59:04.605691 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 255, id 1, offset 0, flags [none], proto IPIP (4), length 40)
192.0.2.254 > 192.0.2.1: (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto IPIP (4), length 20)
192.0.2.1 > 192.0.2.254: [|ip]
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 0028 0001 0000 ff04 36d1 c000 02fe c000 .(......6.......
0x0020: 0201 4500 0014 0000 0000 ff04 36e6 c000 ..E.........6...
0x0030: 0201 c000 02fe ......
21:59:04.621125 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 82: (tos 0xc0, ttl 64, id 7450, offset 0, flags [none], proto ICMP (1), length 68)
192.0.2.1 > 192.0.2.254: ICMP 192.0.2.1 protocol 4 port 20 unreachable, length 48
(tos 0x0, ttl 255, id 1, offset 0, flags [none], proto IPIP (4), length 40)
192.0.2.254 > 192.0.2.1: (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto IPIP (4), length 20)
192.0.2.1 > 192.0.2.254: [|ip]
0x0000: 0000 0000 0000 0000 0000 0000 0800 45c0 ..............E.
0x0010: 0044 1d1a 0000 4001 d7df c000 0201 c000 .D....@.........
0x0020: 02fe 0303 fcfc 0000 0000 4500 0028 0001 ..........E..(..
0x0030: 0000 ff04 36d1 c000 02fe c000 0201 4500 ....6.........E.
0x0040: 0014 0000 0000 ff04 36e6 c000 0201 c000 ........6.......
0x0050: 02fe ..

> Можно включить "accept_local", но это дыра, и потому используют пинг.

А можно подумать головой, понять, что микротик тупее пробки от шампанского и
через raw socket слать ему нужный вид егоного "keepalive" раз в ндцать
секунд, оно будет довольно.

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Sun, Aug 07, 2022 at 05:57:03PM +0300, Andrey Jr. Melnikov wrote:
> > IL Ka <kazakev...@gmail.com> wrote:
> > > У микротов есть похожая проблема с GRE: определить смерть GRE невозможно,
> > Не у микротов, а опять-же у "флагмана промышленности" - cisco. Ибо это её
> > инженегры накостыляли GRE со всеми его проблемами.

> GRE это протокол, который с точки зрения payload'a является программным
> аналогом 2-го уровня модели OSI, то есть это уровень изернетовских фреймов.
> Если посмотреть на номера пейлоадов в исходном RFC1701 (1994 год), там
> значения совпадают с изернетовскими номерами. А 2-му уровню нет дела
> до доступности получателя. Его задача -- упаковать пришедший пакет и
> отправить дальше. Примерно так, наверное, рассуждали авторы GRE.

Тут вопросов нет. Но только вот мозгом никто не подумал, что между двумя
роутерам может быть больше ОДНОГО туннеля. И с фрагментацией тоже никто не
подумал.. И мультикаст туда не завезли. А так да, стильно-модно-молодёжно,
даже etherip 1991 года своим TEB закрывало, но почему-то не взлетело.

> Спецификация GRE не регламентирует поведение инкапсулятора, который
> может мониторить состояние туннеля, либо нет, по своему усмотрению.
> Так что вендоры вольны реализовать над GRE любые модели поведения:
> как голый GRE (stateless), так и l2tp (например) со своими таймерами.

Да оно вообще ничего не регламентирует. Как и прохождение через кривые
провайдерские NAT'ы и прочие перелести современных инетрнетов.

> Но задача, которая обсуждается здесь, более высокого уровня: что делать,
> если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
> И даже если он мониторит состояния линка и может передать его на уровень
> дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
> вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
> BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.

В оригинале автор сомневался, что решение "скриптик с wg show" это не
профессионально и всё такое, а дальше - понеслось.

[Eugene Berdnikov]

On Sun, Aug 07, 2022 at 11:01:16PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
>
> > Спецификация GRE не регламентирует поведение инкапсулятора, который
> > может мониторить состояние туннеля, либо нет, по своему усмотрению.
> > Так что вендоры вольны реализовать над GRE любые модели поведения:
> > как голый GRE (stateless), так и l2tp (например) со своими таймерами.
> Да оно вообще ничего не регламентирует. Как и прохождение через кривые
> провайдерские NAT'ы и прочие перелести современных инетрнетов.

В 1994 году об этих современных реалиях можно было лишь гадать... Многие
сетевики, насколько я помню, считали что мир пойдёт в сторону технологий
source routing, в том же RFC1701 для GRE есть целая пачка заготовок
на этот счёт. Но к концу 90х явно стал побеждать привычный нам NAT.

Однако явторы GRE не были совсем уж тупы, они также ввели поле "key",
которое дало потом возможность делать трекинг коннекций на шлюзе и
выходить за NAT. Благодаря этому полю GRE до сих пор полужив.

> > Но задача, которая обсуждается здесь, более высокого уровня: что делать,
> > если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
> > И даже если он мониторит состояния линка и может передать его на уровень
> > дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
> > вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
> > BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
> В оригинале автор сомневался, что решение "скриптик с wg show" это не
> профессионально и всё такое, а дальше - понеслось.

В общем, он правильно сомневается: bgpd или ospfd отслеживают события
"link up/down" гораздо надёжнее, чем самопальные скрипты. Хотя бы потому,
что между двумя poll-ами вида "wg show" можно пропустить события
link down-up, скрипт этого не заметит, а вот ядро маршрутик-то через
могнувший дивайс аккуратно удалит. С push-ами через netlink таких пропусков
не будет. У quagga с этим всё вроде нормально, про bird не скажу, но
думаю что у него аналогично.
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Sun, Aug 07, 2022 at 11:01:16PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> >

[]

> > > Но задача, которая обсуждается здесь, более высокого уровня: что делать,
> > > если машрут через туннель недоступен. Сам инкапсулятор этого не знает.
> > > И даже если он мониторит состояния линка и может передать его на уровень
> > > дивайса (link up/down) или на 3-й уровнь (icmp-unreach и т.п.), варианты
> > > вида "переключить маршрут" выходят за рамки p2p-туннеля. Для этого нужен
> > > BGP/OSPF/etc, а GRE тут просто низший уровень, который задачу не решает.
> > В оригинале автор сомневался, что решение "скриптик с wg show" это не
> > профессионально и всё такое, а дальше - понеслось.

> В общем, он правильно сомневается: bgpd или ospfd отслеживают события
> "link up/down" гораздо надёжнее, чем самопальные скрипты. Хотя бы потому,
> что между двумя poll-ами вида "wg show" можно пропустить события
> link down-up, скрипт этого не заметит, а вот ядро маршрутик-то через
> могнувший дивайс аккуратно удалит. С push-ами через netlink таких пропусков
> не будет. У quagga с этим всё вроде нормально, про bird не скажу, но
> думаю что у него аналогично.

Да нету там этих событий. В выводе wg show можно только гадать по наличию
"latest handshake: XX seconds ago" и то, если включены keepalive. Поэтому и
нужен протокол, умеющий внутри себя keepalive.

[Maksim Dmitrichenko]

пн, 8 авг. 2022 г. в 01:19, Eugene Berdnikov <b...@protva.ru>:

 В общем, он правильно сомневается: bgpd или ospfd отслеживают события
 "link up/down" гораздо надёжнее, чем самопальные скрипты. Хотя бы потому,
 что между двумя poll-ами вида "wg show" можно пропустить события
 link down-up, скрипт этого не заметит, а вот ядро маршрутик-то через
 могнувший дивайс аккуратно удалит. С push-ами через netlink таких пропусков
 не будет. У quagga с этим всё вроде нормально, про bird не скажу, но
 думаю что у него аналогично.

Мне что-то в голову не приходит, каким образом моя задача может быть решена с помощью ospfd.

Давайте определим задачу, если вы уже тут собрались придумать решение за рамками очерченной в исходном вопросе проблемы.

Задача: в некоторой сети за рубежом необходимо сделать так, что трафик на российские IP заворачивается в туннель, который выныривает на сервере внутри России, и чтобы всё это не зависело от настроек хостов в этой сети. Для чего? Для того, чтобы не страдал user experience в отношении российских сервисов анально отгородившихся от остального мира  - это как многие государственные сервисы, так и коммерческие (например, Авито). Почему не заворачивать весь трафик? Out of scope. Так надо сделать.

Сейчас задача решается следующим способом: между роутером в этой сети и серваком в РФ поднят wireguard-туннель. Пакеты на роутере классифицируются по destination ip с помощью geoip-модуля iptables или с помощью nftables, и пакетам присваивается соответствующий fwmark. Далее, работает policy routing по этому fwmark, который заворачивает весь трафик, кроме пакетов на адрес российского сервака (он, очевидно, тоже получает такой fwmark), в туннель.

Проблема: если туннель ложится (причины не обсуждаем сейчас), то отваливается весь рунет. То есть нужна некоторая активная сущность, которая будет отключать классификатор пакетов, либо менять правила policy routing. Я не совсем понимаю, как эту задачу можно решить с помощью ospfd. То есть, понятно, что можно анонсировать со стороны российского сервера в туннель маршруты на весь рунет, но как это сделать с т.з. конфигурации - я хз.  

[Eugene Berdnikov]

On Tue, Aug 09, 2022 at 03:16:04AM +0300, Maksim Dmitrichenko wrote:
> Задача: в некоторой сети за рубежом необходимо сделать так, что трафик на
> российские IP заворачивается в туннель, который выныривает на сервере
> внутри России, и чтобы всё это не зависело от настроек хостов в этой сети.
> Для чего? Для того, чтобы не страдал user experience в отношении
> российских сервисов анально отгородившихся от остального мира  - это как
> многие государственные сервисы, так и коммерческие (например, Авито).
> Почему не заворачивать весь трафик? Out of scope. Так надо сделать.
>
> Сейчас задача решается следующим способом: между роутером в этой сети и

[ ... неважно]

>
> Проблема: если туннель ложится (причины не обсуждаем сейчас), то
> отваливается весь рунет.

А зачем заворачивать в туннель ВЕСЬ рунет? Заворачивайте то, что нужно
завернуть ("отгородившиеся" сервисы), тогда если туннель отваливается,
то менять правила на ротутере будет незачем. К отвалившимся хостам ведь
напрямую ходить не следует, разве не так?

Вопрос, конечно, как составить список "отгородившихся"... Но если решать
задачу не в плоскости ip, а в плоскости прокси и доменных имён, то завернуть
домены ru/su/рф/рус и ещё пяток через российский parent очень просто.

> То есть, понятно, что можно анонсировать со стороны российского сервера в
> туннель маршруты на весь рунет, но как это сделать с т.з. конфигурации - я
> хз.  

Технически это рабочая схема, правда, где взять список российских сетей,
я не знаю.
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 66 lines --]

> пн, 8 авг. 2022 г. в 01:19, Eugene Berdnikov <b...@protva.ru>:

[...]

> Проблема: если туннель ложится (причины не обсуждаем сейчас), то
> отваливается весь рунет. То есть нужна некоторая активная сущность, которая
> будет отключать классификатор пакетов, либо менять правила policy routing.

Проблема в том, что инструмент надо использовать по назначению. Модули
netfilter с geoip списками сетей были придуманы для того, чтоб можно было
распихивать пакеты в разные стороны исходя из SRC.
А тут стильно-модно-молодёжно они используются ровно в обратном виде, с
кучей проблем.

> Я не совсем понимаю, как эту задачу можно решить с помощью ospfd. То есть,
> понятно, что можно анонсировать со стороны российского сервера в туннель
> маршруты на весь рунет, но как это сделать с т.з. конфигурации - я хз.

Просто. Берёшь базы от geoip и вливаешь их в таблицу роутинга и через bgp их
в свой туннель экспортируешь. Заодно, вливать можно самим демоном роутинга -
демона пристрелил - маршруты пропали.

[Maksim Dmitrichenko]

вт, 9 авг. 2022 г. в 08:46, Eugene Berdnikov <b...@protva.ru>:

 А зачем заворачивать в туннель ВЕСЬ рунет? Заворачивайте то, что нужно
 завернуть ("отгородившиеся" сервисы), тогда если туннель отваливается,
 то менять правила на ротутере будет незачем. К отвалившимся хостам ведь
 напрямую ходить не следует, разве не так?

Затем, что не никакого желания составлять список отгородившихся. Более того, этот список постоянно меняется. Тот, кто ещё вчера не отгораживался, сегодня может уже отгородится. Пользователи об этом не будут репортить своевременно, так как для большинства из них "сайт лёг" - это событие не связанное с тем, что сервис находится в РФ.

 

 Вопрос, конечно, как составить список "отгородившихся"... Но если решать
 задачу не в плоскости ip, а в плоскости прокси и доменных имён, то завернуть
 домены ru/su/рф/рус и ещё пяток через российский parent очень просто.

Не приходит в голову сходу как можно заворачивать трафик по DNS, тем паче, что некоторые юзеры с своих настройках ставят фиксированный публичный DNS типа google или adguard. Схема не должна ломаться в этом случае.

 

>    То есть, понятно, что можно анонсировать со стороны российского сервера в
>    туннель маршруты на весь рунет, но как это сделать с т.з. конфигурации - я
>    хз.  

 Технически это рабочая схема, правда, где взять список российских сетей,
 я не знаю.

Коллега, а как вы думаете - без списка российских сетей модуль geoip как трудится? Никак. Список очевидно есть. В пожатом виде это 70Кб в некотором бинарном виде. Можно, конечно, написать тул, который перегоняет это в вид, понятный OSPF'у. Но тут надо понять, что проще - писать тул или писать демона, который будет следить за keepalive-статистикой wireguard и дёргать нужные хуки.

[Maksim Dmitrichenko]

Проблема в том, что инструмент надо использовать по назначению. Модули
netfilter с geoip списками сетей были придуманы для того, чтоб можно было
распихивать пакеты в разные стороны исходя из SRC.

Такая проблема имеется у вас в мозгу в виде ненужного догмата. UNIX way не предполагает ограничения списка задач для того или иного инструмента, если он разрабатывался под решение одной проблемы, но также работает и для другой проблемы. И в данном случае свою задачу этот инструмент решает. Проблема с другим инструментом.

Более того, в nftables нет вообще никакого geoip модуля, там это работает просто из коробки благодаря тому, что там есть более высокоуровневые сущности, которых нет в iptables, из-за чего приходилось решать гораздо более частные задачи написанием целых модулей для iptables. Отвлеклись от темы, но от того, что ваш кругозор расширится, вреда не будет.

 

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

Здесь нету никаких проблем в использовании его в обратном виде. Если в том сценарии, о котором пишите вы, ложится одна из дырок, куда надо было запихать, исходя из SRC, то решение так же не будет работать, но не из-за того, что решение не правильное, а из-за проблем другого порядка. Как собственно и у меня.

 

Просто. Берёшь базы от geoip и вливаешь их в таблицу роутинга и через bgp их
в свой туннель экспортируешь.

Мои сомнения в предыдущем письме как раз связаны с отсутствием готового инструмента, который подобную базу конвертирует в вид, пригодный для использования демоном того или иного протокола распространения маршрутов. А у вас всё "просто". Однако, вы сейчас выполняете роль чукчи из анекдота ниже )

Геологи едут по тундре, и у них застревает машина. Они и так и эдак — не могут вытащить. Подъезжает чукча на оленях:
— Однако давай бутылку — скажу что вам надо.
Геологи:
— Да иди ты чукча! Без тебя вытащим.
Весь день вытаскивали — не вытащили. Снова проезжает чукча на оленях. Геологи его останавливают, говорят:
— Чукча, вот тебе бутылка, скажи, что нам надо?
— А! Однако теперь две бутылки давай!
Дали чукче две бутылки. Чукча уложил их в сани, сел сам и говорит:
— Однако ТРАКТОР вам надо!

[Eugene Berdnikov]

On Tue, Aug 09, 2022 at 10:44:42AM +0300, Maksim Dmitrichenko wrote:
> вт, 9 авг. 2022 г. в 08:46, Eugene Berdnikov <[1]b...@protva.ru>:

> решать
>  задачу не в плоскости ip, а в плоскости прокси и доменных имён, то
> завернуть
>  домены ru/su/рф/рус и ещё пяток через российский parent очень просто.
>
> Не приходит в голову сходу как можно заворачивать трафик по DNS, тем паче,

Речь шла о том, чтобы юзеров выпускать в мир через прокси. A на прокси,
как вариант, прописать проксирование российских доменов через российский
parent-прокси, доступный через туннель. Для сквида это директивы вида
"dstdomain .ru .su ..." и "cache_peer_access ...", ну и prefer_direct
и never_direct по вкусу.

Для сквида есть ещё вариант пометить обращения к целевым доменам через
tcp_outgoing_address / tcp_outgoing_mark / tcp_outgoing_tos, и далее
через ip rules отправлять их в туннель. Но не уверен, что это можно
сделать по имени домена -- у сквида есть ограничения на тип acl-ей
для таких директив.

> Коллега, а как вы думаете - без списка российских сетей модуль geoip как
> трудится? Никак. Список очевидно есть. В пожатом виде это 70Кб в некотором
> бинарном виде. Можно, конечно, написать тул, который перегоняет это в вид,
> понятный OSPF'у. Но тут надо понять, что проще - писать тул или писать
> демона, который будет следить за keepalive-статистикой wireguard и дёргать
> нужные хуки.

Ага, за время пока мы тут дискутируем, можно было пару раз пинговалку
написать. А поскольку риалтайм тут не нужен, то всякие bgp и ospf здесь
перебор, десяток строчек на шелле решат задачу.
--
Eugene Berdnikov

[Maksim Dmitrichenko]

вт, 9 авг. 2022 г. в 11:48, Eugene Berdnikov <b...@protva.ru>:

 Речь шла о том, чтобы юзеров выпускать в мир через прокси.

Детям, всё лучшее - детям! )

 

>    Коллега, а как вы думаете - без списка российских сетей модуль geoip как
>    трудится? Никак. Список очевидно есть. В пожатом виде это 70Кб в некотором
>    бинарном виде. Можно, конечно, написать тул, который перегоняет это в вид,
>    понятный OSPF'у. Но тут надо понять, что проще - писать тул или писать
>    демона, который будет следить за keepalive-статистикой wireguard и дёргать
>    нужные хуки.

 Ага, за время пока мы тут дискутируем, можно было пару раз пинговалку
 написать. А поскольку риалтайм тут не нужен, то всякие bgp и ospf здесь
 перебор, десяток строчек на шелле решат задачу.

ЛОЛ! Я написал свой вопрос 8 июля и тогда вообще никто не ответил. Я уже и забыл про это, как вдруг спустя месяц обнаружил эту довольно токсичную дискуссию, где участники практически с ходу перешли на личности. Неужели вы думаете, что за это время я не приделал костыль? И зачем пинги, когда у wireguard есть свои keepalive'ы? Приделал, конечно, но тем не менее, я был бы счастлив узнать что-то новое и узнать способ решения такой задачи правильным путем.

К вопросу об OSPF, BGP и иже с ними. Допустим мы решили задачу конфигурации и получения базы маршрутов. Если это девайс уровня домашнего роутера с OpenWRT, он потянет такую большую таблицу маршрутизации? Для случая с policy routing эта проблема во много решается connmark'ом, чтобы не прогонять каждый пакет через модуль geoip. А как скажется на нагрузке использование огромной таблицы маршрутов?

[Andrey Jr. Melnikov]

Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 70 lines --]

> > Проблема в том, что инструмент надо использовать по назначению. Модули
> > netfilter с geoip списками сетей были придуманы для того, чтоб можно было
> > распихивать пакеты в разные стороны исходя из SRC.


> Такая проблема имеется у вас в мозгу в виде ненужного догмата. UNIX way не
> предполагает ограничения списка задач для того или иного инструмента, если
> он разрабатывался под решение одной проблемы, но также работает и для
> другой проблемы. И в данном случае свою задачу этот инструмент решает.
> Проблема с другим инструментом.

Проблема с изначальной постановкой задачи и общим понимание применимости
конкретных инструментов.

> Более того, в nftables нет вообще никакого geoip модуля, там это работает
> просто из коробки благодаря тому, что там есть более высокоуровневые
> сущности, которых нет в iptables, из-за чего приходилось решать гораздо
> более частные задачи написанием целых модулей для iptables. Отвлеклись от
> темы, но от того, что ваш кругозор расширится, вреда не будет.

Спасибо, о великий, за расширение моего кругозора. Только это не тебе - а
роскомнадзору. Благодоря ему, я уже не один год знаю - как, что, зачем и
куда отправлять. Через туннели с шифрованием и без, с помощью BGP и прочих
самопальных демонов на nfqueue.

> > А тут стильно-модно-молодёжно они используются ровно в обратном виде, с
> > кучей проблем.

> Здесь нету никаких проблем в использовании его в обратном виде. Если в том
> сценарии, о котором пишите вы, ложится одна из дырок, куда надо было
> запихать, исходя из SRC, то решение так же не будет работать, но не из-за
> того, что решение не правильное, а из-за проблем другого порядка. Как
> собственно и у меня.

Исходя из DST, родной. Из DST. И на эту задачу этот инструмент ложится -
криво. Но если вам мотать изолентой скрипты не лень - можете. Благо, UNIX
way такое позволяет. Мне лень, мне проще bird2+bgp поднять. В одном месте
прописал - весь мой домашний mesh уже знает. И нет проблем с выяснением
связанности, оно без меня и скриптов разберется - как туда попасть.

> > Просто. Берёшь базы от geoip и вливаешь их в таблицу роутинга и через bgp
> > их в свой туннель экспортируешь.
> >

> Мои сомнения в предыдущем письме как раз связаны с отсутствием готового
> инструмента, который подобную базу конвертирует в вид, пригодный для
> использования демоном того или иного протокола распространения маршрутов. А
> у вас всё "просто". Однако, вы сейчас выполняете роль чукчи из анекдота
> ниже )

Я тебе один умный вешь скажу, только ты не обижайся - эти данные есть
изначально только в одном виде - список сетей с масками. Текстовый. Лежит в
RIPE. То, что добрый дядя, взял его и перевёл в бинарный формат (устраивая
при этом vendor lock) - так это задачи дяди, он на этом деньги зарабатывает.
И в оригинале - все эти базы maxmind были вообще для применения в
web-серверах. И только потом их начали прикручивать куда попало.

Поэтому - изначально идея правильная, а решение кривое до невозможности.
Ровно из-за микроскопа, которым пытаются забивать в землю дождевых червей.

[Maksim Dmitrichenko]

вт, 9 авг. 2022 г. в 13:00, Andrey Jr. Melnikov <temno...@gmail.com>:

Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 70 lines --]

> > Проблема в том, что инструмент надо использовать по назначению. Модули
> > netfilter с geoip списками сетей были придуманы для того, чтоб можно было
> > распихивать пакеты в разные стороны исходя из SRC.


> Такая проблема имеется у вас в мозгу в виде ненужного догмата. UNIX way не
> предполагает ограничения списка задач для того или иного инструмента, если
> он разрабатывался под решение одной проблемы, но также работает и для
> другой проблемы. И в данном случае свою задачу этот инструмент решает.
> Проблема с другим инструментом.

Проблема с изначальной постановкой задачи и общим понимание применимости
конкретных инструментов.

Постановка задачи вполне валидная. Применимость конкретных инструментов обсуждаемая. Но твой довод сводится к тому, что если Эйнштейн придумал ОТО пытаясь объяснить себе что сфотографирует фотоаппарат, движущийся со скоростью света от объекта, то ОТО нельзя применять для GPS.

 

Исходя из DST, родной. Из DST.

Я цитирую тебя. Ты описывал сценария с SRC. Так вот в том сценарии проблема такая же.

 

> > Просто. Берёшь базы от geoip и вливаешь их в таблицу роутинга и через bgp
> > их  в свой туннель экспортируешь.
> >

> Мои сомнения в предыдущем письме как раз связаны с отсутствием готового
> инструмента, который подобную базу конвертирует в вид, пригодный для
> использования демоном того или иного протокола распространения маршрутов. А
> у вас всё "просто". Однако, вы сейчас выполняете роль чукчи из анекдота
> ниже )
Я тебе один умный вешь скажу, только ты не обижайся - эти данные есть
изначально только в одном виде - список сетей с масками. Текстовый. Лежит в
RIPE.

Секрет полишинеля, ганацвале. Или ты хочешь сказать, что не стал использовать плоды работы доброго дяди и сам героически составил такую базу исключительно на данных RIPE?

 

То, что добрый дядя, взял его и перевёл в бинарный формат (устраивая
при этом vendor lock) - так это задачи дяди, он на этом деньги зарабатывает.

Для баз maxmind есть тулзы, которые конвертируют этот формат в формат, понятный geoip для iptables и nftables. Неужели ты думаешь, что они работают с неизвестным никому форматом? )

 

И в оригинале - все эти базы maxmind были вообще для применения в
web-серверах.

Какая разница для чего? Опять ты со своим догматом "где родился только там и пригодился".

 

И только потом их начали прикручивать куда попало.

Ииии?

 

Поэтому - изначально идея правильная, а решение кривое до невозможности.
Ровно из-за микроскопа, которым пытаются забивать в землю дождевых червей.

Я по прежнему не прочитал правильное решение в твоем исполнении на практике, кроме того, как это может работать в теории. Я не против поднятия демонов для роутинга и прочее. Однако конкретные нюансы, без решения которых на практике эту теорию не воплотить, ты обходишь стороной, как этот самый скользкий дождевой червь )

[Eugene Berdnikov]

On Tue, Aug 09, 2022 at 12:53:53PM +0300, Maksim Dmitrichenko wrote:
> К вопросу об OSPF, BGP и иже с ними. Допустим мы решили задачу
> конфигурации и получения базы маршрутов. Если это девайс уровня домашнего
> роутера с OpenWRT, он потянет такую большую таблицу маршрутизации?

Вопрос насколько большую. Если база под рукой, посчитайте число префиксов.
Насколько я помню, у full view сейчас префиксов где-то 800 тысяч, так что
рунет с его 3% от населения Земли скорее всего < 40 тысяч маршрутов требует.
Это 5-10 мег памяти, у современного домашнего роутера столько найдётся.
По cpu нужно смотреть, но думаю что в линуксе просмотр таблиц маршрутизации
хорошо оптимизирован и узким местом будет не процессор, а шина.
--
Eugene Berdnikov