Ktorú zdrojovú adresu zapíše NGINX pre klienta VPN?

Rozhodnite, čo NGINX vidí vedľa OpenVPN na jednom hostiteľovi: vnútornú adresu tunela, verejnú výstupnú adresu alebo preposlaný protiľahlý bod, podľa zvolenej cesty.

V inštalácii NGINX a OpenVPN na tom istom hostiteľovi sa objavujú tri adresy klienta, jedna pre každú cestu, ktorou môže požiadavka ísť. Prehliadač, ktorý ide na adresu tunela, prehliadač, ktorý ide na verejnú adresu, a program, ktorý vychádza cez internetovú cestu brány, vyzerajú na počúvajúcom sockete odlišne. Skôr než vyložíte riadok logu, rozhodnite, na ktorú cestu sa pozeráte. Rozhodnutie závisí od cieľa, ktorý klient použil, od výnimky, ktorú má pre vonkajší koncový bod VPN, a od toho, či niečo paket po ceste prekladá.

Rozhodujte podľa cieľa, nie podľa toho, kto je používateľ

Začnite adresou, na ktorú bola požiadavka odoslaná, pretože táto adresa volí cestu. Požiadavka na adresu tunela hostiteľa prichádza na rozhranie tunela s vnútornou adresou klienta ako zdrojom. Požiadavka na verejnú adresu hostiteľa zvyčajne prichádza na rozhranie obrátené do internetu s verejnou adresou klienta, aj keď má ten istý notebook v tej chvíli tunel nadviazaný. Členstvo v pule VPN je preto vlastnosťou cesty paketu, nie vlastnosťou, ktorá nasleduje používateľa.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Práve tento tretí riadok stojí za to skontrolovať najskôr, keď sa v logu objaví používateľ VPN s adresou, ktorá s tunelom nemá nič spoločné. Vysvetľuje aj to, prečo dvaja používatelia s rovnakým profilom môžu vytvoriť rôzne záznamy: ich vlastné prístupové siete sa líšia a nič v tuneli to neprepisuje.

Prečo vonkajší koncový bod vytvára druhú verejnú cestu

Klient sa musí dostať na verejnú adresu brány, aby tunel nadviazal, takže trasa k tejto adrese musí existovať mimo tunela. Keď klient presmeruje všetku prevádzku dovnútra, rozumná implementácia si ponechá explicitnú trasu hostiteľa k verejnej adrese servera, aby sa vyhla tunelu, ktorý závisí od seba samého. Táto výnimka nie je voči službám selektívna, takže ju nasleduje každá požiadavka na tú istú verejnú adresu, vrátane požiadavky prehliadača na web hostovaný na bráne.

To je mechanizmus za väčšinou mätúcich hlásení v tejto oblasti a je daný implementáciou klienta, nie servera. Dvaja klienti s rovnakými profilmi sa preto môžu správať odlišne. Odstránenie výnimky, aby ste log »opravili«, so sebou strhne aj tunel, takže ju ponechajte a navrhnite riešenie okolo nej.

Čítajte socket, tabuľku a formát logu spolu

Tri pozorovania rozhodnú, na ktorú cestu sa pozeráte: kde socket počúva, ktoré rozhranie odpovedá cieľu a čo formát logu skutočne zaznamenáva. Ak je počúvajúci proces viazaný iba na adresu tunela, verejná požiadavka sa k nemu vôbec nedostane, čo hneď vylučuje dva riadky. Ak vyhľadanie pre klienta vráti zariadenie tunela, požiadavka dorazila s vnútorným zdrojom a log by to mal ukázať.

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

Potom čítajte formát, nie riadok. Pole plnené preposlanou hlavičkou zaznamenáva tvrdenie, nie protiľahlý bod socketu, a tvrdenie má význam len vtedy, keď je bezprostredný protiľahlý bod dôveryhodný proxy server. Zápis oboch hodnôt do logu ukončí neskoršie spory, pretože bezprostredný protiľahlý bod a nahradená adresa sú rôzne skutočnosti a len jedna z nich prišla zo siete.

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

Zvoľte vstupný bod, ktorý chcete, a zlaďte DNS

Ak má byť web dostupný len cez tunel, dajte mu názov, ktorý sa klientom VPN prekladá na adresu tunela, a vynucujte politiku na počúvajúcom sockete. Odpoveď split-DNS vracajúca 10.24.0.1 pre interný názov je rozhodnutie o smerovaní v prestrojení za detail prekladu názvov. Ak má byť web aj verejný, ponechajte dva názvy alebo dva porty a nechajte log povedať, ktorý požiadavku obslúžil.

Pravidlá allow sa riadia rovnakou logikou. Povolenie pulu tunela neoprávňuje verejnú požiadavku a nevyplní vnútornú adresu na spojení, ktoré prišlo cez internet. Zmiešanie oboch vstupných bodov pod jeden názov mení zaznamenaný zdroj na vedľajší efekt smerovania klienta namiesto návrhovej voľby.

Overte cestu, potom politiku

Potvrďte cestu zachytením na bráne a požiadavkou, ktorú ovládate. Zachytenie na zariadení tunela a na verejnom rozhraní ukážu, ktoré prenieslo bajty, a poradie paketov vám povie, či medzi nimi prebehol preklad.

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

Potom overte prístup v oboch smeroch: zamýšľaný pomenovaný vstup funguje pre zamýšľaného klienta a neschválená verejná cesta je odmietnutá, nie len pomalá. Všeobecný web s odrazom IP dokazuje niečo o internetovom výstupe brány a nič o tomto webe na tom istom hostiteľovi. Keď sa stránka a WebSocket rozchádzajú, porovnajte ich URL, adresné rodiny a odpovede DNS, skôr než sa dotknete konfigurácie servera.

Súvisiace články