Hvilken kildeadresse logger NGINX for en VPN-klient?

Tre klientadresser dukker opp i et NGINX- og OpenVPN-oppsett på samme vert, én for hver vei en forespørsel kan ta. En nettleser som treffer tunneladressen, en nettleser som treffer den offentlige adressen og et program som går ut via gatewayens internettvei ser alle ulike ut ved den lyttende socketen. Avgjør hvilken vei du ser på før du tolker logglinjen. Avgjørelsen avhenger av hvilket mål klienten brukte, hvilket unntak den har for den ytre VPN-endepunktet, og om noe oversetter pakken på veien.

Avgjør etter mål, ikke etter hvem brukeren er

Begynn med adressen forespørselen ble sendt til, fordi den adressen velger veien. En forespørsel til vertens tunneladresse kommer inn på tunnelgrensesnittet med klientens indre adresse som kilde. En forespørsel til vertens offentlige adresse kommer vanligvis inn på grensesnittet som vender mot internett, med klientens offentlige adresse, også når samme bærbare datamaskin har en tunnel opprettet i det øyeblikket. Medlemskap i VPN-bassenget er derfor en egenskap ved pakkens vei, ikke en egenskap som følger brukeren.

Nettopp denne tredje raden er verdt å sjekke først når en VPN-bruker dukker opp i loggen med en adresse som ikke har noe med tunnelen å gjøre. Den forklarer også hvorfor to brukere med samme profil kan gi ulike oppføringer: deres egne tilgangsnett er ulike, og ingenting i tunnelen skriver over det.

Hvorfor det ytre endepunktet lager en andre offentlig vei

Klienten må nå gatewayens offentlige adresse for å opprette tunnelen, så det må finnes en rute til den adressen utenfor tunnelen. Når en klient omdirigerer all trafikk innover, holder en fornuftig implementasjon en eksplisitt vertsrute til serverens offentlige adresse for å unngå en tunnel som er avhengig av seg selv. Det unntaket er ikke selektivt med hensyn til tjenester, så enhver forespørsel til den samme offentlige adressen følger det, også en nettleserforespørsel til et nettsted som hostes på gatewayen.

Dette er mekanismen bak de fleste forvirrende rapportene på dette feltet, og den ligger i klientimplementasjonen og ikke i serveren. To klienter med identiske profiler kan derfor oppføre seg ulikt. Fjerner man unntaket for å »reparere« loggen, faller tunnelen med, så behold det og design rundt det.

Les socketen, tabellen og loggformatet sammen

Tre observasjoner avgjør hvilken vei du ser på: hvor socketen lytter, hvilket grensesnitt som svarer på målet, og hva loggformatet faktisk registrerer. Hvis lytteren bare er bundet til tunneladressen, kan en offentlig forespørsel ikke nå den i det hele tatt, noe som straks utelukker to rader. Hvis oppslaget for klienten returnerer tunnel-enheten, kom forespørselen inn med en indre kilde, og loggen burde vise det.

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

Les deretter formatet i stedet for linjen. Et felt som fôres av en videresendt header, registrerer en påstand, ikke en socket-peer, og påstanden teller bare når den nærmeste peeren er en klarert proxy. Å skrive begge verdiene i loggen avgjør senere diskusjoner, fordi den nærmeste peeren og den erstattede adressen er forskjellige fakta og bare én av dem kom fra nettet.

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

Velg inngangspunktet du vil ha og få DNS til å stemme

Hvis nettstedet skal være bare via tunnelen, gi det et navn som for VPN-klienter løses ut til tunneladressen, og håndhev policy på den lyttende socketen. Et delt DNS-svar som returnerer 10.24.0.1 for det interne navnet, er et rutingsvalg i kostyme av en detalj om navneoppslag. Hvis nettstedet også må være offentlig, behold to navn eller to porter og la loggen si hvilken som betjente forespørselen.

Tillatelsesregler følger samme logikk. Å tillate tunnelbassenget gir ikke rett til en offentlig forespørsel, og det fyller ikke ut en indre adresse på en tilkobling som kom over internett. Å blande begge inngangspunktene under ett navn gjør den registrerte kilden til en bivirkning av klientrutingen i stedet for et designvalg.

Verifiser veien, deretter policyen

Bekreft veien med en fangst på gatewayen og en forespørsel du kontrollerer. En fangst på tunnel-enheten og en på det offentlige grensesnittet viser hvilken som bar bytene, og rekkefølgen på pakkene forteller om det skjedde en oversettelse mellom dem.

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

Verifiser deretter tilgang i begge retninger: det tiltenkte navngitte inngangspunktet virker for den tiltenkte klienten, og en ikke-godkjent offentlig vei avvises i stedet for bare å være treg. Et generelt IP-ekko-nettsted beviser noe om gatewayens internettutgang og ingenting om dette nettstedet på samme vert. Når en side og en WebSocket er uenige, sammenlign URL-ene, adressefamiliene og DNS-svarene deres før du rører ved serverkonfigurasjonen.