Si të dërgoni vetëm një nënrrjet privat përmes VPN

Një nënrrjet privat përmes tunelit dhe gjithçka tjetër në rrugën tuaj normale është një kërkesë e vogël me shumë mënyra për ta bërë gabim. Rezultatin nuk e vendos kutia e shënimit me emrin split tunneling, por ku zbatohet vendimi: në tabelën e rrugëve të vetë klientit, në një rrugë që shtyn serveri, ose në një politikë për të cilën negociojnë dy skajet. Zgjidhni shtresën e gabuar dhe merrni ose një tunel të plotë që nuk e keni dashur kurrë, ose një rrugë drejt një tuneli që pala tjetër refuzon ta pranojë. Unë përdor një provë me tre kushte përpara se të hap çdo konfigurim, pastaj zgjedh një nga mekanizmat më poshtë.

Tre kushte që vendosin projektin

Së pari, ju nevojitet prefiksi dhe maska e saktë nga pronari i rrjetit. Rrjeti 10.x nuk është prefiks; 10.20.0.0/16 është. Konfirmoni që nuk mbivendoset me LAN-in e shtëpisë, një urë Docker ose një VPN tjetër që drejtoni, sepse mbivendosja e bën rrugën të paqartë dhe kernel-i zgjedh hyrjen që nuk e kishit ndërmend.

Së dyti, kush i përgjigjet trafikut të kthimit. Rrugëtimi i një pakete në tunel e çon vetëm te serveri VPN. Nëse nënrrjeti ndodhet pas një routeri tjetër që nuk ka rrugë kthimi te grupi juaj i klientëve, serveri duhet të maskojë trafikun, ose ai router duhet të mësojë grupin tuaj. Asnjë rrugë në anën e klientit nuk rregullon një rrugë kthimi që mungon.

Së treti, pika e zbatimit. Disa klientë instalojnë një rrugë dhe sistemi operativ bën pjesën tjetër. Të tjerë negociojnë një politikë, dhe një politikë që porta nuk e pranon nuk prodhon fare tunel: paketat hidhen pa një gabim të dukshëm. Zbuloni cila nga të dyja është rasti juaj përpara se të shkruani ndonjë gjë.

WireGuard: AllowedIPs është tabela e rrugëve

Te klienti, AllowedIPs rendit destinacionet që mund të hyjnë në tunel, dhe wg-quick e kthen çdo hyrje në një rrugë të zakonshme. Pra gjysma e klientit e kësaj detyre është një rresht.

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

Tani krahasoni hyrjen e serverit për të njëjtin klient. Ajo përshkruan çfarë do t'i dërgojë serveri klientit, që zakonisht është adresa e tunelit të klientit, jo nënrrjeti privat.

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

Ndërrimi i këtyre dyve është gabimi që shoh më shpesh. Vendosja e 10.20.0.0/16 nën seksionin peer të serverit deklaron se i gjithë nënrrjeti ndodhet pas atij klienti, dhe kjo është një pretendim nga vendi në vend, jo një leje. Paketat që nuk përputhen me AllowedIPs e asnjë peer hidhen në heshtje, kështu që një hyrje e gabuar duket saktësisht si një problem me murin e zjarrit.

Nëse i administroni vetë rrugët, vendosni Table = off nën [Interface] dhe shtoni rrugën që dëshironi. Atëherë nuk shtohet asgjë automatikisht, kështu që rruga i përket asaj që ngre ndërfaqen.

OpenVPN: shtyjeni rrugën, pastaj sigurohuni që mbërrin

Në një server normal ndryshimi është një direktivë në konfigurimin e serverit, pranë grupit të klientëve.

push "route 10.20.0.0 255.255.0.0"

Klienti e shton kur lidhet. Mënyra e dështimit shfaqet kur i njëjti profil shtyn edhe redirect-gateway, ose kur dikush e ka shtuar tashmë route-nopull: e para e kthen sesionin në tunel të plotë, dhe e dyta hedh çdo rrugë të shtyrë, përfshirë tuajën.

Një klient që ka nevojë për sjellje të ngushtë ndaj një serveri me tunel të plotë duhet të injorojë vetëm pjesët që nuk i dëshiron. Në OpenVPN 2.4 e më pas, pull-filter ekziston pikërisht për këtë.

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

Mbani familjet e adresave të ndara: një rrugë IPv4 e shtyrë nuk bën asgjë për një shërbim të brendshëm që zgjidhet në IPv6, dhe ai shërbim dështon përmes tunelit ndërsa gjithçka tjetër duket në rregull.

