SoftEther SecureNAT: DHCP y NAT son dos decisiones

SecureNAT es una sola casilla que activa dos servicios, y de ahí viene la mayor parte de la confusión que lo rodea. Un servidor DHCP virtual entrega al cliente una dirección, una máscara, una puerta de enlace y a menudo un resolutor. Un NAT virtual reenvía paquetes más allá de esa puerta de enlace usando la propia pila de red del host del servidor. Ambos conviven en la configuración y fallan de forma independiente: un cliente puede tener una concesión perfecta y ninguna ruta funcional, o una ruta funcional con ajustes que apuntan al resolutor equivocado. Verifícalos como dos decisiones y el diagnóstico se vuelve corto.

Dos servicios detrás de una casilla

El lado del DHCP virtual responde a una pregunta de configuración: qué ajustes recibe este cliente dentro de este concentrador virtual. El lado del NAT virtual responde a una pregunta de reenvío: cuando un cliente envía un paquete a una dirección fuera del concentrador, el servidor lo traduce y lo reenvía. Lo primero es local al concentrador y no necesita ninguna red aguas arriba. Lo segundo depende por completo del host.

La interfaz de host virtual pertenece a la primera decisión, no a la segunda. Su dirección, a menudo algo como 192.168.30.1 por defecto, es la puerta de enlace que ofrece el servicio DHCP. No es la dirección pública de escucha del servidor, y confundir ambas produce reglas de cortafuegos y ajustes de cliente dirigidos a una máquina que no existe en esa red.

Decisión 1: quién suministra la dirección

Si el DHCP virtual está activado, los clientes deberían recibir una concesión en el grupo que hayas configurado, con la interfaz de host virtual como puerta de enlace y el resolutor que hayas proporcionado. Inspecciona la concesión y no el texto de estado del cliente, porque «conectado» describe el túnel y no la asignación de dirección:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Merece la pena conocer dos modos de fallo antes de depurar cualquier otra cosa. Un cliente con una dirección estática residual de un diseño anterior la conservará e ignorará la concesión, lo que parece que el DHCP se niega a responder. Y un segundo origen DHCP en un segmento puenteado competirá por los mismos clientes, lo que produce direcciones intermitentes y una cola de soporte que no puede reproducir el problema.

Los grupos superpuestos también tienen cabida aquí. Si el grupo del DHCP virtual se superpone a la subred LAN del host o al grupo de otro concentrador, el cliente recibe una dirección que enruta de forma ambigua, y cada prueba posterior es inconcluyente.

Decisión 2: quién reenvía más allá de la puerta de enlace virtual

Con el NAT virtual activado, el tráfico de salida del concentrador lo traduce el servidor y se envía por la tabla de enrutamiento del host. Eso significa que la cadena de reenvío es: cliente a puerta de enlace virtual, NAT virtual a pila del host, pila del host a su ruta por defecto. Cada eslabón puede fallar sin tocar a los demás, y las firmas de fallo son distintas.

Prueba la segunda decisión con algo que deba salir del concentrador, no con algo local a él. Hacer ping a la puerta de enlace virtual demuestra el primer eslabón y nada más:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Si la resolución de nombres funciona pero las conexiones a una dirección pública fallan, estás en la cadena de reenvío y no en el DHCP. Si fallan ambas, comprueba primero el resolutor, porque un resolutor empujado como dirección interna inalcanzable hará que una ruta funcional parezca completamente rota.

El reenvío de SecureNAT lo implementa el proceso del servidor, no la ruta de reenvío del núcleo que usarías con un puente. Eso es cómodo y más lento que puentear, y también significa que las reglas de cortafuegos y las decisiones de enrutamiento del host siguen aplicándose al tráfico traducido. El NAT virtual no elude la política del host; la utiliza.

La ruta propia del host es una tercera cosa

Todo lo anterior presupone que el host del servidor puede alcanzar el destino. Un host sin ruta funcional aguas arriba, con una política de salida restrictiva o con una familia de direcciones que no tiene fallará la segunda decisión por correcta que sea la configuración del concentrador. Comprueba el host por separado, fuera del túnel, antes de atribuir su fallo a SoftEther.

SecureNAT tampoco es una autorización para alcanzar cada red conectada al servidor. Traduce y reenvía el tráfico que llega hasta él; decidir a qué puede llegar el host sigue siendo trabajo del cortafuegos y del enrutamiento del host, y un diseño que confía en el túnel para conceder acceso está a una regla mala de conceder demasiado.

Las familias de direcciones merecen su propia comprobación. Un ejemplo de DHCP IPv4 que funciona no demuestra que toda capacidad IPv6 esté presente en tu compilación, así que lee el manual de la versión que realmente ejecutas antes de prometer comportamiento de doble pila. La sección SecureNAT del manual cubre las funciones de NAT y DHCP virtuales para la versión actual.

Verifica cada decisión con su propia prueba

Acepta la primera decisión con una comprobación de la concesión: dirección en el grupo, puerta de enlace igual a la interfaz de host virtual, resolutor el que configuraste. Acepta la segunda con una petición de salida desde el cliente y un vistazo a la tabla NAT del servidor, porque un recuento de sesiones creciente es la única evidencia directa de que la traducción ocurre y no solo de que está activada.

Después anota la separación en la nota de diseño: qué componente suministra la dirección, qué componente reenvía y por qué interfaz de host sale el tráfico. Cuando un reinicio cambie el comportamiento, esa nota te dice cuál de los tres inspeccionar en lugar de reiniciarlo todo y esperar que el síntoma se mueva.

Una decisión más pertenece al registro, aunque hoy no la tomes: SecureNAT y un puente local son diseños distintos para el mismo concentrador, y un concentrador que necesita ambos es un concentrador que necesita otro plan. Elige a conciencia, escribe por qué, y la siguiente persona no tendrá que hacer ingeniería inversa a partir de una configuración en marcha.