VPN klijenti dolaze do poslužitelja, ali ne do mreže LAN: koje rješenje?

Klijent pinga adresu tunela OpenVPN poslužitelja i dobiva odgovor, zatim pokuša host u mreži LAN poslužitelja i ne dobije ništa. Ta razlika znatno sužava kvar: tunel je podignut, prosljeđivanje vjerojatno radi, a odgovor izlazi na vrata koja ne vode natrag. Postoje tri rješenja, a pravo ovisi o tome što kontrolirate i čega ste spremni odreći se. Odgovorite na tri pitanja niže redom i izbor prestaje biti stvar ukusa.

Najprije utvrdite koji je smjer pokvaren

Zahtjev dolazi na sučelje tunela s izvornom adresom iz skupa VPN. Poslužitelj ga prosljeđuje hostu u mreži LAN, a taj host odgovara pristupniku koji navede njegova vlastita tablica, obično usmjerivaču mreže LAN. Ako usmjerivač nema rutu prema skupu, odgovor tamo umire ili luta prema internetu.

Testirajte oba stroja prije nego što ikoga izmijenite. Pitajte poslužitelj kojim bi putem njegova tablica došla do klijenta; pitajte host u mreži LAN kako bi došao na istu adresu. Prvo pretraživanje obično pokazuje na tunel, a drugo na usmjerivač mreže LAN, i ta je razlika kvar u jednom retku. Dva su pretraživanja jeftinija od revizije vatrozida i određuju smjer problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ako host u mreži LAN već pokazuje na VPN poslužitelj, problem je pravilo vatrozida ili ograničenje MTU, a ne nedostajući povratni put. Ne dodajte rutu da biste popravili filtar.

Prvo pitanje: možete li uređivati usmjerivač udaljene mreže LAN?

Kada je usmjerivač mreže LAN vaš, čist je odgovor statična ruta prema skupu VPN s adresom LAN VPN poslužitelja kao sljedećim skokom. Ona čuva izvorne adrese klijenata netaknutima, što je važno kada hostovi u mreži LAN bilježe, filtriraju ili ograničavaju brzinu po adresi. Također ne zahtijeva prevođenje na poslužitelju, pa tunel ostaje čist put usmjeravanja. Obveza koju stvara je dokumentacijska, jer se skup, ruta i konfiguracija poslužitelja moraju slagati.

Tiho zataji onog dana kad netko promijeni skup. Zapišite vrijednost jednom i tretirajte izmjenu na bilo kojem od tri mjesta kao izmjenu sva tri.

NAS ili Layer 3 preklopnik koji hosta uslugu treba istu rutu, osim ako sve šalje kroz usmjerivač koji je ima. Provjerite uređaj koji završava podmrežu, ne samo onaj okrenut internetu. Male mreže često imaju tri uređaja s mišljenjem o usmjeravanju.

Drugo pitanje: može li mreža LAN prestati vidjeti adrese klijenata?

Kada usmjerivač pripada nekome drugom, prevođenje na VPN poslužitelju ne traži suradnju. Host u mreži LAN vidi adresu LAN poslužitelja, odgovara joj, a poslužitelj prevodi natrag. Zato se uređaji i uloge daljinskog pristupa temeljene na NAT-u ponašaju tako.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Cijena je pripisivanje: adrese po klijentu nestaju iz zapisa mreže LAN. Svaki popis dopuštenih na hostu u mreži LAN tada mora navesti poslužitelj umjesto skupa.

Odaberite prevođenje kada suradnja nije dostupna, a ne kada je samo nezgodna. Skriva klijenta od svake buduće istrage, uključujući one u kojima morate znati koje je prijenosno računalo otvorilo vezu. Može i pokvariti protokole koji ugrađuju adrese u korisni teret, jer prevođenje živi u zaglavlju. Nijedna mogućnost nije naprednija; odgovaraju na različita pitanja o vlasništvu.

Treće pitanje: je li poslužitelj sam klijent drugog tunela?

Zamislite drugu topologiju: VPN poslužitelj ujedno zove komercijalnog pružatelja, pa ima dva tunela i dva skupa adresa. Promet koji prosljeđuje vlastitim klijentima izlazi kroz pružatelja, a on neće usmjeriti odgovore natrag na adrese skupa. Zato odgovori nestaju iako su oba tunela zdrava.

Rješenje je maskirati i odlazni tunel, da pružatelj vidi samo adresu tunela poslužitelja. Suprotni smjer treba vlastito pravilo, jer je poslužitelj koji započinje vezu prema vlastitom klijentu drugi tok. Bez tog pravila klijent odgovara na adresu koju ne može usmjeriti. Postavite usko pravilo prije svakog širokog maskiranja da bi posebni prijevod pobijedio.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hostovi s više sučelja dodaju srodan kvar koji s klijentove strane izgleda jednako. Odgovor izlazi kroz sučelje niže metrike jer je izvorna adresa odabrana iz druge tablice. Provjerite povratni put pretraživanjem umjesto da pretpostavljate da ga put naprijed podrazumijeva.

Zatim provjerite oba smjera i obje veličine

Nakon promjene pingajte s klijenta na host u mreži LAN, a zatim s hosta u mreži LAN na klijenta. Drugi je smjer onaj koji ljudi preskaču, i on otkriva nepotpuno pravilo prevođenja. Zabilježite oba rezultata s vremenskom oznakom da bi kasnija regresija bila usporediva.

Zatim prenesite stvarne podatke, jer mali ping koji uspije dok se velik prijenos zaustavlja simptom je MTU. Taj se kvar pojavljuje odmah nakon što si čestitate na popravljenoj ruti.

Na kraju ponovno testirajte nakon ponovnog pokretanja. Naredbe za rute i vatrozid u radu ga ne preživljavaju, a popravak koji nestane pri sljedećem pokretanju ponovno će diagnosticirati netko s manje konteksta. Učinite promjenu trajnom kako vaš sustav to već čini, pa se jednom namjerno ponovno pokrenite.