Publicar un servicio LAN en la propia dirección de la puerta de enlace VPN

Presentar un dispositivo LAN en una de las direcciones de túnel propias de la puerta de enlace requiere una sola línea de NAT. La conexión sigue fallando, porque el dispositivo que responde no tiene idea de que la dirección del cliente es alcanzable a través de esa puerta de enlace. Recorra el paquete desde el cliente hacia dentro y luego recorra la respuesta de vuelta hacia fuera, y la mitad que falta se vuelve obvia.

Empiece por la perspectiva del cliente

El cliente de este ejemplo está en el grupo VPN 10.62.0.0/24 y se conecta a 10.62.0.1 en el puerto 8080. Esa dirección pertenece a la propia puerta de enlace, así que el paquete llega al núcleo de la puerta de enlace y no a otro par. Detrás de la puerta de enlace, la LAN es 172.21.4.0/24. La puerta de enlace tiene 172.21.4.10 y el dispositivo que realmente sirve HTTP es 172.21.4.40.

Una dirección que pertenece a otro par de VPN no es intercambiable con la dirección de servicio de la puerta de enlace. Si el cliente se conecta a la dirección de un par, no interviene ninguna regla de la puerta de enlace y todo este recorrido es el caso equivocado.

Delimite la traducción de destino a propósito

La versión estrecha presenta un puerto y reescribe solo el destino. El paquete conserva su protocolo y su origen, y eso es lo que hace interesante el resto del recorrido.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Una regla sin criterios de protocolo y puerto es la versión amplia: conserva el puerto que el cliente haya elegido y solo cambia la dirección. Eso es legítimo cuando se pretende presentar todo el host y erróneo cuando la intención era un solo servicio. Vuelva a leer la regla y confirme el nombre de la interfaz. Una regla DNAT en la interfaz equivocada no coincide con nada, lo que produce el mismo tiempo de espera que una regla ausente y desperdicia una hora mirando el dispositivo.

Deje que la frontera de reenvío esté de acuerdo

La traducción cambia la cabecera, pero no concede permiso. Con una política de descarte predeterminada, el flujo reenviado necesita su propia aceptación, y la dirección de vuelta necesita la regla de conexión establecida que su política probablemente ya tiene.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Una aceptación incondicional para cada flujo DNAT es más amplia que este diseño y también permitirá asignaciones que alguien añada más tarde. Nombre el destino y el puerto, y deje el resto cerrado. Si los contadores de la regla de reenvío se quedan en cero mientras los contadores de NAT suben, el paquete se descarta antes de su regla. Lea el orden de la cadena en lugar de añadir una segunda copia.

El dispositivo tiene que responder de alguna forma

Después de la traducción, el dispositivo ve un origen dentro de 10.62.0.0/24. Su respuesta va a su puerta de enlace predeterminada, que es el enrutador de la LAN, no la puerta de enlace VPN, a menos que algo le diga lo contrario. Dos disposiciones lo arreglan y no son equivalentes. Una ruta en el dispositivo o en el enrutador de la LAN envía 10.62.0.0/24 a 172.21.4.10 conservando el origen del cliente. Una traducción de origen limitada esconde al cliente detrás de la dirección LAN de la puerta de enlace.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Elija según lo que necesite el servicio. La política por cliente y los registros significativos quieren la forma enrutada; un dispositivo al que no se le puede dar una ruta, o un servicio que simplemente debe ver una dirección LAN, apuntan a la forma traducida. No recurra a una regla masquerade global para hacer funcionar una sola respuesta. Esconde a cada cliente de cada destino y rompe en silencio las políticas que dependen de las direcciones de origen.

No pruebe desde la propia puerta de enlace

Una petición generada en la puerta de enlace hacia 10.62.0.1 sale por la cadena OUTPUT, no por la PREROUTING entrante. Su fallo o éxito no dice nada sobre la regla que mira al cliente, y así es como la gente concluye que una regla que funciona está rota.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Ejecute una petición real de cliente y lea ambas cosas. La entrada de conntrack muestra la traducción aplicada, y las capturas muestran si la petición cruzó a la LAN y si volvió una respuesta hacia el túnel. Use una conexión nueva después de cambiar reglas, porque el estado existente conserva su asignación anterior y seguirá fallando a la vieja manera. Después confirme toda la conversación: la dirección del dispositivo, el permiso de reenvío y la ruta de respuesta describen el mismo flujo.