маршрутизация OpenVPN

ЯННП. Хост в сеть будет ходить как и раньше, без туннеля? Виртуалка должна ходить через туннель? Зачем делать бриджем?

Присоединяюсь к выше отписавшемуся. Также ЯННП. Достаточно сумбурно описана задача. 1. Вам tap нужен для L2 или это «просто так подумали» ? 2. Может проще решить на уровне L3 и вам этого достаточно?

поднимай в ВМ vpn клиента.

Вам tap нужен для L2

Скорее всего у автора оффтопик на хосте.

хост ходит в сеть параллельно нему ТАР ВПН ходит черех хост (ну как и обычно) зачем делать бридж? затем что виртуалбокс детектит только ТАР адаптеры

ЯННП - а что тут непонятного? поднимаем на хосте ВПН ТАР в виртуалбоксе указываем его в качестве бриджа но при этом траффик хоста чтобы не заварачивался к этот ВПН туннель

все просто помойму, не?

L2 нужен для виртуалбокса как физ.адаптер L3 он не кушает

зачем делать бридж? затем что виртуалбокс детектит только ТАР адаптеры

В смысле? Бридж — это ты про тип адаптера, что ли (который в свойствах виртуальной машины и из системы не меняется)?

в свойствах виртуалки «тип подключения -> сетевой мост» он же бридж

но при этом траффик хоста чтобы не заварачивался к этот ВПН туннель

Ну так пропишите на хосте соответствующие маршруты. В чем проблема-то?

как их правильно прописать?

можете пример привести (я не работал с маршрутизацией)

Какие сейчас правила маршрутизации на хосте? Приведите результат команды

route -n

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
128.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tun0
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0
172.21.0.0 172.21.0.1 255.255.0.0 UG 2 0 0 tun0
8.8.8.8 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0

это на хосте с поднятым ВПН (8.8.8.8 ИПшник ВПНа заменен на гугл)

Для начала удалите tun0-интерфейс в качестве шлюза по умолчанию:

route del default gw 172.21.0.1

Далее, вот эта строка мне совершенно непонятна - зачем половину интернета в туннель направлять?

128.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tun0

Я бы ее тоже удалил:

route del -net 128.0.0.0 netmask 128.0.0.0 gw 172.21.0.1

Вроде этого достаточно. Выполните эти команды и снова, на всякий случай, приведите вывод

route -n

[root@arch]: ~># route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 128.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tap0 172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0 172.21.0.0 172.21.0.1 255.255.0.0 UG 2 0 0 tap0 8.8.8.8 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0

[root@arch]: ~># route del -net 128.0.0.0 netmask 128.0.0.0 gw 172.21.0.1

[root@arch]: ~># route del default gw 172.21.0.1 SIOCDELRT: No such process

[root@arch]: ~># ping -I tap0 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 172.21.0.2 tap0: 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 61ms

[root@arch]: ~># ping -I eth0 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 192.168.1.95 eth0: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=24.0 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=23.9 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=23.9 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 4ms rtt min/avg/max/mdev = 23.893/23.946/24.025/0.056 ms

[root@arch]: ~># route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.21.0.1 128.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0 172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0 172.21.0.0 172.21.0.1 255.255.0.0 UG 2 0 0 tap0 8.8.8.8 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [root@arch]: ~>#

это добавляет OpenVPN при запуске конфига (openvpn conf.ovpn)

/usr/bin/ip link set dev tap0 up mtu 1500 /usr/bin/ip addr add dev tap0 172.21.0.2/16 broadcast 172.21.255.255 /usr/bin/ip route add 8.8.8.8/32 via 192.168.1.1 /usr/bin/ip route add 0.0.0.0/1 via 172.21.0.1 /usr/bin/ip route add 128.0.0.0/1 via 172.21.0.1 /usr/bin/ip route add 172.21.0.0/16 metric 2 via 172.21.0.1

SIOCDELRT: No such process

Тогда так:

route del -net 0.0.0.0 netmask 128.0.0.0 gw 172.21.0.1

это добавляет OpenVPN при запуске конфига

Хм, а кто этот конфиг писал? В чем смысл этих дополнительных маршрутов?

Вот это лишнее. Закомментируйте эти команды:

