Zašto vaš LAN ne može dosegnuti uslugu na VPN klijentu

Vaš tunel je aktivan, usluga sluša, a uredski LAN i dalje ne dobija ništa natrag. Nitko nije pokvario VPN. S LAN strane, adresa tunela prijenosnika ne postoji dok nešto ne kaže LAN-u kako da je dosegne, i odgovor se mora vratiti istim putem kojim je zahtjev otišao. Vidio sam ljude kako tri puta iznova grade potpuno ispravan tunel prije nego što je itko pogledao povratni put.

Tunel nije ono što se pokvarilo

Oba kraja sjede na privatnim rasponima, što je normalan slučaj, a ne pogrešna konfiguracija. Adresa poput 10.8.0.6 stvarna je unutar tunela i ne postoji nigdje drugdje, pa LAN nema razloga da joj išta šalje. Prije nego što dodirnete rutiranje, potvrdite da je usluga uopće dostupna unutar tunela: na klijentu ss -ltn pokazuje da li se slušatelj veže na 127.0.0.1, na LAN sučelje ili na adresu tunela. Demon vezan samo na loopback ne odgovara nikome osim sebi, i tome ne pomaže nikakva ruta, DNAT ni prosljeđivanje porta.

Proxy na portu 80 ili 443 drugi je alat s drugom vidljivošću. On premješta zahtjeve, a ne pakete, pa je pogrešan sloj za sirovu vezu s bazom podataka, i upravo posezanje za njim dovodi do toga da ovaj problem završi tri alata duboko prije nego što itko bilo što izmjeri.

Oblik rute: recite LAN-u gdje je bazen

Statička ruta na LAN pristupniku najčišći je odgovor kada se LAN i bazen tunela ne preklapaju. Usmjerite bazen na stroj koji završava tunel:

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 ispravlja samo jedan smjer, i zato polovične verzije ove promjene izgledaju kao napredak. Tunelskoj strani treba odgovarajuća polovica, inače odgovor napušta klijenta preko njegove vlastite zadane rute i umire na putu:

push "route 192.168.1.0 255.255.255.0"

Za podmrežu koja stoji iza jednog klijenta, a ne iza poslužitelja, poslužitelju trebaju i sistemska ruta i unos iroute u datoteci tog klijenta pod client-config-dir. Bez iroute OpenVPN zna da prefiks postoji i nema pojma koji klijent ga posjeduje: paketi dolaze, a demon nema s čime da ih upari.

Evo mita koji vrijedi imenovati. Ruta čini adresu dostupnom; ona ne čini drugu stranu voljnom odgovoriti. Site-to-site partneri dodaju još jedan sloj povrh toga, jer udaljeni pristupnik prihvaća samo izvore unutar prefiksa navedenih u njegovoj politici, a prijenosnik koji dolazi iz kućnog bazena nije unutar njih.

Oblik NAT-a: DNAT prema unutra i linija SNAT-a koju svi preskaču

Kada ne možete dirati LAN pristupnik ili želite objaviti točno jedan port, prevođenje na VPN hostu radi bez ikakve rute na LAN-u. Objavite port, proslijedite ga i prevedite izvor na putu u tunel:

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

Treća linija je ona koja izostane. Preskočite je i klijent vidi izvornu LAN adresu kao izvor, odgovara preko svoje zadane rute, a taj odgovor odlazi u tunel umjesto natrag prema LAN-u. Hoće li veza preživjeti, tada ovisi o rutiranju koje nikada niste planirali. Uz SNAT klijent vidi adresu tunela poslužitelja, pa odgovor slijedi tunel natrag do jedinog hosta koji može poništiti prevođenje.

Potrošački firmware koristi vlastita imena lanaca i ne generira to prevođenje za vas. Na Tomato-u dolazno pravilo pada u WANPREROUTING, a zatim u filtarski lanac poput wanin, i skup pravila koji izgleda potpun još uvijek treba ručnu POSTROUTING liniju. To nije bug firmwarea; to je skup pravila napisan samo za dolazni promet.

Zašto pravilo koje izgleda ispravno ipak odbacuje paket

Većina tih kvarova nije u pravilu u koje buljite. Provjerite četiri stvari ovim redom i zaustavite se na prvoj koja ne vrijedi:

• Redoslijed lanaca. iptables -I umeće na vrh, a -A dodaje na kraj, pa ranije dopuštajuće ili blokirajuće pravilo odlučuje prvo.
• Pogrešan lanac. Promet adresiran na sam usmjerivač prolazi kroz INPUT, a proslijeđeni promet ga nikada ne dira. Objava jedne usluge može zahtijevati pravila u oba.
• Oznake smjera. -i tun0 podudara promet koji dolazi od klijenata, a -o tun0 promet koji odlazi prema njima. REJECT s pogrešnom oznakom blokira nešto što niste namjeravali.
• Ograničenje izvora. Prosljeđivanje koje prihvaća jednu adresu klijenta radi od tog klijenta i odbacuje svaki drugi izvor bez riječi.

Pravilo s nula brojačem paketa uopće nije na putu, a čitanje brojača najbrži je način da odvojite problem pogrešnog lanca od problema pogrešnog pravila.

Lokalno prosljeđivanje, kada se na LAN-u ništa ne može promijeniti

SSH lokalno prosljeđivanje zaobilazi cijelo pitanje. Ne treba mu ruta na LAN-u, ni suradnja klijentova vatrozida, ni port objavljen bilo gdje:

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

Usluga se tada pojavljuje na localhost:3000 stroja koji drži tunel, i nigdje drugdje. To je granica: jedna radna stanica, jedan port, i prosljeđivanje umire sa sesijom ako ga nešto ne restartuje. Za administratora koji provjerava pripremnu bazu podataka to je pravi alat. Za kameru ili skener do kojih drugi ljudi moraju doći nije, jer bi svaki korisnik trebao vlastito prosljeđivanje.

Provjerite oba smjera prije nego dodate još jedno pravilo

Prevođenje ostavlja tragove, a čitanje ih je bolje od nagađanja. Na VPN hostu conntrack -L pokazuje je li prevođenje uopće nastalo, iptables -t nat -L -n -v pokazuje jesu li se brojači pomaknuli, a tcpdump -ni any port 3000 pokazuje koja je izvorna adresa zapravo stigla. Na klijentu ss -ltn potvrđuje da je slušatelj na adresi koju tunel može dosegnuti.

Zatim odaberite oblik koji zadržavate. Jedan objavljen port, ruta za cijeli bazen i prosljeđivanje za jednog administratora tri su različite obveze, a njihovo miješanje je način na koji radna postavka postaje ona koju nitko ne može objasniti šest mjeseci kasnije. Zapišite koja je adresa odakle dostupna, i sljedeća osoba koja ovo bude otklanjala počinje od odgovora, a ne od tunela.