Přístup ke službě na klientu VPN: reverzní tunel, nebo DNAT

Dokonce i notebook za NAT operátora může posloužit kolegovi, pokud server VPN funguje jako místo setkání. Vedou tam dva mechanismy: klient se připojí ven a požádá server, aby držel naslouchající port, nebo server zveřejní port a přeloží ho do tunelu. Oba řeší stejný problém dostupnosti a chovají se odlišně při poruše, dohledu a protokolování. Tři podmínky rozhodují, který z nich patří do vašeho nastavení.

Dva tvary, jedno místo setkání

V prvním tvaru klient otevře SSH relaci ven a požádá server, aby naslouchal na zvoleném portu, a každé spojení předává zpět touto relací. Na serveru se nic nepřesměrovává a nedochází k žádnému překladu paketů, takže jediné požadavky jsou SSH účet, povolené přesměrování a pravidlo firewallu pro port. Služba zůstává vázaná na loopback na klientu, což je obvykle to, co chcete.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

Ve druhém tvaru vlastní veřejný port server a přepisuje každé spojení směrem k adrese tunelu klienta. To vyžaduje zapnuté IP přesměrování, překlad cíle na vstupu a překlad zdroje na výstupu a funguje to i tehdy, když neexistuje žádná SSH relace. Port patří serveru, nikoli relaci, a to je vlastnost, která rozhoduje většinu reálných případů.

Ani jeden tvar není bezpečnější svou konstrukcí. Oba nakonec vystavují jeden port služby komukoli, kdo dosáhne veřejné adresy serveru, a oba stále závisí na vlastní autentizaci služby.

Podmínka jedna: musí port přežít relaci

Reverzní přesměrování žije přesně tak dlouho jako SSH relace, která je vytvořila. Když spojení spadne, naslouchající prvek zmizí a kolega uvidí odmítnuté připojení místo pomalé cesty. Dohled nad příkazem pomocí systemd jednotky a politiky restartu to řeší a ExitOnForwardFailure=yes udělá neúspěšné navázání okamžitě viditelným, místo aby zůstala relace bez přesměrování.

Přeložený port přežije restarty, pokud jsou pravidla trvale uložena, ale závisí na tom, že si klient ponechá stejnou adresu tunelu. Dynamický fond, který notebooku po opětovném připojení přidělí jinou adresu, tiše nasměruje pravidlo do prázdna. Nejprve rezervujte adresu tunelu, potom napište pravidlo a berte obojí jako jednu změnu.

Pokud musí služba odpovídat ve tři ráno bez nikoho, kdo by se díval, má tvar s portem zveřejněným serverem méně pohyblivých částí, protože jediný proces, který musí běžet, je samotný tunel.

Podmínka dvě: komu patří firewall a protokoly

Reverzní tvar drží veškerou politiku na dvou místech. sshd rozhoduje, zda jsou vzdálená přesměrování vůbec povolena, prostřednictvím AllowTcpForwarding, a GatewayPorts rozhoduje, zda se naslouchající prvek váže na loopback, nebo na všechny adresy. S výchozí hodnotou no se kolega mimo server k portu nedostane, i když přesměrování uspělo, a vypadá to jako rozbitý tunel, když jde ve skutečnosti o adresu navázání.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Přeložený tvar potřebuje zapnuté přesměrování a dvě pravidla a druhé pravidlo je místo, kde většina receptů chybuje. Omezení překladu zdroje stavem conntrack DNAT znamená, že se přepisují jen spojení vytvořená pravidlem cíle, místo každého paketu, který server pošle do tunelu.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Tento přepis také ničí přiřazení. Potom klient vidí každého volajícího jako adresu tunelu serveru, což srazí jakýkoli limit rychlosti na adresu do jednoho hrnce a skryje, kdo co poslal. Pokud na přiřazení záleží, ukončete spojení na serveru nebo tam ponechte rozhodnutí o povolení a předejte identitu v hlavičce, které služba důvěřuje. Volba mezi těmito dvěma opravami závisí na tom, zda služba vůbec čte proxy hlavičku.

Podmínka tři: jeden port, nebo mnoho, a komu patří jméno

Jedna služba na jednom portu je případ, kdy reverzní přesměrování vyhrává úsilím. Potřebujete jeden příkaz, jeden účet a jedno pravidlo firewallu a úklidem je ukončení relace. Více služeb na stejné veřejné adrese vás tlačí k tvaru zveřejněnému serverem, protože každé reverzní přesměrování potřebuje vlastní port serveru a množina roste s každou službou.

Jména to dále komplikují. Reverzní přesměrování může sedět za TCP proxy, která směruje podle SNI, zatímco přeložený port je obvykle jeden port na službu. Pokud služba sama ukončuje TLS a potřebuje původní název hostitele, přístup přes proxy ho zachová a přístup DNAT ho zachová jen tehdy, když služba ten název na tom portu přijme.

Zapište, která ze tří podmínek tvar rozhodla. Jinak další člověk, který přidá druhou službu, znovu otevře stejné srovnání s menším kontextem.

Rozhodněte a potom testujte zvenčí

Testujte cestu ze sítě, která nemá žádnou trasu k notebooku, a sledujte čítače na serveru, dokud požadavek běží. Testování ze serveru na jeho vlastní veřejnou adresu zde nic nedokazuje, protože paket vzniká lokálně a nikdy nedorazí k háku překladu příchozího provozu, takže test může projít, i když je skutečná cesta rozbitá.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Čítače, které zůstávají ploché, znamenají, že paket k pravidlu nikdy nedorazil, což ukazuje na poskytovatele nebo firewall hostitele. Čítače, které se hýbou, zatímco služba odmítá, ukazují na vlastní firewall klienta nebo adresu, na které služba naslouchá. Tunel, který paket přenáší, ale nic nevrací, je problém trasy nebo reverzní cesty, a žádný z těchto tří výsledků by se neměl ladit úpravou adaptéru klienta. Zapište, který čítač se pohnul, než něco změníte, protože další test tu základnu potřebuje.

Když tvar funguje, poznamenejte port, vlastníka a způsob dohledu vedle konfigurace tunelu. Oprava dostupnosti, která existuje jen v něčí historii shellu, je jedno restartování od opakované události.