Estoy configurando una puerta de enlace OpenVPN para permitir el acceso LAN a Internet a través del túnel. La puerta de enlace ejecuta OpenBSD 5.5-stable amd64 en la plataforma APU de PC Engines.
La LAN contiene interfaces re1, re2y ral0. También contiene cuál aloja la red vether0local . 192.168.2.0/24Estas interfaces están vinculadas bridge0para proporcionar una puerta de enlace, una subred y un DHCP comunes a través de dhcpd.
La VPN se establece y tun0se abre. La propia puerta de enlace puede acceder a la VPN sin problemas.
El problema es que, por defecto, los hosts acceden a la VPN con sus 192.168.2.0/24direcciones nativas. Se necesita NAT para traducir la red local a la red VPN en 10.0.1.0/24.
He probado las siguientes pf.confconfiguraciones:
# 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
Obtuve resultados similares con estas reglas:
# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any
Esto permite que el tráfico LAN pase tun0con una dirección de origen de 10.0.1.10y el tráfico de retorno se devuelve al host respectivo. El nuevo problema es que el tráfico de retorno todavía no parece encaminarse correctamente.
Por ejemplo, puedo hacer ping 8.8.8.8desde google.comcualquier host de LAN, sin embargo, la primera respuesta SIEMPRE se deja caer entre tun0la interfaz de retorno. Herramientas como dig, nslookup, traceroutey pinggeneralmente son lentas y tardan mucho más de lo debido. A pesar de que todavía pasa algo de tráfico, los navegadores y otras aplicaciones no se pueden utilizar.
tcpdumpdemostrando la pérdida:
# 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
Sé que es casi seguro que se trata de un problema de NAT, pf.confpero después de tantos intentos de configuración, tengo problemas para encontrar la forma correcta de pasar el tráfico.
Cuando usaba DD-WRT y iptables, esta era mi configuración:
iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept
Sin embargo , no estoy seguro de cómo "portar" esto a pf. ¡Cualquier sugerencia será muy apreciada!
Respuesta1
Esto resultó ser un pf.confproblema. Pasar algo de tiempo extra estudiando elOpenBSD PF NATLa página me llevó a la siguiente regla que permitió que el tráfico pasara correctamente a través de la tun0interfaz:
# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin
Básicamente, esto dice: pasar el tráfico desde la red local destinado a cualquier dirección en tun0, específicamente IPv4, solo mirar las banderas syny ack, y realizar NAT saliente usando tun0. Los paréntesis alrededor (tun0)indican pfque se actualice automáticamente la regla cuando la interfaz cambie su dirección. Esto puede ocurrir si su VPN admite múltiples pares y realiza una conmutación por error y, por lo tanto, volver a cargar manualmente el conjunto de reglas se vuelve innecesario.
Algún tiempo en elFiltrado PF de OpenBSDLa página me ayudó a refinar la regla:
# /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
La modulate statebandera permite pfsustituir un Número de secuencia inicial más fuerte que puede ayudar a proteger algunos sistemas operativos en la red.
La puerta de enlace está funcionando muy bien ahora y estoy en pf.confconfiguraciones más complejas.