A szerver IP-címének változása után az SNAT-szabály még a régit nevezi meg

A szerver új címre költözött, a kliensek továbbra is csatlakoznak, és semmi, amit küldenek, nem éri el az internetet. Ez a szakadás a nyom: a figyelő socket és a porttovábbítás túlélte a költözést, ezért az alagút feljön, miközben a a továbbított csomagokra alkalmazott forrásfordítás még mindig olyan címet nevez meg, amelyet a gazdagép már nem birtokol. Azokra az átírt csomagokra adott válaszok egy már nem létező géphez mennek.

A csatlakozás és a továbbítás más-más helyen hibázik

A felépítés attól a végponttól függ, amelyet a kliensek már ismernek: a nyilvános cím, az előtte lévő porttovábbítás és a belső figyelő. A továbbított forgalom egy második döntéstől függ, amelyet azután hoznak, hogy a csomag belép az alagútba, amikor a gazdagép átírja a forrását, hogy a válaszok megtalálják a visszautat.

A címváltozás csak a második döntést töri el, és ezért olvasható a tünet úgy, hogy "csatlakozva, de nincs internet". Ez magyarázza azt is, miért tűnnek egészségesnek a szokásos kliensoldali ellenőrzések: a kézfogás lezárul, a kliens címet kap, és még a szerver alagútcímére küldött ping is válaszolhat. Órák mennek el a kliensen egy olyan hiba miatt, amely a másik oldalon él, ezért a szabálytábla az első hely, ahol érdemes megnézni.

Szerkesztés előtt olvassa el a szabályt és a számlálóit

Listázza ki a fordítási szabályokat a számlálókkal, és hasonlítsa össze a beállított forrást azokkal a címekkel, amelyekkel a gazdagép valóban rendelkezik. A halott címre átírt szabály általában forgalmat mutat a bejövő irányban, mert a csomagok elérik és lefordítódnak, a visszirányban pedig semmit.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Ellenőrizzen három mezőt, amíg ott van: a forrás-egyeztetésben lévő készletet, a kilépő interfészt, ha a szabály megnevez egyet, és azt a kizárást, amely megakadályozza az alagutak közötti forgalom átírását. Ezt a kizárást könnyű elveszíteni egy szerkesztés során, és elvesztése miatt a partnerek közötti forgalom működőnek látszik, miközben a válaszai furcsa úton járnak.

Ha a számlálók nullán ragadnak, a csomagok soha nem érik el ezt a szabályt, és a cím nem a jelenlegi probléma. Keressen egy versengő szabályt korábban a láncban, ami akkor fordul elő, amikor valaki csere hozzáadása helyett az eredetit szerkeszti. Hasonlítsa össze a szabályszámokat az egy perccel korábban feljegyzett kimenettel. A sorrend a konfiguráció része, nem kozmetikai részlet.

Cserélje le a forrást, vagy hagyjon fel egy megnevezésével

Ha a gazdagépnek stabil címe van, cserélje le a szabályt a helyén, ahelyett hogy újat fűzne hozzá. A szabályszám szerinti csere megőrzi azt a sorrendet, amelytől a lánc többi része függ.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Ha a címet dinamikusan osztják ki, ne nevezzen meg semmilyen forrást, és hagyja, hogy a kernel a kilépő interfészről válassza ki az aktuálisat. Ez a változat szerkesztés nélkül túléli a következő költözést, azon az áron, hogy elrejti, melyik címet használták.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Erősítse meg, hogy az IPv4-továbbítás még mindig engedélyezett a kezelt konfiguráción keresztül, majd tegye a szabályt tartóssá a disztribúció saját mechanizmusával. A csak a futó kernelben végrehajtott változás a következő újraindításkor visszatér, általában egy karbantartási ablakban, amelyet senki nem köt a változáshoz.

Két módja annak, hogy a cserét elrontsa

Ha a készletet a szerver alagútcímére fordítja a LAN-címe helyett, a válaszok egyenesen visszamennek az alagútba, ahol olyan kliens felé irányítódnak, amely soha nem kérte őket. A kapcsolat úgy akad el, hogy útvonalhuroknak látszik, mert az is.

A második fordítás rápakolása a régire a másik hiba. Az első egyező szabály nyer, így az elavult bejegyzés tovább kezeli a csomagokat, amíg törlik, az új szabály számlálói pedig nullán maradnak, miközben mindenki a cserét okolja. Törölje a duplikátumot, mielőtt bármi újat hozzáad. Utána olvassa el még egyszer a listát, és erősítse meg, hogy pontosan egy fordítás egyezik a készlettel.

Ha az alagút IPv6-ot is szállít, ismételje meg az egész átvizsgálást a másik vermen. A fordítás és az irányított előtag nélküli IPv6-alapértelmezett útvonal ugyanolyan csendesen hibázik, és könnyű elfelejteni, mert minden felette azonosnak látszik.

A bejövő szolgáltatásoknak az ellenkező fordításra van szükségük

A VPN-kliensen futó szolgáltatásnak, amelynek kívülről elérhetőnek kell lennie, célfordításra van szüksége, nem forrásfordításra: a nyilvános portot belépés előtt a kliens alagútcímére írják át. A továbbítási útvonalnak aztán kifejezett szabályra van szüksége, amely engedélyezi ezt a forgalmat.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Soha ne fordítsa le azt a portot, amely magát az alagutat szállítja, mert ez az átírás megszakítja azt a kapcsolatot, amely elérhetővé teszi a szolgáltatást. Tartsa az alagút portját teljesen a cél-szabályokon kívül. Végül ellenőrizze mindkét végéről: számlálók az új szabályon, rövid rögzítés az alagút eszközén, és egy kérés az alagúton belüli címre, mielőtt a nyilvánosat kipróbálná.