Kako poslati samo jednu privatnu podmrežu kroz VPN

Jedna privatna podmreža kroz tunel, a sve ostalo vašim uobičajenim putem: mali zahtjev s velikim brojem načina da se pogriješi. Ishod ne odlučuje polje s oznakom split tunneling, nego mjesto gdje se odluka provodi: vlastita tabela ruta klijenta, ruta koju server šalje ili politika o kojoj se dvije strane dogovaraju. Odaberete pogrešan sloj i dobijete ili puni tunel koji nikad niste htjeli, ili rutu prema tunelu koji druga strana odbija prihvatiti. Prije nego otvorim bilo koju konfiguraciju, primijenim test s tri uvjeta, a zatim odaberem jedan od mehanizama ispod.

Tri uvjeta koja određuju dizajn

Prvo, trebate tačan prefiks i masku od vlasnika mreže. Mreža 10.x nije prefiks; 10.20.0.0/16 jeste. Provjerite da se ne preklapa s vašom kućnom LAN mrežom, Docker mostom ili drugim VPN-om koji vodite, jer preklapanje čini rutu dvosmislenom i jezgro bira unos koji niste namjeravali.

Drugo, ko odgovara na povratni saobraćaj. Rutiranje paketa u tunel samo ga dovodi do VPN servera. Ako podmreža stoji iza drugog rutera koji nema rutu natrag do vašeg skupa klijenata, server mora maskirati saobraćaj ili taj ruter mora naučiti vaš skup. Nijedna ruta na strani klijenta ne ispravlja nedostajući povratni put.

Treće, tačka provođenja. Neki klijenti instaliraju rutu, a ostalo odradi operativni sistem. Drugi pregovaraju politiku, a politika koju gateway ne prihvata ne stvara nikakav tunel: paketi se odbacuju bez očigledne greške. Utvrdite koja je od te dvije vaša prije nego što šta napišete.

WireGuard: AllowedIPs je tabela ruta

Na klijentu AllowedIPs navodi odredišta koja smiju ući u tunel, a wg-quick pretvara svaki unos u običnu rutu. Dakle klijentska polovina ovog zadatka je jedan red.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Sada uporedite unos servera za istog klijenta. On opisuje šta će server poslati klijentu, a to je obično adresa tunela klijenta, ne privatna podmreža.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Zamjena tih dvaju je greška koju vidim najčešće. Stavljanje 10.20.0.0/16 pod peer sekciju servera tvrdi da cijela podmreža stoji iza tog klijenta, a to je tvrdnja od lokacije do lokacije, ne dozvola. Paketi koji ne odgovaraju AllowedIPs nijednog peer-a odbacuju se tiho, pa pogrešan unos izgleda tačno kao problem s firewallom.

Ako sami upravljate rutama, postavite Table = off pod [Interface] i dodajte rutu koju želite. Tada se ništa ne dodaje automatski, pa ruta pripada onome što podiže interfejs.

OpenVPN: pošaljite rutu, pa provjerite da je stigla

Na normalnom serveru promjena je jedna direktiva u konfiguraciji servera, uz skup klijenata.

push "route 10.20.0.0 255.255.0.0"

Klijent je dodaje kada se poveže. Način neuspjeha pojavljuje se kada isti profil šalje i redirect-gateway, ili kada je neko već dodao route-nopull: prvo pretvara sesiju u puni tunel, a drugo odbacuje svaku poslanu rutu, uključujući vašu.

Klijent kojem treba usko ponašanje prema serveru s punim tunelom treba ignorisati samo dijelove koje ne želi. U OpenVPN 2.4 i novijim pull-filter postoji upravo za to.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Držite porodice adresa odvojeno: poslana ruta IPv4 ne čini ništa za internu uslugu koja se razrješava u IPv6, i ta usluga pada kroz tunel dok sve ostalo izgleda ispravno.

