Máte použít SNAT u přesměrování portu do podsítě VPN?

Přesměrování portu na hostitele, který stojí za vlastním VPN klientem routeru, selhává způsobem, který vypadá jako problém firewallu, protože požadavek zjevně dorazí. Služba zaznamená spojení, klient čeká a nic se nevrací. Překlad cíle udělal svou práci; zpáteční paket je ta část, která zmizela. Jedno selektivní pravidlo zdrojového NAT na routeru to opraví a zajímavé je rozhodnout, jak úzké to pravidlo může být.

Proč odpověď jde jinou cestou

Přesměrování portu přepisuje, kam paket jde, nikdy odkud přišel. Adresa internetového klienta zůstává v poli zdroje po celé cestě tunelem, takže vzdálená služba vidí cizince a odpovídá jediným způsobem, který zná: přes svou vlastní výchozí bránu. Tou bránou je VPN koncentrátor na vzdálené straně, který nemá žádnou cestu zpět na libovolnou veřejnou adresu.

Podívejte se na zachycení na rozhraní tunelu a asymetrie je zřejmá: požadavky odcházejí, nic nepřichází. Řetězec přesměrování tok povolil a tunel ho přenesl, takže k zahození dochází poté, co vzdálený hostitel už zvolil cestu zpět.

Zdrojové pravidlo dost úzké na to, aby se mu dalo věřit

Udělejte z routeru zdroj, kterému vzdálený hostitel odpovídá. V tomto uspořádání je adresa WAN 203.0.113.24, LAN je 192.168.88.0/24, adresa tunelu routeru je 172.20.5.1 a služba odpovídá na 172.20.5.40:8443. Pravidlo níže odpovídá paketu po překladu cíle, proto uvádí přeloženou adresu, a ne veřejnou. Nic v něm nezávisí na adrese klienta, a právě o to jde.

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á shoda v tom řádku existuje proto, aby přepis zůstal lokální pro jednu službu na jednom tunelu. Odeberte rozhraní nebo port a přepisujete víc provozu, než problém vyžaduje, a tak se cílená oprava mění v záhadu pro dalšího člověka.

Kdy je plošná maska poctivá volba

Pokud router přesměrovává mnoho služeb do stejné podsítě VPN, pravidlo pro každou službu se stane seznamem, který nikdo neudržuje. Maskovat vše, co opouští rozhraní tunelu, je jednodušší a předvídatelnější, za cenu skrytí původního klienta před každým hostitelem na druhé straně. Zvolte to, když se tamní logy nepoužívají k atribuci; úzké pravidlo si ponechte, když ano.

Obě možnosti také selhávají jinak. Chybějící úzké pravidlo rozbije jednu službu; široká maska, která odpovídá příliš mnoha věcem, může tiše přepsat provoz, který už fungoval, včetně vlastních odchozích spojení routeru.

Před zveřejněním zkontrolujte čítače

Pravidla, která nikdy neodpovídají, vypadají stejně jako pravidla, která fungují, dokud pakety nespočítáte. Přečtěte tabulku znovu s bajtovými čítači, než se připojí jakýkoli klient, potom se připojte ze sítě, která není LAN, a přečtěte ji znovu. Dvě čtení jsou to, co mění domněnku ve fakt. Přesměrování zveřejněte až po tom, co se druhé pohne.

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

Nulový čítač na zdrojovém pravidle po skutečném spojení znamená, že shoda je špatná, obvykle proto, že cíl nebo port neodpovídá paketu po překladu. Pokud čítač roste, ale klient stále končí časovým limitem, cesta zpět je opravená a odpověď zahazuje něco jiného, takže se dál podívejte na politiku přesměrování na vzdálené straně. Přístup smyčkou zevnitř LAN je samostatný problém a potřebuje vlastní pravidlo, ne širší verzi tohoto.