¿Una NIC o dos? Cómo decidir la disposición de interfaces de un servidor VPN

Un solo adaptador físico basta para muchos servidores VPN, y tampoco es un diseño universal. La conexión cifrada llega a ese adaptador, el proceso VPN la descifra y el tráfico interno sale por una interfaz virtual antes de llegar a un servicio local o a una LAN enrutada. Que eso funcione depende de tres condiciones: dónde vive el destino, si la LAN tiene un camino de vuelta al conjunto de clientes y si un enlace físico compartido le da el aislamiento que afirma. Responda esas tres y el número de adaptadores se sigue solo.

Las tres condiciones que lo deciden

La primera condición es el destino. Un servicio en el propio host VPN se alcanza solo por la interfaz del túnel, mientras que un host en la LAN requiere reenvío y un camino de vuelta. La segunda condición es ese camino de vuelta, porque el dispositivo de la LAN tiene que saber cómo llegar al conjunto de clientes, sea por una ruta o por traducción en el servidor.

La tercera condición es la separación. Un adaptador significa que cada paquete, cifrado o no, comparte un enlace y normalmente una cadena de políticas, así que una afirmación de aislamiento que depende de hardware separado no la satisface una sola interfaz. Eso es un hecho sobre el camino, no sobre cómo está configurado el sistema operativo. Aún puede filtrar el tráfico del túnel, pero no puede afirmar una frontera que no tiene.

Ninguna de las tres trata del número de puertos del chasis. Tratan del enrutamiento, de la propiedad de las direcciones y de cuánto depende el diseño de la separación física.

Dos adaptadores siguen siendo una opción legítima cuando zonas físicas, enlaces ascendentes separados, rendimiento o un camino de recuperación fuera de banda lo justifican. Son requisitos concretos, y vale la pena decirlos antes de que alguien pida hardware.

Cuando el servicio se ejecuta en el host VPN

El caso más simple no necesita ningún reenvío. El demonio recibe los paquetes del cliente en la interfaz del túnel y los entrega a un socket local, y la respuesta vuelve por la misma interfaz. La dirección del conjunto de clientes es una dirección local real desde el punto de vista del host.

Dos cosas siguen teniendo que estar bien: el servicio debe escuchar en una dirección que el túnel pueda alcanzar, y el cortafuegos del host debe aceptar el tráfico que llega a la interfaz del túnel. Ambas son visibles en los comandos de abajo.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Vincular un servicio solo a la dirección pública, o filtrar la interfaz del túnel por error, produce una conexión que llega al host y luego muere. Eso parece un fallo de VPN y normalmente es una decisión de socket o de cortafuegos.

Cuando el destino está en la LAN

Aquí es donde un diseño de un solo adaptador se gana su fama de delicado. El servidor tiene que reenviar los paquetes del cliente hacia la LAN, y el dispositivo de la LAN tiene que enviar las respuestas de vuelta al conjunto de clientes. O lleva ese conjunto como una ruta en la LAN, o traduce la dirección de origen en el servidor para que las respuestas vuelvan al propio servidor.

Ambas respuestas son legítimas y fallan de forma distinta. Una ruta de vuelta mantiene la dirección original del cliente visible para el destino, lo cual es bueno para los registros y malo para reglas de cortafuegos que suponen direcciones de LAN. La traducción mantiene la LAN simple y oculta la identidad del cliente al destino.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Un camino asimétrico es el síntoma clásico: llega la petición del cliente, la respuesta sale por otro enrutador y la conexión expira sin ningún error en ninguno de los dos extremos. Capture en ambos lados antes de concluir nada sobre el túnel.

Por qué un alias no crea una segunda zona

Añadir una segunda dirección al mismo adaptador, o crear una interfaz ficticia para imitar un segundo puerto, cambia muy poco. Los paquetes siguen saliendo por el mismo enlace físico, el mismo puerto del conmutador y normalmente la misma cadena de cortafuegos, así que no existe una frontera nueva entre ellos. Es comodidad de configuración, no segmentación. Tratarlo como una frontera de zona es la forma en que una afirmación de aislamiento sobrevive solo en el papel.

Una zona separada necesita una separación real en el camino, y ese es el requisito que satisface un segundo adaptador. Si una regla depende de que el tráfico orientado a VPN nunca comparta un dominio de difusión con el tráfico orientado a LAN, un solo cable no puede ofrecer esa propiedad, por mucho que se direccione el host.

Donde un producto documenta una topología multiinterfaz para un modo concreto, siga la documentación de ese producto en lugar de inventar una solución alternativa. Los proveedores también cambian sus topologías admitidas entre versiones, otra razón para leer la guía actual y no una captura antigua del asistente.

Compruebe la disposición contra el tráfico que permite

Enumere las clases de tráfico que el servidor debe transportar: cliente a host, cliente a LAN, host a LAN y la conexión exterior cifrada. Cada clase tiene un origen, un destino y una interfaz, y la disposición tiene que satisfacer las cuatro a la vez. Un diseño que resuelve tres de ellas suele ser el que genera tiques.

Después confirme las interfaces reales y la captura real, no el diagrama del documento de diseño. Los comandos de abajo imprimen ambas vistas.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Si la captura exterior muestra el tráfico cifrado y la captura interior muestra el tráfico descifrado en la interfaz del túnel mientras el adaptador físico transporta ambos, una sola NIC hace el trabajo. Si la captura interior está vacía, el problema está en el túnel o en las reglas de reenvío, no en el número de adaptadores. Decida la topología a partir de esas dos capturas y de la tabla de enrutamiento, y el próximo cambio tendrá con qué medirse.