Que enderezo de orixe rexistrará NGINX para un cliente VPN?

Nunha instalación de NGINX con OpenVPN no mesmo host aparecen tres enderezos de cliente, un por cada camiño que pode tomar unha solicitude. Un navegador que chega ao enderezo do túnel, un navegador que chega ao enderezo público e un programa que sae pola ruta de internet da pasarela vense distintos no socket de escoita. Decida que camiño está a mirar antes de interpretar a liña do rexistro. A decisión depende do destino que usou o cliente, da excepción que mantén para o extremo externo da VPN e de se algo traduce o paquete polo camiño.

Decida por destino, non por quen é o usuario

Empece polo enderezo ao que se enviou a solicitude, porque ese enderezo é o que selecciona o camiño. Unha solicitude ao enderezo do túnel do host chega pola interface do túnel co enderezo interno do cliente como orixe. Unha solicitude ao enderezo público do host adoita chegar pola interface orientada a internet co enderezo público do cliente, mesmo cando ese mesmo portátil ten un túnel establecido nese momento. Pertencer ao conxunto da VPN é, polo tanto, unha propiedade do camiño do paquete, non unha propiedade que siga ao usuario.

Esa terceira fila é a que convén comprobar primeiro cando un usuario da VPN aparece no rexistro cun enderezo que non ten nada que ver co túnel. Tamén explica por que dous usuarios co mesmo perfil poden xerar entradas distintas: as súas propias redes de acceso son diferentes e nada dentro do túnel o sobrescribe.

Por que o extremo externo crea un segundo camiño público

O cliente ten que acadar o enderezo público da pasarela para establecer o túnel, así que debe existir unha ruta a ese enderezo fóra do túnel. Cando un cliente redirixe todo o tráfico cara a dentro, unha implementación sensata mantén unha ruta de host explícita para o enderezo público do servidor, para evitar un túnel que dependa de si mesmo. Esa excepción non distingue entre servizos, de modo que calquera solicitude ao mesmo enderezo público a segue, incluída unha solicitude de navegador a un sitio aloxado na pasarela.

Este é o mecanismo que hai detrás da maioría dos informes confusos neste eido, e depende da implementación do cliente e non do servidor. Por iso dous clientes con perfís idénticos poden comportarse de forma distinta. Quitar a excepción para »arranxar« o rexistro leva consigo o túnel, así que consérvea e deseñe arredor dela.

Lea o socket, a táboa e o formato do rexistro en conxunto

Tres observacións resolven que camiño está a mirar: onde escoita o socket, que interface responde ao destino e que rexistra realmente o formato do rexistro. Se o escoitador está ligado só ao enderezo do túnel, unha solicitude pública non pode chegar a el de ningún xeito, o que descarta dúas filas de inmediato. Se a consulta para o cliente devolve o dispositivo do túnel, a solicitude chegou cunha orixe interna e o rexistro debería mostralo.

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

Despois lea o formato en lugar da liña. Un campo alimentado por unha cabeceira reenviada rexistra unha afirmación, non un par do socket, e a afirmación só importa cando o par inmediato é un proxy de confianza. Escribir ambos os valores no rexistro remata discusións posteriores, porque o par inmediato e o enderezo substituído son feitos distintos e só un deles veu da rede.

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

Escolla o punto de entrada que quere e faga que o DNS coincida

Se o sitio debe ser só por túnel, déalle un nome que para os clientes da VPN resolva ao enderezo do túnel e aplique a política no socket de escoita. Unha resposta de DNS dividido que devolve 10.24.0.1 para o nome interno é unha decisión de encamiñamento disfrazada de detalle de resolución de nomes. Se o sitio tamén debe ser público, manteña dous nomes ou dous portos e deixe que o rexistro lle diga cal serviu a solicitude.

As regras de permitir seguen a mesma lóxica. Permitir o conxunto do túnel non autoriza unha solicitude pública, e non encherá un enderezo interno nunha conexión que chegou por internet. Mesturar ambos os puntos de entrada baixo un mesmo nome converte a orixe rexistrada nun efecto secundario do encamiñamento do cliente en lugar dunha decisión de deseño.

Verifique o camiño e despois a política

Confirme o camiño cunha captura na pasarela e unha solicitude que vostede controle. Unha captura no dispositivo do túnel e outra na interface pública mostran cal transportou os bytes, e a orde dos paquetes dille se houbo unha tradución entre eles.

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

Logo verifique o acceso en ambos os sentidos: a entrada con nome prevista funciona para o cliente previsto e un camiño público non aprobado rexéitase en lugar de ser só lento. Un sitio xenérico de eco de IP demostra algo sobre a saída a internet da pasarela e nada sobre este sitio no mesmo host. Cando unha páxina e un WebSocket non coinciden, compare as súas URL, as súas familias de enderezos e as súas respostas DNS antes de tocar a configuración do servidor.