Kas peaksite VPN-i alamvõrku suunatud pordi edastamisel kasutama SNAT-i?

Pordi edastamine hostile, mis asub ruuteri enda VPN-kliendi taga, ebaõnnestub viisil, mis näeb välja nagu tulemüüri probleem, sest päring saabub selgelt kohale. Teenus logib ühenduse, klient ootab ja midagi ei tule tagasi. Sihtkoha tõlge tegi oma töö; tagasisaadav pakett on see osa, mis kadus. Üks valikuline lähtevõrgu NAT-i reegel ruuteril parandab selle, ja huvitav osa on otsustada, kui kitsas see reegel saab olla.

Miks vastus valib teise tee

Pordi edastamine kirjutab ümber, kuhu pakett läheb, mitte kunagi seda, kust see tuli. Interneti-kliendi aadress jääb lähteväljale kogu tunneliteekonna jooksul, seega kaugteenus näeb võõrast ja vastab ainsal viisil, mida teab: oma vaikelüüsi kaudu. See lüüs on teisel pool asuv VPN-kontsentraator, millel pole marsruuti tagasi suvalisele avalikule aadressile.

Vaadake tunneliliidesel tehtud salvestust ja asümmeetria on ilmne: päringupaketid välja, sisse ei midagi. Edastusahel lubas voo ja tunnel kandis selle, seega toimub mahajätmine pärast seda, kui kaughost on juba tagasitee valinud.

Lähtevõrgu reegel, mis on piisavalt kitsas, et seda usaldada

Tee ruuterist lähtekoht, millele kaughost vastab. Selles paigutuses on WAN-i aadress 203.0.113.24, LAN on 192.168.88.0/24, ruuteri tunneli aadress on 172.20.5.1 ja teenus vastab aadressil 172.20.5.40:8443. Allolev reegel sobib paketiga pärast sihtkoha tõlget, seepärast nimetab see tõlgitud aadressi, mitte avalikku. Miski selles ei sõltu kliendi aadressist ja täpselt selles ongi mõte.

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

Iga vaste selles reas on selleks, et hoida ümberkirjutus kohalikuna ühe teenuse ja ühe tunneli jaoks. Eemaldage liides või port ja te kirjutate ümber rohkem liiklust, kui probleem nõuab, ja nii muutub sihitud parandus järgmisele inimesele mõistatuseks.

Millal on üldine maskeerimine aus valik

Kui ruuter edastab palju teenuseid samasse VPN-i alamvõrku, muutub teenusepõhine reegel nimekirjaks, mida keegi ei halda. Kõige maskeerimine, mis tunneliliideselt lahkub, on lihtsam ja ettearvatavam, selle hinnaga, et algne klient on teisel pool iga hosti eest peidetud. Valige see, kui sealsed logid ei ole atributsiooniks kasutusel; hoidke kitsast reeglit, kui on.

Mõlemad valikud ebaõnnestuvad ka erinevalt. Puuduv kitsas reegel lõhub ühe teenuse; liiga palju sobiv lai maskeerimine võib vaikselt ümber kirjutada liiklust, mis juba töötas, sealhulgas ruuteri enda väljuvad ühendused.

Kontrollige loendureid enne avaldamist

Reeglid, mis kunagi ei sobi, näevad välja täpselt samad nagu töötavad reeglid, kuni te pakette loendate. Lugege tabel uuesti baitide loenduritega enne, kui ükski klient ühendub, seejärel ühenduge võrgust, mis ei ole LAN, ja lugege seda uuesti. Kaks lugemist on see, mis muudab oletuse faktiks. Avaldage edastamine alles pärast seda, kui teine liigub.

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

Null-loendur lähtevõrgu reeglil pärast tõelist ühendust tähendab, et vaste on vale, tavaliselt sellepärast, et sihtkoht või port ei vasta tõlkejärgsele paketile. Kui loendur kasvab, aga klient saab endiselt ajalõpu, on tagasitee parandatud ja midagi muud viskab vastuse kõrvale, seega vaadake järgmisena teise poole edastuspoliitikat. LAN-i seest tulev juuksenõela-ligipääs on eraldi probleem ja vajab oma reeglit, mitte selle laiemat versiooni.