Prečo sa vaša LAN nedostane na službu na klientovi VPN

Váš tunel je hore, služba počúva a kancelárska LAN napriek tomu nič nedostane späť. Nikto VPN nepokazil. Z pohľadu LAN adresa tunela notebooku neexistuje, kým niekto nepovie LAN, ako sa k nej dostať, a odpoveď sa musí vrátiť tou istou cestou, ktorou vyšla požiadavka. Videl som ľudí trikrát prestavať úplne funkčný tunel, než sa niekto pozrel na návratovú cestu.

Nepokazil sa tunel

Oba konce sedia v privátnych rozsahoch, čo je normálny stav a nie chybná konfigurácia. Adresa ako 10.8.0.6 je vnútri tunela skutočná a inde neexistuje, takže LAN nemá dôvod tam niečo posielať. Skôr než sa dotknete smerovania, potvrďte, že služba je vôbec dostupná vnútri tunela: na klientovi ss -ltn ukazuje, či sa počúvajúci viaže na 127.0.0.1, na rozhranie LAN alebo na adresu tunela. Démon naviazaný len na loopback neodpovedá nikomu okrem seba a žiadna trasa, DNAT ani presmerovanie portu to nezmení.

Proxy na porte 80 alebo 443 je iný nástroj s inou viditeľnosťou. Presúva požiadavky, nie pakety, takže je to nesprávna vrstva pre surové pripojenie k databáze, a práve siahnutie po ňom je spôsob, akým tento problém skončí tri nástroje hlboko, než niekto čokoľvek zmeria.

Tvar trasy: povedzte LAN, kde je fond

Statická trasa na bráne LAN je najčistejšia odpoveď, keď sa LAN a fond tunela neprekrývajú. Namierte fond na stroj, ktorý 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í iba jeden smer, a preto polovičné verzie tejto zmeny vyzerajú ako pokrok. Strana tunela potrebuje zodpovedajúcu polovicu, inak odpoveď opustí klienta jeho vlastnou predvolenou trasou a cestou zomrie:

push "route 192.168.1.0 255.255.255.0"

Pre podsieť, ktorá stojí za jedným klientom a nie za serverom, server potrebuje systémovú trasu aj záznam iroute v súbore toho klienta pod client-config-dir. Bez iroute OpenVPN vie, že prefix existuje, a netuší, ktorý klient ho vlastní: pakety prichádzajú a démon nemá čím ich spárovať.

Tu je mýtus, ktorý si zaslúži meno. Trasa robí adresu dostupnou; nerobí druhú stranu ochotnou odpovedať. Partneri lokalita-lokalita pridávajú ďalšiu vrstvu, pretože vzdialená brána akceptuje len zdroje vnútri prefixov zo svojej politiky, a notebook prichádzajúci z domáceho fondu v nich nie je.

Tvar NAT: DNAT dovnútra a riadok SNAT, ktorý všetci vynechávajú

Keď nemôžete siahnuť na bránu LAN alebo chcete publikovať presne jeden port, preklad na hoste VPN funguje bez akejkoľvek trasy v LAN. Publikujte port, preposlite ho a preložte zdroj na ceste do tunela:

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

Tretí riadok je ten, ktorý zmizne. Vynechajte ho a klient vidí pôvodnú adresu LAN ako zdroj, odpovedá cez svoju predvolenú trasu a tá odpoveď ide do tunela namiesto späť k LAN. Či spojenie prežije, potom závisí od smerovania, ktoré ste nikdy neplánovali. So SNAT klient vidí adresu tunela servera, takže odpoveď ide tunelom späť k jedinému hostiteľovi, ktorý dokáže preklad zrušiť.

Spotrebiteľský firmvér používa vlastné názvy reťazcov a tento preklad za vás nevytvorí. Na Tomato spadne prichádzajúce pravidlo do WANPREROUTING a potom do filtračného reťazca ako wanin, a sada pravidiel, ktorá vyzerá úplne, napriek tomu potrebuje ručný riadok POSTROUTING. To nie je chyba firmvéru; je to sada pravidiel napísaná len pre prichádzajúcu prevádzku.

Prečo pravidlo, ktoré vyzerá správne, paket aj tak zahodí

Väčšina týchto zlyhaní nie je v pravidle, na ktoré sa pozeráte. Skontrolujte štyri veci v tomto poradí a zastavte sa pri prvej, ktorá neplatí:

• Poradie reťazcov. iptables -I vkladá na začiatok a -A pridáva na koniec, takže skoršie povoľujúce alebo blokujúce pravidlo rozhodne prvé.
• Nesprávny reťazec. Prevádzka adresovaná samotnému routeru prechádza cez INPUT a preposielaná prevádzka sa jej nikdy nedotkne. Publikovanie jednej služby môže vyžadovať pravidlá v oboch.
• Príznaky smeru. -i tun0 zodpovedá prevádzke prichádzajúcej od klientov a -o tun0 prevádzke odchádzajúcej k nim. REJECT s nesprávnym príznakom zablokuje niečo, čo ste nezamýšľali.
• Obmedzenie zdroja. Presmerovanie, ktoré prijíma jednu adresu klienta, funguje od toho klienta a každý iný zdroj bez slova zahodí.

Pravidlo s nulovým počítadlom paketov vôbec nie je na ceste, a čítanie počítadiel je najrýchlejší spôsob, ako oddeliť problém nesprávneho reťazca od problému nesprávneho pravidla.

Lokálne presmerovanie, keď sa v LAN nedá nič zmeniť

Lokálne presmerovanie SSH obíde celú otázku. Nepotrebuje trasu v LAN, spoluprácu firewallu klienta ani port publikovaný kdekoľvek:

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

Služba sa potom objaví na localhost:3000 stroja, ktorý drží tunel, a nikde inde. To je hranica: jedna pracovná stanica, jeden port a presmerovanie umiera so seansou, ak ho niečo nereštartuje. Pre administrátora, ktorý kontroluje testovaciu databázu, je to správny nástroj. Pre kameru alebo skener, ku ktorým sa musia dostať iní ľudia, nie, pretože každý používateľ by potreboval vlastné presmerovanie.

Pred pridaním ďalšieho pravidla overte oba smery

Preklad zanecháva stopy a čítať ich je lepšie ako hádať. Na hoste VPN conntrack -L ukáže, či k prekladu vôbec došlo, iptables -t nat -L -n -v ukáže, či sa počítadlá pohli, a tcpdump -ni any port 3000 ukáže, ktorá zdrojová adresa skutočne prišla. Na klientovi ss -ltn potvrdí, že počúvajúci je na adrese, ktorú tunel dokáže dosiahnuť.

Potom si vyberte tvar, ktorý si ponecháte. Jeden publikovaný port, trasa pre celý fond a presmerovanie pre jedného administrátora sú tri rôzne záväzky a ich miešanie je spôsob, akým sa z funkčného nastavenia stane také, ktoré po pol roku nikto nevysvetlí. Zapíšte, ktorá adresa je odkiaľ dostupná, a ďalší človek, ktorý to bude ladiť, začne pri odpovedi namiesto pri tuneli.