¿Qué paquete debe coincidir con una política VPN de doble WAN?

Las peticiones de enrutar la VPN por el segundo enlace describen al menos dos tareas distintas, y la política que arregla una no toca la otra. En la primera tarea, el transporte cifrado entre dos extremos pasa a otra dirección WAN. En la segunda, el flujo de aplicación descifrado de un usuario conectado sale hacia otro salto siguiente. Ambas son legítimas, ambas usan enrutamiento y cada una necesita una coincidencia en un paquete que exista en el punto donde se toma la decisión. Recorra las comprobaciones de abajo en orden, porque la primera determina qué paquete deben nombrar las reglas posteriores.

Nombre las dos conversaciones

Imagine un trabajador remoto conectado a una puerta de enlace de oficina, que abre HTTPS hacia un servidor de aplicaciones interno. Hay dos conversaciones independientes en el cable, y tienen direcciones distintas en cada extremo. La conversación exterior va entre los dos extremos de la VPN: de la dirección de la puerta de enlace a la dirección del par, con el protocolo y el puerto que haya negociado el despliegue. La conversación interior va desde la dirección asignada al cliente hasta la dirección del servidor de aplicaciones en el puerto 443.

El puerto de destino de la aplicación no es el puerto de transporte de la VPN, y ninguna cantidad de política sobre TCP 443 moverá el túnel. Igualmente, una regla que redirige la dirección de transporte del par no dice nada sobre adónde va la petición HTTP de ese usuario tras el descifrado. Anote las dos conversaciones con sus direcciones reales antes de tocar una regla, porque la mayor parte de la confusión en este terreno viene de nombrar una y configurar la otra.

Descubra dónde puede ver realmente el paquete su política

La coincidencia debe evaluarse en la cadena y el espacio de nombres donde el paquete sigue teniendo la forma que describió. Una regla enganchada a la entrada de LAN ve el paquete interior, sin cifrar, antes de que se enrute hacia el túnel. Una regla aplicada al tráfico originado localmente ve los paquetes que genera la propia puerta de enlace, y no cubre automáticamente el tráfico que la puerta de enlace solo reenvía. La salida encapsulada es otra vez un tercer caso, normalmente gestionado en la interfaz que lleva el túnel y no en el lado de la LAN.

Por eso el mismo fragmento de configuración se comporta distinto en dos plataformas: los puntos de enganche difieren, y el gancho de política de un fabricante puede estar antes o después del paso de cifrado. Lea la ruta del paquete para el producto concreto en lugar de suponer el orden a partir del diagrama de otro fabricante.

Confirme el transporte que negoció

Para IPsec encapsulado en UDP, RFC 3948 coloca ESP dentro de UDP y usa un marcador que no es ESP para mantener IKE distinguible en el puerto compartido. El ESP simple es un protocolo IP, no un puerto TCP o UDP, así que una regla de cortafuegos escrita contra un número de puerto no lo hará coincidir en absoluto. Esta distinción decide si su política WAN necesita una regla UDP, una regla de protocolo o ambas.

Los valores negociados ganan a los recordados. Lea los puertos y direcciones actuales de la asociación desde el dispositivo en lugar de añadir TCP 4500 o un puerto antiguo del fabricante por si acaso, lo que captura tráfico no relacionado y oculta el problema real de clasificación.

Compruebe el camino de vuelta antes de comprometerse

El éxito de salida demuestra la mitad de un diseño. Un paquete que vuelve hacia el conjunto de clientes remotos ya no es visible bajo la dirección del cliente cuando la encapsulación la sustituye: el destino exterior es la dirección de transporte del par. Si el segundo enlace llega a ese par por un operador distinto, su traducción y filtrado pueden discrepar del primero, y la asociación podría necesitar reconstruirse en lugar de migrarse.

El estado de traducción de direcciones de red es la víctima habitual de un cambio de WAN. Anote el enlace elegido, la dirección de origen exterior esperada, la traducción en uso y la accesibilidad del par de vuelta hacia ella, y luego mantenga el transporte accesible sin enviarlo dentro del túnel que transporta.

Verifique ambas capas con dos capturas

Una captura en la interfaz WAN y otra dentro del túnel resuelven la cuestión más rápido que cualquier comparación de configuración. Ejecútelas desde la puerta de enlace mientras un cliente aprobado hace una sola petición, y guarde ambos archivos.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

La primera captura debería mostrar la conversación exterior saliendo de la interfaz que pretendía, con la dirección de origen esperada. La segunda debería mostrar la conversación interior una vez, no duplicada, con la dirección del cliente como origen y el servidor de aplicaciones como destino. La consulta de ruta confirma qué tabla usaría el enrutador para ese par origen y destino, que es donde suele aparecer un error de política. Si alguna captura no aparece, el punto de decisión está en otro sitio distinto de donde se enganchó la regla, y la corrección corresponde allí y no a una coincidencia más amplia.