Umiestnite službu na notebook za NAT na úrovni operátora, nasmerujte ten notebook na VPS cez VPN a nikto zvonku sa k nemu nedostane. Pridáte pravidlo cieľového NAT na VPS a dostanete niečo horšie ako ticho: spojenia sa otvoria a potom sa zaseknú. Odpoveď nechýba, odchádza vlastnou predvolenou cestou klienta, čo znamená, že ju server nikdy nevidí. Prejdite týchto päť kontrol v poradí a zastavte sa pri prvej, ktorá neobstojí.

Potvrďte, že server vôbec bude preposielať

Zaškrtnite toto pole skôr, než napíšete čo i len jeden preklad. Pravidlo DNAT pre paket, ktorý jadro odmieta preposlať, parser pravidiel prijme a potom ho cesta preposielania zahodí, čo vytvorí časový limit, ktorý vyzerá ako problém brány firewall.

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

Nastavenie v bežiacom jadre nie je to isté ako nastavenie naprieč reštartom. Zapíšte net.ipv4.ip_forward=1 do súboru pod /etc/sysctl.d/, spustite sysctl --system a potom prečítajte hodnotu späť namiesto toho, aby ste verili, že sa súbor načítal. Kontajner, ktorý spravuje svoj vlastný sieťový menný priestor, potrebuje rovnakú hodnotu vnútri tohto priestoru, nielen na hostiteľovi.

Ak je odčítanie stále nula, zastavte sa tu. Nič ďalej nebude fungovať.

Pripnite adresu tunela skôr, než na ňu bude odkazovať akékoľvek pravidlo

Bazén prideľuje adresy v poradí pripojení, takže pravidlo napísané pre dnešný prenájom môže budúci týždeň ticho ukazovať na iného klienta. Spojte adresu s identitou certifikátu, nie s poradím príchodu.

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

Táto dvojica je klientský koniec a koniec partnera tunela bod-bod, pričom server je zviazaný so spoločným názvom certifikátu. V topológii podsiete sa druhá hodnota namiesto toho číta ako sieťová maska, takže napíšte tvar, ktorý zodpovedá používanej topológii. Potom klienta znovu pripojte a prečítajte adresu na samotnom klientovi, pretože pohľad servera na bazén nie je dôkazom toho, čo klient nakonfiguroval.

Ak sa adresa po opätovnom pripojení zmení, zastavte sa. Pravidlo NAT, ktoré sleduje pohyblivý cieľ, bude zlyhávať prerušovane a nič vás nenaučí.

Prekladajte oboma smermi

Preklad cieľa posiela prichádzajúci paket klientovi. Preklad zdroja je to, čo prinúti klienta odpovedať serveru a nie pôvodnému odosielateľovi, a je to pravidlo, ktoré ľudia 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 odpovedá cez svoj ISP vzostupný kanál, takže vzdialený partner vidí zdrojovú adresu, s ktorou nikdy nehovoril, kým server nemá pre odpoveď žiadny záznam sledovania. Vonkajší pozorovateľ vidí podanie ruky, ktoré sa dokončí spolovice, a to je presne ten príznak, ktorý posiela ľudí hľadať chybu brány firewall, ktorá tam nie je.

Prečítajte obe pravidlá späť pomocou iptables -t nat -S a potvrďte, že názov rozhrania je ten, ktorý nesie verejnú adresu. Na hostiteľovi, ktorý už filtruje pomocou nftables, zapíšte preklad do NAT reťazca nftables zodpovedajúcej rodiny adries namiesto miešania nástrojov.

Pustite tabuľku filtrov ďalej

Tabuľky NAT prepisujú hlavičky; neudeľujú povolenie. Pri predvolenej politike DROP potrebuje preposielaný tok vlastné povolenie plus spätný smer, ktorý väčšina politík už pokrýva pravidlom 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

Pred pridaním čohokoľvek skontrolujte politiku reťazca FORWARD, pretože poradie skorého DROP rozhoduje o tom, či bude vaše pravidlo vôbec konzultované. Na hostiteľovi, ktorého filtrovanie žije v nftables, pridajte ekvivalentné pravidlo do háku forward tabuľky inet a potvrďte, že základný reťazec skutočne vidí preposielanú prevádzku a nie len lokálny vstup. Ak počítač paketov na novom pravidle zostane na nule, kým počítače NAT rastú, paket sa zahadzuje pred vaším pravidlom. To je signál prečítať poradie reťazcov, nie pridať druhú kópiu toho istého pravidla.

Dokážte to z vonkajšej siete

Testujte z nesúvisiacej siete. Sonda z iného stroja v tej istej LAN môže prejsť podporou hairpin NAT a nikdy neprecvičí cestu, ktorú používa vzdialený klient, takže zelený výsledok tam dokazuje nesprávnu vec.

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

Spustite zachytávanie na serveri a na klientovi súčasne. Zachytávanie na serveri ukazuje, či preložený paket odchádza k tunelu; zachytávanie na klientovi ukazuje, či požiadavka dorazí a kam je odpoveď adresovaná. Záznam prekladu v conntrack -L dokazuje, že pravidlo zodpovedalo, a jeho neprítomnosť dokazuje, že paket nikdy nedosiahol reťazec NAT.

Skenery portov sú slabý dôkaz. Hlásia port ako zatvorený, kým aplikácia nie je zviazaná a nepočúva, takže použite skutočné pripojenie k skutočnej službe. Keď to konečne funguje, udržte expozíciu na tom jednom porte: preposielanie SSH alebo administračného panelu preto, že prvé pravidlo pôsobilo neohrabane, je oveľa väčšie rozhodnutie než zverejniť službu.

Súvisiace články