Kateri izvorni naslov bo NGINX zabeležil za odjemalca VPN?

V namestitvi NGINX in OpenVPN na istem gostitelju se pojavijo trije odjemalski naslovi, po eden za vsako pot, ki jo lahko ubere zahteva. Brskalnik, ki doseže naslov tunela, brskalnik, ki doseže javni naslov, in program, ki izstopi po internetni poti prehoda, so na poslušajoči vtičnici videti različno. Preden razložite vrstico dnevnika, odločite, na katero pot gledate. Odločitev je odvisna od cilja, ki ga je uporabil odjemalec, od izjeme, ki jo ima za zunanjo končno točko VPN, in od tega, ali kaj na poti prevede paket.

Odločite se po cilju, ne po tem, kdo je uporabnik

Začnite z naslovom, na katerega je bila zahteva poslana, ker ta naslov izbere pot. Zahteva na naslov tunela gostitelja prispe na vmesnik tunela z notranjim naslovom odjemalca kot virom. Zahteva na javni naslov gostitelja običajno prispe na vmesnik, obrnjen v internet, z javnim naslovom odjemalca, tudi ko ima isti prenosnik v tistem trenutku vzpostavljen tunel. Pripadnost skladu VPN je torej lastnost poti paketa, ne lastnost, ki bi sledila uporabniku.

Prav to tretjo vrstico je vredno najprej preveriti, ko se v dnevniku pojavi uporabnik VPN z naslovom, ki nima nič skupnega s tunelom. Pojasni tudi, zakaj lahko dva uporabnika z istim profilom ustvarita različne vnose: njuni lastni dostopovni omrežji se razlikujeta in nič v tunelu tega ne prepiše.

Zakaj zunanja končna točka ustvari drugo javno pot

Odjemalec mora doseči javni naslov prehoda, da vzpostavi tunel, zato mora pot do tega naslova obstajati zunaj tunela. Ko odjemalec preusmeri ves promet navznoter, smiselna izvedba ohrani izrecno pot gostitelja do javnega naslova strežnika, da se izogne tunelu, ki je odvisen sam od sebe. Ta izjema ne razlikuje storitev, zato ji sledi vsaka zahteva na isti javni naslov, vključno z zahtevo brskalnika na mesto, gostovano na prehodu.

To je mehanizem za večino zmedenih poročil na tem področju in je odvisen od izvedbe odjemalca, ne strežnika. Dva odjemalca z enakimi profili se zato lahko obnašata različno. Če izjemo odstranite, da bi »popravili« dnevnik, s tem podrete tudi tunel, zato jo obdržite in načrtujte okoli nje.

Berite vtičnico, tabelo in obliko dnevnika skupaj

Tri opažanja odločijo, na katero pot gledate: kje vtičnica posluša, kateri vmesnik odgovarja na cilj in kaj oblika dnevnika dejansko zabeleži. Če je poslušalec vezan le na naslov tunela, javna zahteva do njega sploh ne more priti, kar takoj izloči dve vrstici. Če iskanje za odjemalca vrne napravo tunela, je zahteva prispela z notranjim virom in dnevnik bi moral to pokazati.

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

Nato berite obliko, ne vrstice. Polje, ki ga napaja posredovana glava, zabeleži trditev, ne partnerja vtičnice, in trditev je pomembna le, ko je neposredni partner zaupanja vreden posrednik. Zapis obeh vrednosti v dnevnik razreši poznejše spore, ker sta neposredni partner in nadomeščeni naslov različni dejstvi in je le eno od njiju prišlo iz omrežja.

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

Izberite vstopno točko, ki jo želite, in uskladite DNS

Če naj bo mesto dostopno le prek tunela, mu dajte ime, ki se odjemalcem VPN razreši na naslov tunela, in uveljavite politiko na poslušajoči vtičnici. Odgovor razdeljenega DNS, ki vrne 10.24.0.1 za notranje ime, je odločitev o usmerjanju v preobleki podrobnosti razreševanja imen. Če mora biti mesto tudi javno, obdržite dve imeni ali dve vrat, in pustite dnevniku, da pove, katera je oskrbela zahtevo.

Pravila dovoljenja sledijo isti logiki. Dovoljenje sklada tunela ne pooblasti javne zahteve in ne bo zapolnilo notranjega naslova na povezavi, ki je prispela prek interneta. Mešanje obeh vstopnih točk pod enim imenom spremeni zabeleženi vir v stranski učinek usmerjanja odjemalca namesto v oblikovalsko izbiro.

Preverite pot, nato politiko

Potrdite pot z zajemom na prehodu in zahtevo, ki jo nadzorujete. Zajem na napravi tunela in eden na javnem vmesniku pokažeta, katera je prenesla bajte, in vrstni red paketov vam pove, ali je med njima prišlo do prevoda.

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

Nato preverite dostop v obe smeri: predvideni imenovani vstop deluje za predvidenega odjemalca, neodobrena javna pot pa je zavrnjena, ne le počasna. Splošno spletno mesto z odmevom IP dokaže nekaj o internetnem izhodu prehoda in nič o tem mestu na istem gostitelju. Ko se stran in WebSocket ne ujemata, primerjajte njune URL-je, naslovne družine in odgovore DNS, preden se dotaknete konfiguracije strežnika.