Dos clientes VPN, dos direcciones públicas: haga que el SNAT coincida

Dos clientes VPN pueden salir por dos direcciones IPv4 públicas distintas, y la regla que lo consigue es más corta de lo que la mayoría espera. Lo que la hace funcionar no es la sintaxis de iptables, sino el estado del paquete cuando llega a la cadena de salida: la dirección de origen que hay allí todavía tiene que distinguir a los clientes. Si un masquerade anterior ya ha unido a ambos en una sola dirección, ninguna regla por cliente puede recuperar la distinción. Resuelva primero esa cuestión y después escriba la traducción.

Qué identidad sobrevive hasta la puerta de enlace

La regla coincide con la dirección de origen del paquete, no con un nombre de usuario VPN ni con el nombre que muestra una aplicación cliente. Todo lo que traduce el paquete antes en el camino decide qué puede ver todavía su regla. Ejecute la tabla nat en orden y encuentre el punto en el que el origen sigue siendo por cliente.

iptables -t nat -S POSTROUTING

Lea ese listado desde arriba. Una regla de masquerade cerca del principio reescribe el origen de cada flujo coincidente, y las entradas por cliente colocadas después coinciden con una dirección que ya no existe. Cuando dos dispositivos LAN comparten un túnel y llegan como una sola dirección interna, el diseño tiene que cambiar antes que el cortafuegos: mantenga sus rangos de origen separados o dé a cada uno su propia dirección interna.

Vincule la asignación de la dirección interna al cliente autenticado. Entregar esa dirección a otro dispositivo entrega también la política de salida, y la traducción de origen no es una prueba de identidad por sí sola.

La traducción no puede inventar una dirección

Cada dirección pública tiene que asignarse o enrutarse a este punto de salida, y las respuestas tienen que encontrar el camino de vuelta. Una regla que envía tráfico desde una dirección a la que nadie enruta de vuelta se descarta en el extremo lejano o se responde a un host que nunca la pidió. Una instancia de proveedor de nube suele tener su dirección pública traducida a una dirección de interfaz privada antes de que el paquete salga, así que el origen del SNAT tiene que ser la dirección que el proveedor aceptará, no el valor que muestra la consola. Lea el modelo de direcciones del proveedor y sígalo en lugar de copiar el valor público en cada paquete.

En la práctica, eso significa comprobar el prefijo enrutado en la consola del proveedor antes de tocar el cortafuegos, y usar la dirección de interfaz privada como origen de la traducción cuando la correspondencia es uno a uno. Las direcciones de los ejemplos siguientes proceden de los rangos de documentación, así que lo primero que hay que sustituir es el propio texto de la dirección.

Inserte antes del masquerade genérico

Confirme la interfaz de salida y la cadena actual antes de añadir nada. La primera decide qué paquetes puede coincidir la regla, y la segunda muestra qué hay ya delante de ella.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

El primer comando nombra la interfaz por la que sale realmente un paquete hacia internet. El segundo imprime la cadena con números de línea. La entrada de masquerade genérica es la línea por encima de la cual hay que quedarse.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Las dos reglas anteriores coinciden con una dirección interna cada una, limitan la coincidencia a la interfaz de salida y fijan el origen explícitamente. Inserte en lugar de añadir: en la posición 1 se evalúan antes de la línea de masquerade. El orden entre ambas no importa porque sus orígenes son distintos. Sustituya ens3 por lo que haya informado el comando de ruta, y mantenga a otros gestores de cortafuegos lejos de los mismos ganchos, ya que dos herramientas que escriben una tabla es la razón habitual de que una regla correcta no tenga efecto.

Demuestre el origen con un flujo nuevo

El NAT con estado vincula una traducción cuando empieza un flujo y la reutiliza para paquetes posteriores, así que una sesión abierta antes del cambio conserva su origen antiguo después del cambio. Solo una conexión iniciada de nuevo demuestra la regla.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Lea la dirección de respuesta de esa entrada: su destino es la dirección que el extremo remoto ve como origen. Compárela con la dirección pública que pretendía, y trate una entrada que lleve la dirección antigua como prueba de un flujo que empezó demasiado pronto, no de una regla rota. Pida al cliente que abra una conexión nueva y luego repita la consulta. Vaciar toda la tabla de seguimiento para forzar la prueba interrumpe todas las demás sesiones de la puerta de enlace.

La traducción sigue sin elegir la ruta, sin admitir el flujo por el filtro y sin publicar un servicio de entrada. Una ruta equivocada y una regla de permiso ausente siguen fallando después de una regla SNAT perfecta. Compruebe también IPv6 y cualquier ruta de salida secundaria, y luego anote los pares interno-a-público en la documentación del cortafuegos, para que el próximo cambio parta de la correspondencia y no del texto de la regla.