Prístup k službe na klientovi VPN: reverzný tunel alebo DNAT

Dokonca aj notebook za NAT operátora môže obslúžiť kolegu, ak server VPN slúži ako miesto stretnutia. Vedú tam dva mechanizmy: klient sa pripojí von a požiada server, aby držal počúvajúci port, alebo server zverejní port a preloží ho do tunela. Oba riešia rovnaký problém dostupnosti a správajú sa odlišne pri poruche, dohľade a protokolovaní. Tri podmienky rozhodujú, ktorý patrí do vášho nastavenia.

Dva tvary, jedno miesto stretnutia

V prvom tvare klient otvorí SSH reláciu von a požiada server, aby počúval na zvolenom porte, pričom každé spojenie posiela späť cez túto reláciu. Na serveri sa nič nepresmerúva a nedochádza k prekladu paketov, takže jediné požiadavky sú SSH účet, povolené presmerovanie a pravidlo firewallu pre port. Služba zostáva viazaná na loopback na klientovi, čo je zvyčajne to, čo chcete.

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

V druhom tvare vlastní verejný port server a prepisuje každé spojenie smerom k adrese tunela klienta. Vyžaduje to zapnuté presmerovanie IP, preklad cieľa na vstupe a preklad zdroja na výstupe a funguje to ďalej, keď neexistuje žiadna SSH relácia. Port patrí serveru, nie relácii, a práve táto vlastnosť rozhoduje väčšinu reálnych prípadov.

Ani jeden tvar nie je bezpečnejší svojou konštrukciou. Oba napokon vystavujú jeden port služby každému, kto dosiahne verejnú adresu servera, a oba stále závisia od vlastnej autentifikácie služby.

Podmienka jedna: musí port prežiť reláciu

Reverzné presmerovanie žije presne tak dlho ako SSH relácia, ktorá ho vytvorila. Keď spojenie padne, počúvajúci prvok zmizne a kolega uvidí odmietnuté pripojenie namiesto pomalej cesty. Dohľad nad príkazom pomocou jednotky systemd a politiky reštartu to rieši a ExitOnForwardFailure=yes urobí neúspešné naviazanie okamžite viditeľným, namiesto toho, aby zostala relácia bez presmerovania.

Preložený port prežije reštarty, ak sú pravidlá trvalo uložené, ale závisí od toho, či si klient ponechá rovnakú adresu tunela. Dynamický fond, ktorý notebooku po opätovnom pripojení pridelí inú adresu, potichu nasmeruje pravidlo do prázdna. Najprv rezervujte adresu tunela, potom napíšte pravidlo a berte oboje ako jednu zmenu.

Ak musí služba odpovedať o tretej ráno bez nikoho, kto by sa pozeral, tvar s portom zverejneným serverom má menej pohyblivých častí, pretože jediný proces, ktorý musí bežať, je samotný tunel.

Podmienka dva: komu patrí firewall a protokoly

Reverzný tvar drží celú politiku na dvoch miestach. sshd rozhoduje prostredníctvom AllowTcpForwarding, či sú vzdialené presmerovania vôbec povolené, a GatewayPorts rozhoduje, či sa počúvajúci prvok viaže na loopback alebo na každú adresu. Pri predvolenej hodnote no sa kolega mimo servera k portu nedostane, aj keď presmerovanie uspelo, a vyzerá to ako pokazený tunel, hoci v skutočnosti ide o adresu naviazania.

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

Preložený tvar potrebuje zapnuté presmerovanie a dve pravidlá, a druhé pravidlo je miesto, kde väčšina receptov chybuje. Obmedzenie prekladu zdroja stavom conntrack DNAT znamená, že sa prepisujú len spojenia vytvorené pravidlom cieľa, namiesto každého paketu, ktorý server pošle do tunela.

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 prepis ničí aj priradenie. Potom klient vidí každého volajúceho ako adresu tunela servera, čo zhrnie akýkoľvek limit rýchlosti na adresu do jedného vedra a skryje, kto čo poslal. Ak na priradení záleží, ukončite spojenie na serveri alebo tam ponechajte rozhodnutie o povolení a odovzdajte identitu v hlavičke, ktorej služba dôveruje. Voľba medzi týmito dvoma opravami závisí od toho, či služba vôbec číta proxy hlavičku.

Podmienka tri: jeden port alebo mnoho, a komu patrí meno

Jedna služba na jednom porte je prípad, keď reverzné presmerovanie vyhráva úsilím. Potrebujete jeden príkaz, jeden účet a jedno pravidlo firewallu a upratovaním je ukončenie relácie. Viac služieb na tej istej verejnej adrese vás tlačí k tvaru zverejnenému serverom, pretože každé reverzné presmerovanie potrebuje vlastný port servera a množina rastie s každou službou.

Mená to ďalej komplikujú. Reverzné presmerovanie môže sedieť za TCP proxy, ktorá smeruje podľa SNI, zatiaľ čo preložený port je zvyčajne jeden port na službu. Ak služba sama ukončuje TLS a potrebuje pôvodné meno hostiteľa, prístup cez proxy ho zachová a prístup DNAT ho zachová len vtedy, keď služba to meno na tom porte prijme.

Zapíšte, ktorá z troch podmienok rozhodla o tvare. Inak ďalší človek, ktorý pridá druhú službu, znova otvorí rovnaké porovnanie s menším kontextom.

Rozhodnite a potom testujte zvonku

Testujte cestu zo siete, ktorá nemá žiadnu trasu k notebooku, a sledujte počítadlá na serveri, kým požiadavka beží. Testovanie zo servera na jeho vlastnú verejnú adresu tu nič nedokazuje, pretože paket vzniká lokálne a nikdy nedorazí k háku prekladu prichádzajúceho provozu, takže test môže prejsť, aj keď je skutočná cesta pokazená.

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

Počítadlá, ktoré zostávajú ploché, znamenajú, že paket k pravidlu nikdy nedorazil, čo ukazuje na poskytovateľa alebo firewall hostiteľa. Počítadlá, ktoré sa hýbu, kým služba odmieta, ukazujú na vlastný firewall klienta alebo adresu, na ktorej služba počúva. Tunel, ktorý paket prenáša, ale nič nevracia, je problém trasy alebo reverznej cesty, a žiadny z týchto troch výsledkov by sa nemal ladiť úpravou adaptéra klienta. Zapíšte, ktoré počítadlo sa pohlo, skôr než niečo zmeníte, pretože nasledujúci test tú základňu potrebuje.

Keď tvar funguje, poznamenajte port, vlastníka a spôsob dohľadu vedľa konfigurácie tunela. Oprava dostupnosti, ktorá existuje len v niekoho histórii shellu, je jedno reštartovanie od opakovanej udalosti.