default gateway внутри default gateway

Например, добавить маршрут к другому концу туннеля.

эээээ

Очень хорошо все описано в man openvpn, его же можно найти в инете, вас интересует раздел redirect-gateway.
ЗЫ Это не обязательно применительно к ovpn, просто описано доступно.

openvpn - это интересно. но как это применить без openvpn?

Прочитайте этот раздел, там описано что делает ovpn за вас, и сами поймете что нужно вам сделать руками.

нет, не пойму. я вообще в этих маршрутах ничего не понимаю, для меня это как книга на китайском языке. я думал, что это тривиальное что-то, что все так делают. а то, что я прочёл в man, мне вообще никакой новой информации не дало :)

А тебе прям критично чтоб маршрут до 192.168.ХХ.0 дефолтным был?

Уж простите, но то что у вас описано в топике, тоже похоже на «китайскую книгу». Если сами не можите разобраться, добавьте чуть больше подробностей. Схемку, вида у меня комп1 у него ип1 маршрут по умолчанию gw1, он поднимает тунель (уточнить что за тунель) на комп2 у которого ип.... и так далее.

Вот прямо вчера хороший ответ в части постановки вопроса/получения ответа Mikrotik OVPN доступ к сетям клиентов (комментарий)

А тебе прям критично чтоб маршрут до 192.168.ХХ.0 дефолтным был?

мне надо как-то заворачивать трафик до 192.168.XX.1. чтобы работало прозрачно - как сейчас оно работает прозрачно с дефолтным маршрутом. чтобы запустил любое интернет-приложение, и оно работало :)

вопрос больше теоретический. и я сам не понимаю, как оно работает. :)

в общем, есть некая абстрактная сеть с выходом на дефолтный маршрут 192.168.0.1. проброшен некий абстрактный тоннель, после чего я получаю ip 192.168.XX.2, и вижу другой узел 192.168.XX.1. хочу, чтобы трафик шёл через 192.168.XX.1. но чтобы он туда шёл, надо, чтобы он сначала дошёл до 192.168.XX.1 через 192.168.0.1

независимо от того, какой тоннель, роутинг и т.п.. т.е., не как это сделать в конкретном случае, а как это делается вообще.

всё. по-моему, тут вся информация

оно мне не то, чтобы особо надо - но просто интересовало, как это делается. уже раз 50 хотел эту тему запостить, чтобы спросить: вдруг это как-то тривиально

Абстрактный не очем, на какой адрес подключаемся тунелем? Предположим это 1.1.1.1 то сначала надо route add -host 1.1.1.1 gw 192.168.0.1

ага, я уже так и сделал :)

впрочем, у меня всё равно на том конце NAT в OpenBSD неправильно настроен, и я в этом точно ничего не понимаю... ssh соединения проходят, а вот на http-соединениях пишет, что запрос отправлен, ждём ответа - и всё, на этом месте зависает. ща надо выяснить, что работает, а что - нет

вопрос больше теоретический. и я сам не понимаю, как оно работает. :)

Если теоретический, то почитайте теорию. Кстати есть суперская серия «Сети для самых маленьких»! Не подумайте по названию что это ерунда, это действительно очень очень очень хороший материал. Начните читать с нулевой, до последней если не нужно то не обязательно, сами поймете где остановиться. Автор просто молодец!!!

впрочем, у меня всё равно на том конце NAT в OpenBSD неправильно настроен, и я в этом точно ничего не понимаю...

Эммм, извините, новые версии libastral публикуют максимум раз в год (не всегда каждый) но день выпуска всегда один 01.04. В данном случае текущая версия все еще не поддерживает ваши требования.

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

да я только включил. сайты размером несколько байт - показывает. больше - висит. ща бум разбираться, чё там за OpenBSD pf :)

вот такая фигня висит :)

all tcp 87.250.250.242:80 <- 192.168.XX.2:48097 FIN_WAIT_2:FIN_WAIT_2

all tcp *.*.*.*:61022 (192.168.XX.2:48097) -> 87.250.250.242:80 FIN_WAIT_2:FIN_WAIT_2

независимо от того, какой тоннель

Не всё, что называют туннелем, позволяет себе такое. gateway обязан находиться непосредственно на интерфейсе, поэтому подходят только методы, создающие свой тунельный интерфейс. А тогда всё просто
ip ro del default
ip ro add tun-ip via 192.168.0.1
tun up
ip ro add default via 192.168.xx.1 dev tun0

разумеется, интерфейс есть :) в общем, на этой стороне разобрались, теперь надо разобраться на той стороне :) в принципе, кроме http всё остальное что пробовал - работает

ipsec в openbsd работает так:

- ты задаешь Security Associations (SAs). это точки, между которыми будет установлен туннель.

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

после настройки и запуска этого можно увидеть, как потоки. так и туннели:

# ipsecctl -sa                                                                  
FLOWS:
flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer x.y.z.a type require
flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer x.y.z.a type require

SAD:
esp tunnel from x.y.z.a to a.b.c.d spi 0xblabla auth hmac-sha2-512 enc blowfish
esp tunnel from a.b.c.d to x.y.z.a spi 0xablabl auth hmac-sha2-512 enc blowfish

# netstat -rn | grep Encap -A5
Encap:
Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
192.168.1.0/24      0     192.168.2.0/24       0     0     x.y.z.a/esp/require/in
192.168.2.0/24       0     192.168.1.0/24      0     0     x.y.z.a/esp/require/out

каноничное описание процесса из мана:

If we apply ESP in transport mode to the above packet, we will get: [IP header] [ESP header] [TCP header] [data...] Everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected. If we apply ESP in tunnel mode to the original packet, we would get: [IP header] [ESP header] [IP header] [TCP header] [data...] Again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don't have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:

Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B

Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above. This implementation makes use of a virtual interface, enc0, which can be used in packet filters to specify those packets that have been or will be processed by IPsec. NAT can also be applied to enc# interfaces, but special care should be taken because of the interactions between NAT and the IPsec flow matching, especially on the packet output path. Inside the TCP/IP stack, packets go through the following stages:

UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF

With IF being the real interface and UL/R the Upper Layer or Routing code. The [X] stage on the output path represents the point where the packet is matched against the IPsec flow database (SPD) to determine if and how the packet has to be IPsec-processed. If, at this point, it is determined that the packet should be IPsec-processed, it is processed by the PF/NAT code. Unless PF drops the packet, it will then be IPsec-processed, even if the packet has been modified by NAT.

у меня нет ipsec. я вообще openbsd и debian соединяю :)

поставил openvpn - вообще перестал трафик ходить ;)

у меня нет ipsec. я вообще openbsd и debian соединяю :)

как и чем?

да уже соединил худо-бедно

openvpn-ом :)