Millise lähteaadressi logib NGINX VPN-kliendi jaoks?

Sama hosti NGINX-i ja OpenVPN-i seadistuses ilmub kolm kliendi aadressi, üks iga tee kohta, mille päring võib võtta. Brauser, mis pöördub tunneli aadressi poole, brauser, mis pöördub avaliku aadressi poole, ja programm, mis väljub lüüsi internetitee kaudu, näevad kuulaval soketil kõik erinevad välja. Otsustage, millist teed te vaatate, enne kui logirida tõlgendate. Otsus sõltub sihtkohast, mida klient kasutas, erandist, mis tal välimise VPN-i lõpp-punkti jaoks on, ja sellest, kas miski paketti teel tõlgib.

Otsustage sihtkoha, mitte kasutaja järgi

Alustage aadressist, kuhu päring saadeti, sest see aadress valib tee. Päring hosti tunneli aadressile saabub tunneliliidesele kliendi sisemise aadressiga allikana. Päring hosti avalikule aadressile saabub tavaliselt internetti vaatavale liidesele kliendi avaliku aadressiga, isegi kui samal sülearvutil on sel hetkel tunnel püsti. VPN-i basseini kuulumine on seega paketi tee omadus, mitte omadus, mis järgib kasutajat.

Just seda kolmandat rida tasub kõigepealt kontrollida, kui logis ilmub VPN-i kasutaja aadressiga, millel pole tunneliga midagi pistmist. See selgitab ka, miks kaks sama profiili kasutajat võivad anda erinevaid kirjeid: nende endi juurdepääsuvõrgud erinevad ja miski tunnelis ei kirjuta seda üle.

Miks välimine lõpp-punkt loob teise avaliku tee

Klient peab tunneli loomiseks jõudma lüüsi avaliku aadressini, seega peab tee selle aadressini eksisteerima väljaspool tunnelit. Kui klient suunab kogu liikluse sissepoole, hoiab mõistlik rakendus serveri avaliku aadressi jaoks eksplitsiitset hostimarsruuti, et vältida tunnelit, mis sõltub iseendast. See erand ei ole teenuste suhtes valiv, seega järgib seda iga päring samale avalikule aadressile, sealhulgas brauseri päring lüüsil majutatud saidile.

See on mehhanism enamiku selles valdkonnas segadust tekitavate aruannete taga ja see on kliendi, mitte serveri rakenduse omadus. Seega võivad kaks identse profiiliga klienti käituda erinevalt. Erandi eemaldamine logi »parandamiseks« võtab kaasa ka tunneli, seega hoidke see alles ja projekteerige selle ümber.

Lugege soketit, tabelit ja logivormingut koos

Kolm tähelepanekut otsustavad, millist teed te vaatate: kus soket kuulab, milline liides sihtkohale vastab ja mida logivorming tegelikult salvestab. Kui kuulaja on seotud ainult tunneli aadressiga, ei jõua avalik päring selleni üldse, mis välistab kohe kaks rida. Kui kliendi otsing tagastab tunneliseadme, saabus päring sisemise allikaga ja log peaks seda näitama.

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

Seejärel lugege vormingut, mitte rida. Edastatud päisega toidetud väli salvestab väite, mitte soketi partneri, ja väide loeb ainult siis, kui vahetu partner on usaldusväärne puhverserver. Mõlema väärtuse logisse kirjutamine lahendab hilisemad vaidlused, sest vahetu partner ja asendatud aadress on erinevad faktid ning ainult üks neist tuli võrgust.

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

Valige soovitud sisenemispunkt ja pange DNS nõustuma

Kui sait peab olema ainult tunneli kaudu, andke sellele nimi, mis VPN-i klientide jaoks laheneb tunneli aadressiks, ja rakendage kuulaval soketil poliitikat. Split-DNS-i vastus, mis tagastab sisemise nime jaoks 10.24.0.1, on marsruutimisotsus nime lahendamise detaili kostüümis. Kui sait peab olema ka avalik, hoidke kahte nime või kahte porti ja laske logil öelda, milline päringut teenindas.

Lubamisreeglid järgivad sama loogikat. Tunneli basseini lubamine ei anna voli avalikuks päringuks ega täida sisemist aadressi ühendusel, mis saabus interneti kaudu. Mõlema sisenemispunkti segamine ühe nime alla muudab salvestatud allika kliendi marsruutimise kõrvalmõjuks, mitte projekteerimisvalikuks.

Kontrollige teed, seejärel poliitikat

Kinnitage tee lüüsil tehtud püüdmise ja teie juhitava päringuga. Püüdmine tunneliseadmel ja avalikul liidesel näitavad, milline baidid kandis, ja pakettide järjekord ütleb, kas nende vahel toimus tõlge.

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

Seejärel kontrollige juurdepääsu mõlemas suunas: ettenähtud nimega sisenemispunkt töötab ettenähtud kliendi jaoks ja heakskiitmata avalik tee lükatakse tagasi, mitte lihtsalt aeglane. Üldine IP-kaja veebisait tõestab midagi lüüsi internetiväljundi kohta ja mitte midagi selle sama hosti saidi kohta. Kui leht ja WebSocket ei ole ühel nõul, võrrelge nende URL-e, aadressipere ja DNS-vastuseid enne serveri seadistuse puutumist.