Hvilken kildeadresse logger NGINX for en VPN-klient?

Tre klientadresser dukker op i et NGINX-plus-OpenVPN-opsætning på samme vært, én for hver vej en anmodning kan tage. En browser, der rammer tunneladressen, en browser, der rammer den offentlige adresse, og et program, der forlader gennem gatewayens internetvej, ser alle forskellige ud ved den lyttende socket. Afgør, hvilken vej du ser på, før du fortolker loglinjen. Beslutningen afhænger af den destination, klienten brugte, den undtagelse den har for VPN'ens ydre endepunkt, og om noget oversætter pakken undervejs.

Afgør efter destination, ikke efter hvem brugeren er

Begynd med den adresse, anmodningen blev sendt til, fordi den adresse vælger vejen. En anmodning til værtens tunneladresse ankommer på tunnelinterfacet med klientens indre adresse som kilde. En anmodning til værtens offentlige adresse ankommer normalt på det internetvendte interface med klientens offentlige adresse, selv når den samme bærbare computer har en tunnel etableret i det øjeblik. Medlemskab af VPN-puljen er derfor en egenskab ved pakkens vej, ikke en egenskab, der følger brugeren.

Det er den tredje række, der er værd at tjekke først, når en VPN-bruger dukker op i loggen med en adresse, der intet har med tunnelen at gøre. Det forklarer også, hvorfor to brugere på samme profil kan give forskellige poster: deres egne adgangsnetværk er forskellige, og intet i tunnelen overskriver det.

Hvorfor det ydre endepunkt skaber en anden offentlig vej

Klienten skal nå gatewayens offentlige adresse for at etablere tunnelen, så der skal findes en rute til den adresse uden for tunnelen. Når en klient omdirigerer al trafik indad, holder en fornuftig implementering en eksplicit værtsrute til serverens offentlige adresse for at undgå en tunnel, der afhænger af sig selv. Den undtagelse er ikke selektiv med hensyn til tjenester, så enhver anmodning til den samme offentlige adresse følger den, inklusive en browseranmodning til et websted, der hostes på gatewayen.

Det er mekanismen bag de fleste forvirrende rapporter på dette område, og den er pr. klientimplementering snarere end pr. server. To klienter med identiske profiler kan derfor opføre sig forskelligt. Fjerner man undtagelsen for at »rette« loggen, tager man tunnelen med ned, så behold den og design omkring den.

Læs socket, tabel og logformat sammen

Tre observationer afgør, hvilken vej du ser på: hvor socket lytter, hvilket interface der svarer på destinationen, og hvad logformatet faktisk registrerer. Hvis lytteren kun er bundet til tunneladressen, kan en offentlig anmodning slet ikke nå den, hvilket udelukker to rækker med det samme. Hvis opslaget for klienten returnerer tunnelenheden, ankom anmodningen med en indre kilde, og loggen bør vise det.

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

Læs derefter formatet i stedet for linjen. Et felt, der fodres af en videresendt header, registrerer et krav, ikke en socket-peer, og kravet betyder kun noget, når den umiddelbare peer er en betroet proxy. At skrive begge værdier i loggen afgør senere diskussioner, fordi den umiddelbare peer og den erstattede adresse er forskellige fakta, og kun én af dem kom fra netværket.

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

Vælg det indgangspunkt, du vil have, og få DNS til at være enig

Hvis webstedet skal være kun via tunnel, giv det et navn, der for VPN-klienter opløses til tunneladressen, og håndhæv politik på den lyttende socket. Et split-DNS-svar, der returnerer 10.24.0.1 for det interne navn, er en rutningsbeslutning i forklædning af en detalje om navneopløsning. Hvis webstedet også skal være offentligt, behold to navne eller to porte, og lad loggen fortælle, hvilken der betjente anmodningen.

Allow-regler følger samme logik. At tillade tunnelpuljen autoriserer ikke en offentlig anmodning, og det udfylder ikke en indre adresse på en forbindelse, der ankom over internettet. At blande begge indgangspunkter under ét navn gør den registrerede kilde til en bivirkning af klientrutning i stedet for et designvalg.

Verificér vejen, derefter politikken

Bekræft vejen med en optagelse på gatewayen og en anmodning, du kontrollerer. En optagelse på tunnelenheden og en på det offentlige interface viser, hvilken der bar byteene, og pakkernes rækkefølge fortæller, om der skete en oversættelse mellem dem.

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

Verificér derefter adgang i begge retninger: det tilsigtede navngivne indgangspunkt virker for den tilsigtede klient, og en ikke-godkendt offentlig vej afvises i stedet for blot at være langsom. Et generisk IP-echo-websted beviser noget om gatewayens internetudgang og intet om dette websted på samme vært. Når en side og en WebSocket er uenige, sammenlign deres URL'er, adressefamilier og DNS-svar, før du rører ved serverkonfigurationen.