Proč se vaše LAN nedostane na službu na klientu VPN

Klient VPN může hostovat službu, kterou LAN nedokáže otevřít. Co obvykle chybí, je zpáteční cesta: jedna trasa, dvojice DNAT nebo řádek SNAT, který nikdo nepřidá.

Tunel je nahozený, služba poslouchá a kancelářská LAN přesto nic nedostane zpátky. Nikdo VPN nerozbil. Z pohledu LAN adresa tunelu notebooku neexistuje, dokud někdo LAN neřekne, jak se k ní dostat, a odpověď se musí vrátit stejnou cestou, kterou vyšel požadavek. Viděl jsem lidi třikrát přestavět naprosto funkční tunel, než se někdo podíval na zpáteční cestu.

Tunel není to, co se rozbilo

Oba konce sedí v privátních rozsazích, což je normální stav a ne chybná konfigurace. Adresa jako 10.8.0.6 je uvnitř tunelu skutečná a jinde neexistuje, takže LAN nemá důvod tam něco posílat. Než se dotknete směrování, potvrďte, že služba je vůbec dostupná uvnitř tunelu: na klientovi ss -ltn ukazuje, zda se naslouchač váže na 127.0.0.1, na rozhraní LAN, nebo na adresu tunelu. Démon vázaný jen na loopback neodpovídá nikomu kromě sebe a žádná trasa, DNAT ani přesměrování portu to nezmění.

Proxy na portu 80 nebo 443 je jiný nástroj s jinou viditelností. Přesouvá požadavky, ne pakety, takže je to špatná vrstva pro surové připojení k databázi, a sáhnout po něm je přesně to, jak tento problém skončí tři nástroje hluboko, než někdo cokoli změří.

Tvar trasy: řekněte LAN, kde je fond

Statická trasa na bráně LAN je nejčistší odpověď, když se LAN a fond tunelu nepřekrývají. Namiřte fond na stroj, který tunel ukončuje:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

To opraví jen jeden směr, a proto poloviční verze této změny vypadají jako pokrok. Strana tunelu potřebuje odpovídající polovinu, jinak odpověď opustí klienta přes jeho vlastní výchozí trasu a cestou zemře:

push "route 192.168.1.0 255.255.255.0"

U podsítě, která stojí za jedním klientem, a ne za serverem, potřebuje server jak systémovou trasu, tak záznam iroute v souboru toho klienta pod client-config-dir. Bez iroute OpenVPN ví, že prefix existuje, a nemá ponětí, který klient ho vlastní: pakety dorazí a démon nemá co k nim přiřadit.

Tady je mýtus, který stojí za pojmenování. Trasa udělá adresu dostupnou; neudělá protistranu ochotnou odpovědět. Partneři site-to-site přidávají další vrstvu, protože vzdálená brána přijímá jen zdroje uvnitř prefixů ze své politiky, a notebook přicházející z domácího fondu v nich není.

Tvar NAT: DNAT dovnitř a řádek SNAT, který všichni přeskakují

Když nemůžete sáhnout na bránu LAN, nebo chcete publikovat právě jeden port, překlad na hostiteli VPN funguje bez jakékoli trasy na LAN. Publikujte port, přepošlete ho a přeložte zdroj na cestě do tunelu:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Třetí řádek je ten, který se ztratí. Přeskočte ho a klient vidí původní adresu LAN jako zdroj, odpovídá přes svou vlastní výchozí trasu a ta odpověď míří do tunelu místo zpět k LAN. Zda spojení přežije, pak závisí na směrování, které jste nikdy neplánovali. Se SNAT klient vidí adresu tunelu serveru, takže odpověď jde tunelem zpět k jedinému hostiteli, který dokáže překlad zrušit.

Spotřebitelský firmware používá vlastní názvy řetězců a tento překlad za vás nevytvoří. Na Tomato spadne příchozí pravidlo do WANPREROUTING a pak do filtrovacího řetězce jako wanin, a sada pravidel, která vypadá úplně, přesto potřebuje ruční řádek POSTROUTING. To není chyba firmwaru; je to sada pravidel psaná jen pro příchozí provoz.

Proč pravidlo, které vypadá správně, paket stejně zahodí

Většina těchto selhání není v pravidle, na které zíráte. Zkontrolujte čtyři věci v tomto pořadí a zastavte se u první, která neplatí:

  • Pořadí řetězců. iptables -I vkládá na začátek a -A přidává na konec, takže dřívější povolující nebo blokující pravidlo rozhodne první.
  • Špatný řetězec. Provoz adresovaný samotnému routeru prochází přes INPUT a přeposílaný provoz se ho nikdy nedotkne. Publikování jedné služby může vyžadovat pravidla v obou.
  • Příznaky směru. -i tun0 odpovídá provozu přicházejícímu od klientů a -o tun0 provozu odcházejícímu k nim. REJECT se špatným příznakem zablokuje něco, co jste nezamýšleli.
  • Omezení zdroje. Přesměrování, které přijímá jednu adresu klienta, funguje od toho klienta a každý jiný zdroj bez slova zahodí.

Pravidlo s nulovým počítadlem paketů není na cestě vůbec, a čtení počítadel je nejrychlejší způsob, jak oddělit problém špatného řetězce od problému špatného pravidla.

Lokální přesměrování, když se na LAN nedá nic změnit

Lokální přesměrování SSH celou otázku obejde. Nepotřebuje trasu na LAN, ani spolupráci firewallu klienta, ani port publikovaný kdekoli:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Služba se pak objeví na localhost:3000 stroje, který tunel drží, a nikde jinde. To je hranice: jedna pracovní stanice, jeden port a přesměrování umírá se sezením, pokud ho něco nerestartuje. Pro správce, který kontroluje testovací databázi, je to správný nástroj. Pro kameru nebo skener, kam se musí dostat další lidé, ne, protože každý uživatel by potřeboval vlastní přesměrování.

Ověřte oba směry, než přidáte další pravidlo

Překlad zanechává stopy a číst je je lepší než hádat. Na hostiteli VPN conntrack -L ukáže, zda k překladu vůbec došlo, iptables -t nat -L -n -v ukáže, zda se pohnula počítadla, a tcpdump -ni any port 3000 ukáže, která zdrojová adresa skutečně dorazila. Na klientovi ss -ltn potvrdí, že naslouchač je na adrese, kterou tunel dokáže dosáhnout.

Pak si vyberte tvar, který si ponecháte. Jeden publikovaný port, trasa pro celý fond a přesměrování pro jednoho správce jsou tři různé závazky a jejich míchání je způsob, jak se z funkčního nastavení stane takové, které po půl roce nikdo nevysvětlí. Zapište, která adresa je odkud dostupná, a příští člověk, který to bude ladit, začne u odpovědi místo u tunelu.

Související články