Kada privatna podmreža nije na VPN serveru nego iza drugog klijenta, server mora biti obaviješten. Dodajte datoteku za svakog klijenta kroz client-config-dir koja sadrži iroute 10.20.0.0 255.255.0.0, plus odgovarajuću route da ostali klijenti nauče put. Bez iroute server nema razlog slati taj prefiks kroz taj konkretni tunel.

IPsec: selektori saobraćaja moraju se složiti

S IPsec-om nema rute koju treba poslati. Dvije strane pregovaraju koje adrese žive unutar tunela, a saobraćaj izvan dogovorenih selektora nije šifrovan niti se šalje kroz njega. Na strongSwan klijentu selektori su izričiti.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ako je gateway konfigurisan s 0.0.0.0/0 na obje strane, IKEv2 sužavanje obično svodi podređenu SA na presjek dvaju predloga, što je ishod koji želite. Neki gatewayi umjesto toga odbijaju predlog koji ne odgovara njihovim konfigurisanim selektorima, a zapis tada pokazuje neuspjelu podređenu SA, a ne žalbu na rutiranje. Kada se to dogodi, promjena pripada gatewayu, jer klijentska ruta ne može stvoriti tunel za selektor koji druga strana neće prihvatiti.

Na Windowsu ugrađeni klijent skriva istu odluku iza dvije postavke. Dijeljenje tunela mora biti uključeno, a prefiks mora biti registrovan uz profil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Registracija prefiksa čini da preživi ponovno povezivanje, što ručno dodana ruta ne čini.

Držite krajnju tačku i DNS izvan odluke

Krajnja tačka VPN-a mora ostati dostupna bez tunela, inače se tunel urušava sam u sebe. Kada se rutira samo 10.20.0.0/16, to je automatski, jer je krajnja tačka javna adresa. Na profilu punog tunela nije, i klijentu treba izričita ruta do hosta krajnje tačke prije nego što se tunel podigne.

DNS je druga odluka koju slanje rute ne donosi umjesto vas. Interna imena obično se razrješavaju kroz resolver do kojeg samo privatna mreža može doći. Ako server šalje DNS server, svako ime prolazi kroz njega; ako ne, interna imena ili ne uspijevaju ili se javno razrješavaju u nešto što niste namjeravali. Podijeljeni DNS drži jednu domenu pretrage na internom resolveru, ali to zavisi od podrške klijenta, pa to tretirajte kao zaseban zadatak, a ne kao nuspojavu rutiranja.

Provjerite, zatim restartujte i provjerite ponovo

Tri provjere pokrivaju pitanje rutiranja. Pitajte jezgro kuda bi otišla udaljena adresa, preuzmite nešto iz unutrašnjosti podmreže, pa potvrdite da običan javni zahtjev još izlazi kroz vašu normalnu vezu.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Prvi red imenuje interfejs. Ako imenuje vaš fizički interfejs, ruta nikada nije sjela. Na Windowsu Find-NetRoute -RemoteIPAddress 10.20.5.7 odgovara na isto pitanje, a posljednja provjera treba još pokazivati vašu običnu adresu, a ne adresu VPN servera.

Zatim restartujte. Rute dodane rukom nestaju, dok se rute iz profila, iz poslane konfiguracije ili iz AllowedIPs vraćaju. Ako uski pristup radi prije restarta i ne uspijeva poslije, kvar je u tome kako tunel kreće, ne u samoj ruti.

Prije nego što to nazovete gotovim, potvrdite četiri stvari: prefiks je došao od vlasnika mreže i ne preklapa se ni s čim lokalnim, povratni put postoji ili ga zamjenjuje pravilo maskiranja, mehanizam koji ste konfigurisali jeste onaj koji provodi rutiranje na vašoj platformi, i iste provjere prolaze nakon čistog restarta. strongSwanove bilješke o prosljeđivanju vrijedi pročitati ako je povratni put dio koji stalno pada.