Quina adreça d'origen registrarà NGINX per a un client VPN?

Tres adreces de client apareixen en una instal·lació d'NGINX i OpenVPN al mateix amfitrió, una per a cada camí que pot seguir una sol·licitud. Un navegador que arriba a l'adreça del túnel, un navegador que arriba a l'adreça pública i un programa que surt pel camí d'internet de la passarel·la es veuen diferents al sòcol d'escolta. Decidiu quin camí esteu mirant abans d'interpretar la línia de registre. La decisió depèn de la destinació que va fer servir el client, de l'excepció que manté per al punt final extern de la VPN i de si alguna cosa tradueix el paquet pel camí.

Decidiu per destinació, no per qui és l'usuari

Comenceu per l'adreça a la qual es va enviar la sol·licitud, perquè aquesta adreça és la que selecciona el camí. Una sol·licitud a l'adreça del túnel de l'amfitrió arriba per la interfície del túnel amb l'adreça interna del client com a origen. Una sol·licitud a l'adreça pública de l'amfitrió normalment arriba per la interfície orientada a internet amb l'adreça pública del client, fins i tot quan el mateix portàtil té un túnel establert en aquell moment. Per tant, pertànyer a la piscina de la VPN és una propietat del camí del paquet, no una propietat que segueixi l'usuari.

Aquesta tercera fila és la primera que val la pena comprovar quan un usuari de la VPN apareix al registre amb una adreça que no té res a veure amb el túnel. També explica per què dos usuaris amb el mateix perfil poden produir entrades diferents: les seves pròpies xarxes d'accés són diferents i res del túnel no ho sobreescriu.

Per què el punt final extern crea un segon camí públic

El client ha d'arribar a l'adreça pública de la passarel·la per establir el túnel, així que ha d'existir una ruta cap a aquesta adreça fora del túnel. Quan un client redirigeix tot el trànsit cap a dins, una implementació sensata manté una ruta d'amfitrió explícita per a l'adreça pública del servidor per evitar un túnel que depengui de si mateix. Aquesta excepció no és selectiva pel que fa als serveis, de manera que qualsevol sol·licitud a la mateixa adreça pública la segueix, incloent-hi una sol·licitud de navegador a un lloc allotjat a la passarel·la.

Aquest és el mecanisme darrere de la majoria d'informes confusos en aquest àmbit, i és per implementació de client i no per servidor. Per tant, dos clients amb perfils idèntics poden comportar-se de manera diferent. Treure l'excepció per »arreglar« el registre s'endú el túnel amb ella, així que manteniu-la i dissenyeu al voltant.

Llegiu el sòcol, la taula i el format del registre alhora

Tres observacions resolen quin camí esteu mirant: on escolta el sòcol, quina interfície respon a la destinació i què registra realment el format del registre. Si l'oient només està lligat a l'adreça del túnel, una sol·licitud pública no hi pot arribar de cap manera, cosa que descarta dues files immediatament. Si la consulta per al client retorna el dispositiu del túnel, la sol·licitud va arribar amb un origen intern i el registre ho hauria de mostrar.

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

Després llegiu el format en lloc de la línia. Un camp alimentat per una capçalera reenviada registra una afirmació, no un parell del sòcol, i l'afirmació només importa quan el parell immediat és un servidor intermediari de confiança. Escriure tots dos valors al registre resol disputes posteriors, perquè el parell immediat i l'adreça substituïda són fets diferents i només un d'ells va venir de la xarxa.

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

Trieu el punt d'entrada que voleu i feu que el DNS hi estigui d'acord

Si el lloc ha de ser només per túnel, doneu-li un nom que per als clients de la VPN es resolgui a l'adreça del túnel i apliqueu la política al sòcol d'escolta. Una resposta DNS dividida que retorna 10.24.0.1 per al nom intern és una decisió d'encaminament disfressada de detall de resolució de noms. Si el lloc també ha de ser públic, manteniu dos noms o dos ports i deixeu que el registre us digui quin ha servit la sol·licitud.

Les regles d'allow segueixen la mateixa lògica. Permetre la piscina del túnel no autoritza una sol·licitud pública, i no omplirà una adreça interna en una connexió que va arribar per internet. Barrejar tots dos punts d'entrada sota un sol nom converteix l'origen registrat en un efecte secundari de l'encaminament del client en lloc d'una decisió de disseny.

Verifiqueu el camí i després la política

Confirmeu el camí amb una captura a la passarel·la i una sol·licitud que controlem. Una captura al dispositiu del túnel i una a la interfície pública mostren quin ha portat els bytes, i l'ordre dels paquets us diu si hi va haver una traducció entremig.

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

A continuació verifiqueu l'accés en tots dos sentits: l'entrada amb nom prevista funciona per al client previst, i un camí públic no aprovat es rebutja en lloc de ser només lent. Un lloc web genèric d'eco d'IP demostra una cosa sobre la sortida a internet de la passarel·la i res sobre aquest lloc al mateix amfitrió. Quan una pàgina i un WebSocket no coincideixen, compareu-ne les URL, les famílies d'adreces i les respostes DNS abans de tocar la configuració del servidor.