Estou configurando um gateway OpenVPN para permitir acesso de LAN à Internet através do túnel. O gateway está executando o OpenBSD 5.5-amd64 estável na plataforma PC Engines APU.
A LAN contém re1, re2e ral0interfaces. Ele também contém quem hospeda a rede vether0local . 192.168.2.0/24Essas interfaces estão vinculadas bridge0para fornecer um gateway, sub-rede e DHCP comuns via dhcpd.
A VPN é estabelecida e tun0aberta. O próprio gateway pode acessar a VPN perfeitamente.
O problema é que, por padrão, os hosts acessam a VPN com seus 192.168.2.0/24endereços nativos. O NAT é necessário para traduzir a rede local para a rede VPN em 10.0.1.0/24.
Eu tentei as seguintes pf.confconfigurações:
# 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
Tive resultados semelhantes com estas 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 tun0com um endereço de origem 10.0.1.10, e o tráfego de retorno seja repassado ao respectivo host. O novo problema é que o tráfego de retorno ainda não parece estar sendo roteado corretamente.
Por exemplo, posso executar ping 8.8.8.8de google.comqualquer host LAN, porém a primeira resposta SEMPRE é colocada entre tun0a interface de retorno. Ferramentas como dig, nslookup, traceroutee pinggeralmente são lentas e demoram muito mais do que deveriam. Apesar de ainda haver algum tráfego, os navegadores e outros aplicativos ficam inutilizáveis.
tcpdumpdemonstrando 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, pf.confmas depois de tantas tentativas de configuração, estou tendo problemas para encontrar a maneira correta de passar o tráfego.
Quando eu estava usando DD-WRT e iptables, esta era minha configuração:
iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept
Não tenho certeza de como "portar" isso para pf, no entanto. Qualquer sugestão seria muito apreciada!
Responder1
Isso acabou sendo um pf.confproblema. Algum tempo extra gasto estudando oOpenBSD PF NATpágina me levou à seguinte regra que permitiu que o tráfego passasse corretamente pela tun0interface:
# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin
Basicamente, isso diz: passe o tráfego da rede local destinado a qualquer endereço em tun0, IPv4 especificamente, observe apenas os synsinalizadores acke e execute NAT de saída usando tun0. Os parênteses ao redor (tun0)indicam pfpara atualizar automaticamente a regra quando a interface altera seu endereço. Isso pode ocorrer se a sua VPN suportar vários pares e você fizer failover e, portanto, recarregar manualmente o conjunto de regras se tornar desnecessário.
Algum tempo noFiltragem PF do OpenBSDpage 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 modulate statesinalizador permite pfsubstituir um número de sequência inicial mais forte, o que pode ajudar a proteger alguns sistemas operacionais na rede.
O gateway está funcionando muito bem agora e estou em pf.confconfigurações mais complexas.