/usr/bin/ip route add 8.8.8.8/32 via 192.168.1.1
/usr/bin/ip route add 0.0.0.0/1 via 172.21.0.1
/usr/bin/ip route add 128.0.0.0/1 via 172.21.0.1

И снова напишите получившуюся таблицу маршрутизации.

ТС не слушайте его.

Хм, а кто этот конфиг писал? В чем смысл этих дополнительных маршрутов?

Объясняю ( хотя все это есть в мане ovpn). Все это делает опция redirect-gateway.
1. Два маршрута 0.0.0.0/1 и 128.0.0.0/1 - это маршрут по умолчанию, сделано для того что бы не трогать оригинальный присутствующий в системе, т.е. добавляем два маршрута с маской /1 Это параметр def1
2. 8.8.8.8/32 - параметр bypass-dns, сохраняем маршрут до днс сервера через оригинальное подключение. Бывает необходимо например когда используются внутренние корп. dns сервера. А в целом по задаче ТС от этого не теплее не холоднее.

/usr/bin/ip route add 8.8.8.8/32 via 192.168.1.1

IP VPN сервера я заменил на 8.8.8.8

Хм, а кто этот конфиг писал? В чем смысл этих дополнительных маршрутов?

конфиг получает из сервера

PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 172.21.0.0 255.255.0.0,dhcp-option DNS 172.16.0.1,dhcp-option DNS 172.17.0.1,block-outside-dns,route-gateway 172.21.0.1,topology subnet,ping 30,ping-restart 120,ifconfig 172.21.0.2 255.255.0.0,peer-id 1,cipher AES-256-GCM'

Два маршрута 0.0.0.0/1 и 128.0.0.0/1 - это маршрут по умолчанию, сделано для того что бы не трогать оригинальный присутствующий в системе, т.е. добавляем два маршрута с маской /1 Это параметр def1

Спасибо, конечно, за пояснения, но именно это и нужно убрать автору темы, если я его правильно понял. Чтобы через туннель шли только пакеты в сеть на той стороне, а весь остальной трафик шел напрямую.

8.8.8.8/32 - параметр bypass-dns, сохраняем маршрут до днс сервера через оригинальное подключение. Бывает необходимо например когда используются внутренние корп. dns сервера.

Если убрать туннель в качестве шлюза по умолчанию, то этот маршрут также не нужен.

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

Еще раз, я правильно понял Вашу задачу, Вы хотите, чтобы туннель использовался только для трафика в сеть 172.21.0.0? А весь остальной трафик шел напрямую через eth0?

Если да, то тогда меняйте конфиг, как я выше советовал. Если нет, то поясните, пожалуйста, еще раз, что Вы хотите получить в итоге.

Вам выше предложили вариант, «поднимать ovpn» в самой виртуалке. ИМХО это самый простой вариант. Он не устраивает? Если нет, то все остальные схемы будут «чуть» сложнее. Вообще сама работа бриджа у коробки отличается от «традиционной» в смысле конфигурирования. Никогда не углублялся в то как она это обрабатывает внутри себя. Варианты наискосок: Поднимаем «коробку» в nat и рулим iptables и pbr на хосте. Или бридж на «коробке» с eth0 и даем ей статик ip и так же рулим pbr+iptables. Или «пустой» бридж на хосте с отдельной сетью а дальше все теже pbr+iptables+ebtables(возможно).
У меня «исторически» осталась и работает одна «коробка» но она в бридже с eth в «коробке» статик ip, и дальше на хосте уже используется pbr+iptables. Я «почти» уверен что никто у «коробки» не поменяет ip (точнее если это произойдет «будет очень быстро заметно» это взлом), поэтому мне этого достаточно.

Читайте мой ответ выше.

По поводу OpenVPN в виртуалке вопросов нет. Непонятно, почему Вы считаете, что предложенный мной способ не будет работать.

Самого способа я так и не увидел. Увидел только предложение удалить маршруты c tap, что в результате приведет к тому что весь трафик пойдет через defroute на eth0. Т.е. это не решение задачи.

то в результате приведет к тому что весь трафик пойдет через defroute на eth0.

Весь, кроме трафика в сеть 172.21.0.0. Т. е. именно то, что и просил автор темы:

но при этом траффик хоста чтобы не заварачивался к этот ВПН туннель

Я такого у ТС не увидел. Может не правильно понял, тогда простите.

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

Я такого у ТС не увидел.

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