Alkalmazzon SNAT-et a VPN-alhálózatba irányuló porttovábbításnál?

Egy port továbbítása egy olyan hosztra, amely a router saját VPN-kliense mögött ül, olyan módon vall kudarcot, amely tűzfalproblémának látszik, mert a kérés egyértelműen megérkezik. A szolgáltatás naplózza a kapcsolatot, a kliens vár, és semmi nem jön vissza. A célfordítás elvégezte a dolgát; a visszatérő csomag az a rész, amely eltűnt. Egyetlen szelektív forrás-NAT-szabály a routeren helyreállítja ezt, és az érdekes rész annak eldöntése, mennyire lehet szűk ez a szabály.

Miért vesz másik utat a válasz

A porttovábbítás átírja, hová megy egy csomag, soha nem azt, honnan jött. Az internetes kliens címe a forrásmezőben marad végig a tunelen át, így a távoli szolgáltatás egy idegent lát, és az egyetlen ismert módon válaszol: a saját alapértelmezett átjáróján keresztül. Az az átjáró a túloldali VPN-koncentrátor, amelynek nincs útvonala vissza egy tetszőleges nyilvános címre.

Nézzen meg egy rögzítést a tunel interfészén, és az aszimmetria nyilvánvaló: kérő csomagok kifelé, semmi befelé. A továbbítási lánc engedélyezte a folyamot, és a tunel szállította, tehát az eldobás azután történik, hogy a távoli hoszt már választott egy visszautat.

Elég szűk forrásszabály ahhoz, hogy megbízzunk benne

Tegye a routert azzá a forrássá, amelyre a távoli hoszt válaszol. Ebben az elrendezésben a WAN-cím 203.0.113.24, a LAN 192.168.88.0/24, a router tunelcíme 172.20.5.1, és a szolgáltatás a 172.20.5.40:8443 címen válaszol. Az alábbi szabály a célfordítás utáni csomagra illeszkedik, ezért a fordított címet nevezi meg, nem a nyilvánosat. Semmi benne nem függ a kliens címétől, és pontosan ez a lényeg.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Az abban a sorban szereplő minden egyezés azért van, hogy az átírás egy szolgáltatásra és egy tunelre korlátozódjon. Vegye ki az interfészt vagy a portot, és több forgalmat ír át, mint amennyit a probléma megkíván, és így válik egy célzott javítás rejtéllyé a következő ember számára.

Mikor az átfogó maszkolás az őszinte választás

Ha a router sok szolgáltatást továbbít ugyanabba a VPN-alhálózatba, a szolgáltatásonkénti szabály olyan listává válik, amelyet senki nem tart karban. Mindent maszkolni, ami elhagyja a tunel interfészét, egyszerűbb és kiszámíthatóbb, azon az áron, hogy az eredeti kliens elrejtőzik a túloldal minden hosztja elől. Válassza ezt, ha az ottani naplókat nem attribúcióra használják; tartsa meg a szűk szabályt, ha használják.

A két lehetőség másképp is vall kudarcot. Egy hiányzó szűk szabály egy szolgáltatást tör el; egy széles maszkolás, amely túl sokra illeszkedik, csendesen átírhat olyan forgalmat, amely már működött, beleértve a router saját kimenő kapcsolatait is.

Ellenőrizze a számlálókat közzététel előtt

A soha nem illeszkedő szabályok addig ugyanúgy néznek ki, mint a működő szabályok, amíg meg nem számolja a csomagokat. Olvassa vissza a táblázatot bájtos számlálókkal, mielőtt bármely kliens csatlakozik, majd csatlakozzon egy nem LAN-hálózatból, és olvassa vissza újra. Két leolvasás az, ami egy sejtést ténnyé változtat. Csak akkor tegye közzé a továbbítást, ha a második elmozdul.

iptables -t nat -L POSTROUTING -v -n --line-numbers

A forrásszabály nulla számlálója egy valódi kapcsolat után azt jelenti, hogy az egyezés hibás, általában azért, mert a cél vagy a port nem illik a fordítás utáni csomaghoz. Ha a számláló nő, de a kliens még mindig időtúllépést kap, a visszaút rendben van, és valami más dobja el a választ, ezért nézze meg következőként a túloldali továbbítási szabályzatot. A LAN-on belüli hajtűhozzáférés külön probléma, és saját szabályt igényel, nem ennek egy szélesebb változatát.