Zveřejněte port klienta VPN za CGNAT: kontrolní seznam

Umístěte službu na notebook za NAT na úrovni operátora, namiřte ten notebook na VPS přes VPN a nikdo zvenčí se k němu nedostane. Přidáte pravidlo cílového NAT na VPS a dostanete něco horšího než ticho: spojení se otevřou a pak ustanou. Odpověď nechybí, odchází vlastní výchozí cestou klienta, což znamená, že ji server nikdy nevidí. Projděte těchto pět kontrol v pořadí a zastavte se u první, která neobstojí.

Potvrďte, že server vůbec bude předávat

Zaškrtněte tento rámeček, než napíšete jediný překlad. Pravidlo DNAT pro paket, který jádro odmítá předat, parser pravidel přijme a pak jej zahodí cesta předávání, což vytvoří časový limit, který vypadá jako problém brány firewall.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Nastavení v běžícím jádru není totéž jako nastavení napříč restartem. Zapište net.ipv4.ip_forward=1 do souboru pod /etc/sysctl.d/, spusťte sysctl --system a potom hodnotu přečtěte zpět, místo abyste věřili, že se soubor načetl. Kontejner, který spravuje svůj vlastní síťový jmenný prostor, potřebuje stejnou hodnotu uvnitř tohoto prostoru, ne jen na hostiteli.

Pokud je odečet stále nula, zastavte se zde. Nic dalšího nebude fungovat.

Připněte adresu tunelu, než na ni bude odkazovat jakékoli pravidlo

Pool přiděluje adresy v pořadí připojení, takže pravidlo napsané pro dnešní pronájem může příští týden tiše ukazovat na jiného klienta. Svažte adresu s identitou certifikátu, nikoli s pořadím příchodu.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Tato dvojice je klientský konec a protější konec tunelu bod-bod, přičemž server je svázán s běžným názvem certifikátu. V topologii podsítě se druhá hodnota čte jako síťová maska, takže napište tvar, který odpovídá používané topologii. Potom klienta znovu připojte a přečtěte adresu na samotném klientovi, protože pohled serveru na pool není důkazem toho, co klient nakonfiguroval.

Pokud se adresa po opětovném připojení změní, zastavte se. Pravidlo NAT, které sleduje pohyblivý cíl, bude selhávat přerušovaně a nic vás nenaučí.

Překládejte v obou směrech

Překlad cíle posílá příchozí paket klientovi. Překlad zdroje je to, co přiměje klienta odpovědět serveru, a ne původnímu odesílateli, a je to pravidlo, které lidé vynechávají.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Bez druhého pravidla klient odpovídá přes svůj ISP vzestupný kanál, takže vzdálený protějšek vidí zdrojovou adresu, se kterou nikdy nemluvil, zatímco server nemá pro odpověď žádný záznam sledování. Vnější pozorovatel vidí handshake, který se dokončí napůl, a to je přesně ten příznak, který posílá lidi hledat chybu brány firewall, která tam není.

Přečtěte obě pravidla zpět pomocí iptables -t nat -S a potvrďte, že název rozhraní je ten, který nese veřejnou adresu. Na hostiteli, který už filtruje pomocí nftables, zapište překlad do NAT řetězce nftables odpovídající rodiny adres, místo abyste míchali nástroje.

Pusťte tabulku filtrů dál

Tabulky NAT přepisují hlavičky; oprávnění nedávají. S výchozí politikou DROP potřebuje předávaný tok vlastní přijetí plus zpětný směr, který většina politik už pokrývá pravidlem established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Před přidáním čehokoli zkontrolujte politiku řetězce FORWARD, protože pořadí včasného DROP rozhoduje o tom, zda bude vaše pravidlo vůbec konzultováno. Na hostiteli, jehož filtrování žije v nftables, přidejte ekvivalentní pravidlo do háku forward tabulky inet a potvrďte, že základní řetězec skutečně vidí předávaný provoz, a ne jen místní vstup. Pokud počítač paketů na novém pravidle zůstává na nule, zatímco počítače NAT rostou, paket se zahazuje před vaším pravidlem. To je signál přečíst pořadí řetězců, ne přidat druhou kopii stejného pravidla.

Dokažte to z vnější sítě

Testujte z nesouvisející sítě. Sonda z jiného stroje ve stejné LAN může projít podporou hairpin NAT a nikdy neprocvičí cestu, kterou používá vzdálený klient, takže zelený výsledek tam dokazuje špatnou věc.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Spusťte zachytávání na serveru a na klientovi současně. Zachytávání na serveru ukazuje, zda přeložený paket odchází k tunelu; zachytávání na klientovi ukazuje, zda požadavek dorazí a kam je odpověď adresována. Záznam překladu v conntrack -L dokazuje, že pravidlo odpovídalo, a jeho nepřítomnost dokazuje, že paket nikdy nedosáhl řetězce NAT.

Skenery portů jsou slabý důkaz. Hlásí port jako zavřený, dokud aplikace není svázána a neposlouchá, takže použijte skutečné připojení ke skutečné službě. Když to konečně funguje, udržte expozici na tom jednom portu: předávání SSH nebo administračního panelu proto, že první pravidlo působilo neohrabaně, je mnohem větší rozhodnutí než publikovat službu.