¿Qué dirección de origen registrará NGINX para un cliente VPN?

En una instalación de NGINX con OpenVPN en el mismo host aparecen tres direcciones de cliente, una por cada camino que puede tomar una petición. Un navegador que llega a la dirección del túnel, un navegador que llega a la dirección pública y un programa que sale por la ruta de internet de la puerta de enlace se ven distintos en el socket de escucha. Decida qué camino está mirando antes de interpretar la línea del registro. La decisión depende del destino que usó el cliente, de la excepción que mantiene para el extremo externo de la VPN y de si algo traduce el paquete por el camino.

Decida por destino, no por quién es el usuario

Empiece por la dirección a la que se envió la petición, porque esa dirección es la que selecciona el camino. Una petición a la dirección del túnel del host llega por la interfaz del túnel con la dirección interna del cliente como origen. Una petición a la dirección pública del host suele llegar por la interfaz orientada a internet con la dirección pública del cliente, incluso cuando ese mismo portátil tiene un túnel establecido en ese momento. Pertenecer al grupo de la VPN es, por tanto, una propiedad del camino del paquete, no una propiedad que siga al usuario.

Esa tercera fila es la que conviene comprobar primero cuando un usuario de la VPN aparece en el registro con una dirección que no tiene nada que ver con el túnel. También explica por qué dos usuarios con el mismo perfil pueden generar entradas distintas: sus propias redes de acceso son diferentes y nada dentro del túnel lo sobrescribe.

Por qué el extremo externo crea un segundo camino público

El cliente tiene que alcanzar la dirección pública de la puerta de enlace para establecer el túnel, así que debe existir una ruta a esa dirección fuera del túnel. Cuando un cliente redirige todo el tráfico hacia dentro, una implementación sensata mantiene una ruta de host explícita para la dirección pública del servidor, para evitar un túnel que dependa de sí mismo. Esa excepción no distingue entre servicios, de modo que cualquier petición a la misma dirección pública la sigue, incluida una petición de navegador a un sitio alojado en la puerta de enlace.

Este es el mecanismo que hay detrás de la mayoría de los informes confusos en este terreno, y depende de la implementación del cliente y no del servidor. Por eso dos clientes con perfiles idénticos pueden comportarse de forma distinta. Quitar la excepción para »arreglar« el registro se lleva por delante el túnel, así que consérvela y diseñe alrededor de ella.

Lea el socket, la tabla y el formato del registro en conjunto

Tres observaciones resuelven qué camino está mirando: dónde escucha el socket, qué interfaz responde al destino y qué registra realmente el formato del registro. Si el escucha está ligado solo a la dirección del túnel, una petición pública no puede llegar a él en absoluto, lo que descarta dos filas de inmediato. Si la consulta para el cliente devuelve el dispositivo del túnel, la petición llegó con un origen interno y el registro debería mostrarlo.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Después lea el formato en lugar de la línea. Un campo alimentado por una cabecera reenviada registra una afirmación, no un par del socket, y la afirmación solo importa cuando el par inmediato es un proxy de confianza. Escribir ambos valores en el registro zanja discusiones posteriores, porque el par inmediato y la dirección sustituida son hechos distintos y solo uno de ellos vino de la red.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Elija el punto de entrada que quiere y haga que el DNS coincida

Si el sitio debe ser solo por túnel, dele un nombre que para los clientes de la VPN resuelva a la dirección del túnel y aplique la política en el socket de escucha. Una respuesta de DNS dividido que devuelve 10.24.0.1 para el nombre interno es una decisión de encaminamiento disfrazada de detalle de resolución de nombres. Si el sitio también debe ser público, mantenga dos nombres o dos puertos y deje que el registro le diga cuál sirvió la petición.

Las reglas de permitir siguen la misma lógica. Permitir el grupo del túnel no autoriza una petición pública, y no rellenará una dirección interna en una conexión que llegó por internet. Mezclar ambos puntos de entrada bajo un mismo nombre convierte el origen registrado en un efecto secundario del encaminamiento del cliente en lugar de una decisión de diseño.

Verifique el camino y luego la política

Confirme el camino con una captura en la puerta de enlace y una petición que usted controle. Una captura en el dispositivo del túnel y otra en la interfaz pública muestran cuál transportó los bytes, y el orden de los paquetes le dice si hubo una traducción entre ellos.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Luego verifique el acceso en ambos sentidos: la entrada con nombre prevista funciona para el cliente previsto y un camino público no aprobado se rechaza en lugar de ser solo lento. Un sitio genérico de eco de IP demuestra algo sobre la salida a internet de la puerta de enlace y nada sobre este sitio en el mismo host. Cuando una página y un WebSocket no coinciden, compare sus URL, sus familias de direcciones y sus respuestas DNS antes de tocar la configuración del servidor.