Melyik forrás-címet naplózza az NGINX egy VPN-kliens esetében?

Ugyanazon a gazdagépen futó NGINX és OpenVPN beállításban három klienscím jelenik meg, egy-egy minden útvonalhoz, amelyet egy kérés választhat. Az alagútcímre érkező böngésző, a nyilvános címre érkező böngésző és az átjáró internetes útvonalán kilépő program mind másként látszik a fogadó socketen. Döntse el, melyik útvonalat nézi, mielőtt értelmezi a naplósort. A döntés attól függ, milyen célcímre ment a kérés, milyen kivételt tart a kliens a külső VPN-végpontra, és hogy átírja-e valami a csomagot útközben.

Célcím szerint döntsön, ne a felhasználó kiléte szerint

Kezdje azzal a címmel, ahová a kérést küldték, mert az a cím választja ki az útvonalat. A gazdagép alagútcímére menő kérés az alagút interfészen érkezik, a kliens belső címével forrásként. A gazdagép nyilvános címére menő kérés általában az internet felé néző interfészen érkezik a kliens nyilvános címével, akkor is, ha ugyanazon a laptopon abban a pillanatban alagút van kiépítve. A VPN-készlethez tartozás tehát a csomag útvonalának tulajdonsága, nem a felhasználót követő tulajdonság.

Ezt a harmadik sort érdemes először ellenőrizni, amikor egy VPN-felhasználó olyan címmel jelenik meg a naplóban, amelynek semmi köze az alagúthoz. Ez magyarázza azt is, miért adhat két felhasználó ugyanazon a profilon különböző bejegyzéseket: a saját hozzáférési hálózataik eltérnek, és az alagútban semmi nem írja felül ezt.

Miért hoz létre a külső végpont második nyilvános útvonalat

A kliensnek el kell érnie az átjáró nyilvános címét az alagút kiépítéséhez, ezért az ahhoz a címhez vezető útvonalnak az alagúton kívül kell léteznie. Amikor a kliens minden forgalmat befelé irányít, egy értelmes megvalósítás kifejezett gazdagép-útvonalat tart fenn a szerver nyilvános címére, hogy elkerülje az önmagától függő alagutat. Ez a kivétel nem válogat a szolgáltatások között, ezért minden ugyanarra a nyilvános címre menő kérés követi, beleértve az átjárón hosztolt oldalra menő böngészőkérést is.

Ez a mechanizmus a legtöbb zavaros jelentés mögött ezen a területen, és inkább a kliens megvalósításától függ, mint a szerverétől. Ezért két azonos profilú kliens eltérően viselkedhet. A kivétel eltávolítása a napló »javítása« érdekében az alagutat is magával rántja, ezért tartsa meg, és tervezzen körülötte.

A socketet, a táblázatot és a naplóformátumot együtt olvassa

Három megfigyelés dönti el, melyik útvonalat nézi: hol figyel a socket, melyik interfész válaszol a célcímnek, és mit rögzít valójában a naplóformátum. Ha a figyelő csak az alagútcímhez van kötve, egy nyilvános kérés egyáltalán nem érheti el, ami azonnal kizár két sort. Ha a klienshez tartozó keresés az alagút-eszközt adja vissza, a kérés belső forrással érkezett, és a naplónak ezt mutatnia kell.

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

Utána a formátumot olvassa, ne a sort. A továbbított fejlécből táplált mező állítást rögzít, nem socket-partnert, és az állítás csak akkor számít, ha a közvetlen partner megbízható proxy. Mindkét érték naplózása lezárja a későbbi vitákat, mert a közvetlen partner és a helyettesített cím különböző tények, és csak az egyikük jött a hálózatról.

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

Válassza ki a kívánt belépési pontot, és hangolja össze a DNS-t

Ha az oldal csak alagúton keresztül érhető el, adjon neki olyan nevet, amely a VPN-kliensek számára az alagútcímre oldódik fel, és érvényesítsen házirendet a fogadó socketen. A belső névre 10.24.0.1-et visszaadó osztott DNS-válasz útvonalválasztási döntés névfeloldási részlet jelmezében. Ha az oldalnak nyilvánosnak is kell lennie, tartson meg két nevet vagy két portot, és hagyja, hogy a napló megmondja, melyik szolgálta ki a kérést.

Az engedélyezési szabályok ugyanezt a logikát követik. Az alagút-készlet engedélyezése nem jogosít fel nyilvános kérésre, és nem tölt ki belső címet egy interneten érkezett kapcsolaton. Mindkét belépési pont egyetlen név alá keverése a naplózott forrást a kliens útvonalválasztásának mellékhatásává teszi a tervezési döntés helyett.

Ellenőrizze az útvonalat, aztán a házirendet

Erősítse meg az útvonalat egy átjárón készített rögzítéssel és egy Ön által irányított kéréssel. Az alagút-eszközön és a nyilvános interfészen készített rögzítés megmutatja, melyik szállította a bájtokat, a csomagok sorrendje pedig elárulja, történt-e köztük átírás.

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

Utána ellenőrizze a hozzáférést mindkét irányban: a szándékolt elnevezett belépési pont működik a szándékolt kliensnek, és egy nem engedélyezett nyilvános útvonalat elutasítanak, nem csupán lassú. Egy általános IP-visszhang webhely valamit bizonyít az átjáró internetes kijáratáról, és semmit erről az ugyanazon a gazdagépen futó oldalról. Amikor egy oldal és egy WebSocket nem ért egyet, hasonlítsa össze az URL-jeiket, címcsaládjaikat és DNS-válaszaikat, mielőtt a szerverkonfigurációhoz nyúl.