Kur nënrrjeti privat nuk është në serverin VPN por pas një klienti tjetër, serveri duhet të njoftohet. Shtoni një skedar për çdo klient përmes client-config-dir që përmban iroute 10.20.0.0 255.255.0.0, plus route përkatëse, që klientët e tjerë ta mësojnë rrugën. Pa iroute serveri nuk ka asnjë arsye ta dërgojë atë prefiks pikërisht përmes atij tuneli.

IPsec: përzgjedhësit e trafikut duhet të bien dakord

Me IPsec nuk ka rrugë për të shtyrë. Dy skajet negociojnë cilat adresa jetojnë brenda tunelit, dhe trafiku jashtë përzgjedhësve të rënë dakord nuk kriptohet dhe nuk dërgohet përmes tij. Në një klient strongSwan përzgjedhësit janë eksplicitë.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Nëse porta është konfiguruar me 0.0.0.0/0 në të dyja anët, ngushtimi i IKEv2 zakonisht e zvogëlon SA-në fëmijë në kryqëzimin e dy propozimeve, që është rezultati i dëshiruar. Disa porta në vend të kësaj refuzojnë një propozim që nuk përputhet me përzgjedhësit e konfiguruar, dhe regjistri atëherë tregon një SA fëmijë të dështuar dhe jo një ankesë rrugëtimi. Kur kjo ndodh, ndryshimi i përket portës, sepse një rrugë te klienti nuk mund të krijojë një tunel për një përzgjedhës që pala tjetër nuk do ta pranojë.

Në Windows klienti i integruar e fsheh të njëjtin vendim pas dy cilësimeve. Ndarja e tunelit duhet të jetë e ndezur, dhe prefiksi duhet të regjistrohet në profil.

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

Regjistrimi i prefiksit është ai që e bën të mbijetojë një rilidhje, gjë që një rrugë e shtuar me dorë nuk e bën.

Mbani pikën fundore dhe DNS jashtë vendimit

Pika fundore e VPN duhet të mbetet e arritshme pa tunel, përndryshe tuneli shembet në vetvete. Kur rrugëtohet vetëm 10.20.0.0/16 kjo është automatike, pasi pika fundore është një adresë publike. Në një profil me tunel të plotë nuk është, dhe klienti ka nevojë për një rrugë të qartë hosti drejt pikës fundore përpara se tuneli të ngrihet.

DNS është një vendim i dytë që shtytja e rrugës nuk e merr për ju. Emrat e brendshëm zakonisht zgjidhen përmes një zgjidhësi të cilin mund ta arrijë vetëm rrjeti privat. Nëse serveri shtyn një server DNS, çdo emër kalon përmes tij; nëse nuk e bën, emrat e brendshëm ose dështojnë ose zgjidhen publikisht në diçka që nuk e kishit ndërmend. DNS i ndarë mban një domen kërkimi në zgjidhësin e brendshëm, por kjo varet nga mbështetja e klientit, prandaj trajtojeni si detyrë më vete dhe jo si efekt anësor i rrugëtimit.

Verifikoni, pastaj rinisni dhe verifikoni përsëri

Tre prova mbulojnë çështjen e rrugëtimit. Pyetni kernel-in ku do të shkonte një adresë e largët, merrni diçka nga brenda nënrrjetit, pastaj konfirmoni që një kërkesë publike e zakonshme ende del përmes lidhjes tuaj normale.

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

Rreshti i parë emërton një ndërfaqe. Nëse emërton ndërfaqen tuaj fizike, rruga nuk mbërriti kurrë. Në Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 i përgjigjet të njëjtës pyetje, dhe prova e fundit duhet të tregojë ende adresën tuaj të zakonshme dhe jo atë të serverit VPN.

Pastaj rinisni. Rrugët e shtuara me dorë zhduken, ndërsa rrugët nga profili, nga një konfigurim i shtyrë ose nga AllowedIPs kthehen. Nëse qasja e ngushtë funksionon para rinisjes dhe dështon pas saj, faji është në mënyrën se si nis tuneli, jo në vetë rrugën.

Përpara se ta shpallni të përfunduar, konfirmoni katër gjëra: prefiksi erdhi nga pronari i rrjetit dhe nuk mbivendoset me asgjë lokale, rruga e kthimit ekziston ose një rregull maskimi e zëvendëson atë, mekanizmi që konfiguruat është ai që zbaton rrugëtimin në platformën tuaj, dhe të njëjtat prova kalojnë pas një rinisjeje të pastër. Shënimet e strongSwan për përcjelljen ia vlen t'i lexoni nëse rruga e kthimit është pjesa që vazhdon të dështojë.