☰

Маршрутизация локальной сети через OpenVPN на OpenBSD 5.5

tag-icon • tag-icon routing openbsd openvpn pf
Маршрутизация локальной сети через OpenVPN на OpenBSD 5.5

Я настраиваю шлюз OpenVPN, чтобы разрешить доступ локальной сети к интернету через туннель. Шлюз работает под управлением OpenBSD 5.5-stable amd64 на платформе PC Engines APU.

Локальная сеть содержит интерфейсы re1, re2и ral0. Она также содержит vether0, который размещает локальную 192.168.2.0/24сеть. Эти интерфейсы связаны под bridge0, чтобы обеспечить общий шлюз, подсеть и DHCP через dhcpd.

VPN установлен и tun0открыт. Сам шлюз может получить доступ к VPN без проблем.

Проблема в том, что по умолчанию хосты получают доступ к VPN со своими собственными 192.168.2.0/24адресами. NAT необходим для перевода локальной сети в сеть VPN по адресу 10.0.1.0/24.

Я пробовал следующие pf.confконфигурации:

# pf.conf -- 10.0.1.10 is my tun0 gateway
set skip on lo
block return
pass in quick on { vether0 re1 re2 ral0 } from 192.168.2.0/24 to !10.0.0.0/8 nat-to 10.0.1.10
pass

У меня были похожие результаты с этими правилами:

# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any

Это позволяет трафику локальной сети проходить tun0с исходным адресом 10.0.1.10, а обратный трафик передается обратно на соответствующий хост. Новая проблема заключается в том, что обратный трафик по-прежнему, по-видимому, не маршрутизируется правильно.

Например, я могу пинговать 8.8.8.8и google.comс любого хоста локальной сети, однако первый ответ ВСЕГДА теряется между tun0и обратным интерфейсом. Такие инструменты, как dig, nslookup, traceroute, и pingобычно медлительны и работают гораздо дольше, чем должны. Несмотря на то, что некоторый трафик все еще проходит, браузеры и другие приложения не могут использоваться.

tcpdumpдемонстрируя потерю:

# 192.168.2.103 is a LAN host
# 74.125.131.139 is google.com

# on ral0
20:59:35.668251 192.168.2.103 > 74.125.131.139: icmp: echo request <-- no reply
20:59:40.651184 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:40.736748 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:41.656101 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:41.741251 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:42.661071 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:42.802410 74.125.131.139 > 192.168.2.103: icmp: echo reply

# on tun0
20:59:35.668359 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:35.764052 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- here's the missing reply, it didn't get to ral0
20:59:40.651221 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:40.736721 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- but the of the replies rest did
20:59:41.656138 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:41.741226 74.125.131.139 > 10.0.1.10: icmp: echo reply
20:59:42.661107 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:42.802372 74.125.131.139 > 10.0.1.10: icmp: echo reply

Я знаю, что это почти наверняка проблема NAT, pf.confно после стольких попыток настройки у меня возникли проблемы с поиском правильного способа передачи трафика.

Когда я использовал DD-WRT и iptables, моя конфигурация была такой:

iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept

Я не уверен, как "портировать" это на pf, хотя. Любые предложения были бы очень признательны!

решение1

Это оказалось проблемой pf.conf. Дополнительное время, потраченное на изучениеOpenBSD ПФ NATстраница привела меня к следующему правилу, которое позволило трафику корректно проходить через tun0интерфейс:

# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin

По сути, это означает: передавать трафик из локальной сети, предназначенный для любого адреса tun0, на , в частности IPv4, только смотреть на synфлаги ackи и выполнять исходящий NAT с помощью tun0. Скобки вокруг (tun0)говорят pfоб автоматическом обновлении правила при изменении адреса интерфейса. Это может произойти, если ваш VPN поддерживает несколько одноранговых узлов и вы выполняете отказоустойчивость, и, таким образом, ручная перезагрузка набора правил становится ненужной.

Некоторое время наФильтрация OpenBSD PFстраница помогла мне уточнить правило:

# /etc/pf.conf
pass out on $vpn_if inet proto { $protos } from $lan_net to any flags S/SA modulate state nat-to ($vpn_if) round-robin
pass in  on $vpn_if inet proto { $protos } from $vpn_gw  to any flags S/SA modulate state

Флаг modulate stateпозволяет pfзаменить начальный порядковый номер на более сильный, что может помочь защитить некоторые операционные системы в сети.

Теперь шлюз работает отлично, и я перехожу к более сложным pf.confконфигурациям.

Связанный контент