Roteando uma LAN através do OpenVPN no OpenBSD 5.5

Question

Estou configurando um gateway OpenVPN para permitir o acesso da LAN à Internet através do túnel. O gateway está executando o amd64 do OpenBSD 5.5-stable na plataforma APU dos motores de PC.

A LAN contém as interfaces re1 , re2 e ral0 . Ele também contém vether0 , que hospeda a rede local 192.168.2.0/24 . Essas interfaces estão vinculadas em bridge0 para fornecer um gateway, uma sub-rede e um DHCP comuns por meio de dhcpd .

A VPN é estabelecida e tun0 é aberto. O próprio gateway pode acessar a VPN bem.

O problema é que, por padrão, os hosts acessam a VPN com seus endereços 192.168.2.0/24 nativos. O NAT é necessário para traduzir a rede local para a rede VPN em 10.0.1.0/24 .

Eu tentei as seguintes configurações 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

Eu tive resultados semelhantes com essas regras:

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

Isso permite que o tráfego da LAN passe tun0 com um endereço de origem de 10.0.1.10 e o tráfego de retorno seja passado de volta para o respectivo host. O novo problema é que o tráfego de retorno ainda não parece estar sendo roteado corretamente.

Por exemplo, posso pingar 8.8.8.8 e google.com de qualquer host da LAN, no entanto, a primeira resposta é SEMPRE descartada entre tun0 e a interface de retorno. Ferramentas como dig , nslookup , traceroute e ping são geralmente lentas e demoram muito mais tempo do que deveriam. Apesar de algum tráfego ainda passar, os navegadores e outros aplicativos não podem ser usados.

tcpdump demonstrando a perda:

# 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

Eu sei que isso é quase certamente um problema de NAT em pf.conf , mas depois de tantas tentativas de configuração estou tendo problemas para encontrar a maneira correta de passar tráfego.

Quando eu estava usando DD-WRT e iptables , essa era minha configuração:

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

Não sei como "port" isso para pf , no entanto. Qualquer sugestão seria muito apreciada!

    

Answer 1

Isso se tornou um problema pf.conf . Algum tempo extra gasto estudando a página NAT do OpenBSD PF me levou à seguinte regra que permitia que o tráfego passasse corretamente através da interface 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

Isso essencialmente lê: passe o tráfego da rede local destinada a qualquer endereço em tun0 , especificamente o IPv4, observe apenas os sinalizadores syn e ack e execute o NAT de saída usando tun0 . Os parênteses em torno de (tun0) informam pf para atualizar automaticamente a regra quando a interface altera seu endereço. Isso pode ocorrer se sua VPN oferecer suporte a vários peers e seu failover e, portanto, o recarregamento manual do conjunto de regras se tornar desnecessário.

Algum tempo na página Filtro do OpenBSD PF me ajudou a refinar a regra:

# /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

O sinalizador modulate state permite que pf substitua um número de sequência inicial mais strong, o que pode ajudar a proteger alguns sistemas operacionais na rede.

O gateway está funcionando muito bem e estou em configurações pf.conf mais complexas.