A NAT dönti el, melyik forrás-címet látja valójában a VPN-szervered

Úgy képzeled, hogy a VPN-szerver a csomagból olvassa ki a laptopod címét, és beírja egy naplóba. Amit olvas, az az, amit az utolsó NAT-ugrás a külső fejlécbe tett, és egy hotspotként használt telefonon ez gyakran olyan cím, amelyet több száz más előfizetővel osztanak meg. A géped saját 192.168.x.x címe soha nem halad át az interneten ebben a fejlécben, és az alagút címét a szerver akkor adja ki, amikor a kapcsolat már áll. Ezért amikor a szerver naplója és a laptopon lévő ip addr nem egyezik, egyik sem hibás; egyetlen munkamenet különböző rétegeit írják le.

Három cím, és csak egy van a naplóban

A zavar abból ered, hogy három címet egyetlenre vonnak össze. Mindegyiknek más a tulajdonosa, más fejlécben él, és más úton éri el a szervert.

Csak a középső sor ismeretlen a csatlakozás pillanatában. A szerver a démontól függően a partnertáblájába, az állapotfájlba vagy a folyamnaplóba írja: a WireGuard végpontnak nevezi, az OpenVPN állapotfájlja Real Address néven jelöli, a strongSwan pedig az IKE_SA távoli gazdagépeként jelenti. Ez az érték minden alkalommal frissül, amikor más forrásból érkezik csomag, tehát úgy változik, hogy senki nem indít újra semmit.

Az alsó sor az, amit az emberek tévesen identitásállításként olvasnak. Egy helyet jelöl a szerver konfigurációjában, nem egy személyt, mert a szerver a saját készletéből választotta. Két felhasználó különböző napokon ugyanazt az alagútcímet kaphatja, és egy ember kettőt is tarthat két eszközről.

Miért változik a naplózott tuple, miközben az alagút állva marad

A címfordítás időzítővel ellátott tábla, nem állandó kötés. Az otthoni router az utolsó csomag után még egy ideig megtartja az UDP-leképezését, az operátor átjárója a saját ütemezése szerint újrahasznosítja a portokat, és a Wi-Fi-ről LTE-re váltó telefon teljesen más forrással tér vissza. A Linux conntrack alapértékei itt hasznos viszonyítási pontok: a nf_conntrack_udp_timeout 30 másodperc, a streaming változat pedig 120, így egy csendes alagút jóval azelőtt elveszítheti a leképezését, hogy a felhasználó észrevenné.

Az alagút azért marad életben, mert a protokoll a partnert hitelesíti, nem a címet. A WireGuard a kézfogás után állapotmentes, így minden hitelesített csomag frissíti a tárolt végpontot, és az újrakötés a következő csomagnál helyreáll; ezért létezik a persistent-keepalive = 25, hogy tétlenség közben melegen tartsa a leképezést. Az OpenVPN --float paramétere ugyanezt teszi, és lehetővé teszi, hogy egy hitelesített kliens új címről és portról folytassa. A 2.4-es és 2.5-ös buildekben, ahol a float alapértelmezés szerint ki van kapcsolva, az újrakötés visszaállítja a munkamenetet, és a kliens újra csatlakozik.

Az IPsec több mozgó alkatrésszel ér oda. Az IKEv2 a NAT-felderítő hasznos terhelésekben a forrás- és cél-hasheket összehasonlítva észleli a fordítást, UDP 4500-as beágyazásra vált, és a keepalive-okat az új tuple-ig követi. Ha a keepalive-okat blokkolják, az SA papíron állva marad, miközben az egyik irányú forgalom csendben megáll.

Mit tud a szerver hozzárendelni, és mit nem

A mítosz, amelyet érdemes megölni, hogy a fordítás elrejt az operátor elől. A címkét változtatja meg, nem a megfigyelést. Az operátor NAT-ja mögötti átjáró a 100.64.0.0/10 teret vagy egy sok előfizető által megosztott nyilvános címet lát, és a folyamot mégis hozzá tudja kötni egy tanúsítvány-tárgyhoz, egy WireGuard nyilvános kulcshoz, egy kiosztott alagútcímhez, bájtszámlálókhoz és egy időablakhoz. Ezek egyikéhez sem kell a LAN-címed.

A korlátok a másik irányba is működnek. A naplóban szereplő megosztott cím egy átjáróra mutat, nem egy háztartásra; két munkamenet ugyanarról a fordított címről különböző portokon két különböző eszköz; ugyanaz a cím két különböző napon két független előfizető lehet, ha a portot újrahasznosították. Egy szerver, amely csak partnerkulcsokat rögzít, a fiókadatbázis nélkül nem tudja ezeket ügyfélhez rendelni, és egy szerver, amely csak címeket rögzít, nem tudja megkülönböztetni a laptopot a telefontól ugyanazon router mögött.

Hasonlítsd össze a két végét a találgatás helyett

Hogy tisztázd, mi történt, rögzítsd ugyanazt a kapcsolatot mindkét végén ugyanabban a pillanatban, és a tuple-t hasonlítsd össze, ne a címet. A kliensen, bármilyen fordítás előtt:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Ezután olvasd el a fordítási bejegyzést a routeren vagy a CGNAT-átjárón, és azt, ami végül a szerverre érkezik:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Három minta magyarázza a legtöbb eltérést. A szerver forrásportja eltér a helyi porttól, miközben a cél megegyezik: közönséges portfordítás. A szerver forráscíme olyan ISP-blokkhoz tartozik, amely nem a tiéd: legalább egy további NAT-réteg. A csomagok egy tétlen időszak után megállnak, és új porttal folytatódnak: a leképezés lejárt, nem útvonalhiba. Ha az időbélyegek több mint egy-két másodperccel eltérnek, két különböző kísérletet hasonlítasz össze.

Ahol a különbség elront dolgokat

A szerverhibának tűnő kiesések általában itt kezdődnek. Az otthoni címedhez rögzített hozzáférési szabály az ISP-bérlet megváltozása után meghiúsul. Egy fordított címre illeszkedő fail2ban-szabály egyszerre tiltja ki az átjáró mögötti összes előfizetőt. Egy rögzített távoli című telephely-közti partner a mobilkapcsolat változása után abbahagyja a kulcsok megújítását. Az alagút protokollja rendben volt; a külső tuple-re vonatkozó feltevés nem.

Ugyanez a zavar a szerver oldalán is megjelenik. Ha maga a VPN-doboz NAT mögött van, porttovábbításra és működő továbbítási útvonalra van szükséged; a strongSwan továbbítási útmutatója ezt az esetet fedi le IPsec esetén. Egy csak privát címen elérhető szerver soha nem látja a kliensei által bemutatott fordított tuple-t, és ez más probléma, mint a kliensek fordítása.

Végezd el ezt a négy ellenőrzést sorrendben, és állj meg az elsőnél, amelyik megbukik:

• Rögzíts mindkét végén egyszerre; erősítsd meg, hogy a forrásport, a célport és az időbélyegek egyeznek.
• A szerver partnertáblájában az aktuálisan tárolt címet olvasd, ne azt, amelyet vártál.
• Ellenőrizd a conntrack vagy NAT táblában a bejegyzést és annak hátralévő élettartamát.
• Erősítsd meg, hogy a kliens alagút-interfészének címe a szerver által kiosztott címmel egyezik, nem a LAN-címmel.

Ha mindkét rögzítés egyetért a tuple-ben, és az alagút mégis meghiúsul, a fordítás nem a te problémád; lépj tovább a kézfogásra és az alagúton belüli útvonaltáblára.