Koju će izvornu adresu NGINX zabilježiti za VPN klijenta?

U instalaciji NGINX-a i OpenVPN-a na istom hostu pojavljuju se tri klijentske adrese, po jedna za svaki put kojim zahtjev može ići. Preglednik koji dolazi na adresu tunela, preglednik koji dolazi na javnu adresu i program koji izlazi preko internetskog puta pristupnika izgledaju različito na socketu koji sluša. Odlučite koji put gledate prije nego što protumačite liniju loga. Odluka zavisi od odredišta koje je klijent koristio, od izuzetka koji ima za vanjsku VPN krajnju točku i od toga da li nešto prevodi paket na putu.

Odlučite po odredištu, ne po tome ko je korisnik

Počnite od adrese na koju je zahtjev poslan, jer ta adresa bira put. Zahtjev na adresu tunela hosta dolazi na sučelje tunela s unutrašnjom adresom klijenta kao izvorom. Zahtjev na javnu adresu hosta obično dolazi na sučelje okrenuto internetu s javnom adresom klijenta, čak i kada isti prijenosnik u tom trenutku ima uspostavljen tunel. Članstvo u VPN bazenu je zato svojstvo puta paketa, a ne svojstvo koje slijedi korisnika.

Upravo je taj treći red onaj koji prvo vrijedi provjeriti kada se u logu pojavi VPN korisnik s adresom koja nema nikakve veze s tunelom. To objašnjava i zašto dva korisnika na istom profilu mogu dati različite zapise: njihove vlastite pristupne mreže se razlikuju i ništa u tunelu to ne prepisuje.

Zašto vanjska krajnja točka stvara drugi javni put

Klijent mora doći do javne adrese pristupnika da bi uspostavio tunel, pa ruta do te adrese mora postojati izvan tunela. Kada klijent preusmjeri sav promet prema unutra, razumna implementacija zadržava izričitu rutu hosta prema javnoj adresi poslužitelja kako bi izbjegla tunel koji zavisi sam od sebe. Taj izuzetak nije selektivan prema uslugama, pa ga slijedi svaki zahtjev na istu javnu adresu, uključujući zahtjev preglednika na stranicu hostanu na pristupniku.

To je mehanizam iza većine zbunjujućih izvještaja u ovom području i zavisi od implementacije klijenta, a ne poslužitelja. Dva klijenta s identičnim profilima zato se mogu ponašati različito. Uklanjanje izuzetka da bi se log »popravio« ruši i tunel, pa ga zadržite i projektirajte oko njega.

Čitajte socket, tablicu i format loga zajedno

Tri zapažanja odlučuju koji put gledate: gdje socket sluša, koje sučelje odgovara odredištu i šta format loga zaista bilježi. Ako je slušalac vezan samo za adresu tunela, javni zahtjev ga uopće ne može dosegnuti, što odmah isključuje dva reda. Ako pretraga za klijenta vrati uređaj tunela, zahtjev je stigao s unutrašnjim izvorom i log bi to trebao pokazati.

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

Zatim čitajte format, a ne red. Polje koje napaja proslijeđeno zaglavlje bilježi tvrdnju, a ne socket partnera, i tvrdnja je važna samo kada je neposredni partner pouzdani proxy. Upisivanje obje vrijednosti u log rješava kasnije rasprave, jer su neposredni partner i zamijenjena adresa različite činjenice i samo jedna od njih je došla s mreže.

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

Odaberite željenu ulaznu točku i uskladite DNS

Ako stranica treba biti samo preko tunela, dajte joj ime koje se VPN klijentima razrješava na adresu tunela i provodite politiku na socketu koji sluša. Odgovor podijeljenog DNS-a koji vraća 10.24.0.1 za interno ime je odluka o rutiranju prerušena u detalj razrješavanja imena. Ako stranica mora biti i javna, zadržite dva imena ili dva porta i pustite log da kaže koja je usluga poslužila zahtjev.

Pravila dopuštanja slijede istu logiku. Dopuštanje VPN bazena ne ovlašćuje javni zahtjev i neće popuniti unutrašnju adresu na vezi koja je došla preko interneta. Miješanje obje ulazne točke pod jednim imenom pretvara zabilježeni izvor u nuspojavu rutiranja klijenta umjesto dizajnerskog izbora.

Provjerite put, pa politiku

Potvrdite put snimkom na pristupniku i zahtjevom koji kontrolirate. Snimka na uređaju tunela i jedna na javnom sučelju pokazuju koja je nosila bajtove, a redoslijed paketa vam kaže da li se između njih dogodilo prevođenje.

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

Zatim provjerite pristup u oba smjera: namjeravana imenovana ulazna točka radi za namjeravanog klijenta, a neodobreni javni put se odbija, a ne samo da je spor. Opća web stranica s odjekom IP-a dokazuje nešto o internetskom izlazu pristupnika i ništa o ovoj stranici na istom hostu. Kada se stranica i WebSocket ne slažu, uporedite njihove URL-ove, porodice adresa i DNS odgovore prije nego što dirate konfiguraciju poslužitelja.