Mali by ste použiť SNAT pri presmerovaní portu do podsiete VPN?

Presmerovanie portu na hostiteľa, ktorý stojí za vlastným VPN klientom routera, zlyháva spôsobom, ktorý vyzerá ako problém firewallu, pretože požiadavka zjavne prichádza. Služba zaznamená spojenie, klient čaká a nič sa nevracia. Preklad cieľa urobil svoju prácu; spiatočný paket je tá časť, ktorá zmizla. Jedno selektívne pravidlo zdrojového NAT na routeri to opraví a zaujímavé je rozhodnúť, aké úzke to pravidlo môže byť.

Prečo odpoveď ide inou cestou

Presmerovanie portu prepisuje, kam paket ide, nikdy odkiaľ prišiel. Adresa internetového klienta zostáva v poli zdroja po celej ceste tunelom, takže vzdialená služba vidí cudzinca a odpovedá jediným spôsobom, ktorý pozná: cez svoju vlastnú predvolenú bránu. Tou bránou je VPN koncentrátor na druhej strane, ktorý nemá žiadnu cestu späť na ľubovoľnú verejnú adresu.

Pozrite sa na zachytenie na rozhraní tunela a asymetria je zrejmá: požiadavky odchádzajú, nič neprichádza. Reťazec presmerovania tok povolil a tunel ho preniesol, takže k zahodeniu dochádza po tom, čo vzdialený hostiteľ už zvolil cestu späť.

Zdrojové pravidlo dosť úzke na to, aby sa mu dalo veriť

Urobte z routera zdroj, ktorému vzdialený hostiteľ odpovedá. V tomto usporiadaní je adresa WAN 203.0.113.24, LAN je 192.168.88.0/24, adresa tunela routera je 172.20.5.1 a služba odpovedá na 172.20.5.40:8443. Pravidlo nižšie zodpovedá paketu po preklade cieľa, preto uvádza preloženú adresu a nie verejnú. Nič v ňom nezávisí od adresy klienta, a práve o to ide.

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

Každá zhoda v tom riadku existuje preto, aby prepis zostal lokálny pre jednu službu na jednom tuneli. Odstráňte rozhranie alebo port a prepisujete viac prevádzky, než problém vyžaduje, a tak sa cielená oprava mení na záhadu pre ďalšieho človeka.

Kedy je plošná maska poctivá voľba

Ak router presmerúva mnoho služieb do tej istej podsiete VPN, pravidlo pre každú službu sa stane zoznamom, ktorý nikto neudržiava. Maskovať všetko, čo opúšťa rozhranie tunela, je jednoduchšie a predvídateľnejšie, za cenu skrytia pôvodného klienta pred každým hostiteľom na druhej strane. Zvoľte to, keď sa tamojšie logy nepoužívajú na atribúciu; úzke pravidlo si ponechajte, keď sa používajú.

Obe možnosti zlyhávajú aj inak. Chýbajúce úzke pravidlo pokazí jednu službu; široká maska, ktorá zodpovedá príliš veľa, môže potichu prepísať prevádzku, ktorá už fungovala, vrátane vlastných odchádzajúcich spojení routera.

Pred zverejnením skontrolujte počítadlá

Pravidlá, ktoré nikdy nezodpovedajú, vyzerajú rovnako ako pravidlá, ktoré fungujú, kým pakety nespočítate. Prečítajte tabuľku znova s bajtovými počítadlami, kým sa pripojí akýkoľvek klient, potom sa pripojte zo siete, ktorá nie je LAN, a prečítajte ju znova. Dve čítania sú to, čo mení domnienku na fakt. Presmerovanie zverejnite až po tom, čo sa druhé pohne.

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

Nulové počítadlo na zdrojovom pravidle po skutočnom spojení znamená, že zhoda je nesprávna, zvyčajne preto, že cieľ alebo port nezodpovedajú paketu po preklade. Ak počítadlo rastie, ale klient stále končí časovým limitom, cesta späť je opravená a odpoveď zahadzuje niečo iné, takže sa ďalej pozrite na politiku presmerovania na vzdialenej strane. Prístup slučkou zvnútra LAN je samostatný problém a potrebuje vlastné pravidlo, nie širšiu verziu tohto.