Nola bidali VPN bidez azpisare pribatu bakarra

Aukeratu bezeroaren ibilbidearen, zerbitzariak bultzatutako ibilbidearen eta negoziatutako hautatzaileen artean, eta gero eraman azpisare pribatu bat tunel osoa gabe.

Tunelaren bidez azpisare pribatu bat eta beste guztia zure ohiko bidetik pasatzea eskaera txikia da, baina hainbat modu daude gaizki egiteko. Emaitza ez du split tunneling izeneko kontrol-laukiak erabakitzen, baizik eta erabakia non betearazten den: bezeroaren beraren ibilbide-taulak, zerbitzariak bultzatutako ibilbide batek edo bi muturrek negoziatutako politikak. Geruza okerra aukeratuta, inoiz nahi ez zenuen tunel osoa lortuko duzu, edo beste aldeak onartzeari uko egiten dion tunel baterako ibilbidea. Konfigurazio bat ireki aurretik hiru baldintzako proba erabiltzen dut, eta gero beheko mekanismoetako bat aukeratzen dut.

Diseinua erabakitzen duten hiru baldintza

Lehenik, sarearen jabearen aurrizki eta maskara zehatzak behar dituzu. 10.x sareak ez da aurrizkia; 10.20.0.0/16 da. Egiaztatu zure etxeko LANarekin, Docker zubi batekin edo exekutatzen duzun beste VPN batekin gainjartzen ez dela, gainjartzeak ibilbidea anbiguoa egiten baitu eta kernelak nahi ez zenuen sarrera hautatzen baitu.

Bigarrenik, nor arduratzen da itzulerako trafikoaz. Pakete bat tunelera bideratzeak VPN zerbitzarira soilik eramaten du. Azpisarea zure bezeroen multzorako itzulerako ibilbiderik ez duen beste bideratzaile baten atzean badago, zerbitzariak trafikoa maskaratu behar du, edo bideratzaile horrek zure multzoa ikasi behar du. Bezeroaren aldeko ibilbide batek ere ez du falta den itzulerako bidea konpontzen.

Hirugarrenik, betearazpen-puntua. Bezero batzuek ibilbide bat instalatzen dute eta sistema eragileak egiten du gainerakoa. Beste batzuek politika bat negoziatzen dute, eta atebideak onartzen ez duen politikak ez du tunelik sortzen: paketeak begi-bistako errorerik gabe baztertzen dira. Aurkitu bietatik zein den zurea ezer idatzi aurretik.

WireGuard: AllowedIPs da ibilbide-taula

Bezeroan, AllowedIPs k tunela sartu dezaketen helmugak zerrendatzen ditu, eta wg-quick k sarrera bakoitza ibilbide arrunt bihurtzen du. Beraz, zeregin honetako bezeroaren erdia lerro bakarra da.

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

Orain alderatu zerbitzariak bezero berarentzako duen sarrera. Zerbitzariak bezeroari zer bidaliko dion deskribatzen du, eta hori normalean bezeroaren tunel-helbidea da, ez azpisare pribatua.

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

Bi horiek trukatzea da sarrien ikusten dudan akatsa. 10.20.0.0/16 zerbitzariaren peer atalean jartzeak azpisare osoa bezero horren atzean dagoela adierazten du, eta hori gunez guneko aldarrikapena da, ez baimena. Inongo peer baten AllowedIPs-arekin bat ez datozen paketeak isilka baztertzen dira, beraz sarrera okerra suebaki arazo baten itxura du zehazki.

Ibilbideak zuk zeuk kudeatzen badituzu, ezarri Table = off [Interface] ren azpian eta gehitu nahi duzun ibilbidea. Orduan ez da ezer automatikoki gehitzen, beraz ibilbidea interfazea igotzen duenaren barruan dago.

OpenVPN: bultzatu ibilbidea eta gero ziurtatu heltzen dela

Zerbitzari arrunt batean aldaketa direktiba bat da zerbitzariaren konfigurazioan, bezeroen multzoaren ondoan.

push "route 10.20.0.0 255.255.0.0"

Bezeroak konektatzean gehitzen du. Hutsegite-modua agertzen da profil berak redirect-gateway ere bultzatzen duenean, edo norbaitek route-nopull jada gehitu duenean: lehenengoak saioa tunel oso bihurtzen du, eta bigarrenak bultzatutako ibilbide guztiak botatzen ditu, zurea barne.

Tunel osoko zerbitzari baten aurrean portaera estua behar duen bezeroak nahi ez dituen zatiak soilik ezikusi behar ditu. OpenVPN 2.4 eta geroagoko bertsioetan, pull-filter horretarako bertarako dago.

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

Eduki helbide-familia bereiziak: bultzatutako IPv4 ibilbide batek ezer ez du egiten IPv6-ra ebazten den barne-zerbitzu batentzat, eta zerbitzu horrek tunelaren bidez huts egiten du, gainerako guztia ondo dagoen bitartean.

Azpisare pribatua VPN zerbitzarian ez dagoenean beste bezero baten atzean baizik, zerbitzariari jakinarazi behar zaio. Gehitu bezero bakoitzeko fitxategi bat client-config-dir bidez iroute 10.20.0.0 255.255.0.0 daukana, gehi dagokion route, beste bezeroek bidea ikas dezaten. iroute gabe, zerbitzariak ez du arrazoirik aurrizki hori tunel zehatz horretatik bidaltzeko.

IPsec: trafiko-hautatzaileek bat etorri behar dute

IPsec-en ez dago bultzatzeko ibilbiderik. Bi muturrek negoziatzen dute zein helbide bizi diren tunelaren barruan, eta adostutako hautatzaileetatik kanpoko trafikoa ez da zifratzen ez eta haren bidez bidaltzen. strongSwan bezero batean hautatzaileak esplizituak dira.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Atebidea bi aldeetan 0.0.0.0/0 rekin konfiguratuta badago, IKEv2-ren estutzeak SA alaba bi proposamenen ebakidurara murrizten du normalean, eta hori da nahi duzun emaitza. Atebide batzuek, ordea, beren hautatzaile konfiguratuekin bat ez datorren proposamena ukatzen dute, eta erregistroak SA alaba huts egina erakusten du, bideratze-kexa baten ordez. Hori gertatzen denean aldaketa atebidearena da, bezeroaren ibilbideak ezin baitu beste aldeak onartuko ez duen hautatzaile baterako tunelik sortu.

Windowsen barneko bezeroak erabaki bera bi ezarpenen atzean ezkutatzen du. Tunelaren banaketa piztuta egon behar da, eta aurrizkia profilean erregistratu behar da.

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

Aurrizkia erregistratzea da berriro konektatzean iraunarazten duena, eskuz gehitutako ibilbide batek egiten ez duena.

Eduki muturra eta DNS erabakitik kanpo

VPN muturrak tunelik gabe irisgarri jarraitu behar du, bestela tunela bere baitan erortzen da. 10.20.0.0/16 soilik bideratzen denean automatikoa da, muturra helbide publikoa baita. Tunel osoko profilean ez da hala, eta bezeroak muturrerainoko ostalari-ibilbide esplizitua behar du tunela igo aurretik.

DNS bigarren erabaki bat da, eta ibilbidea bultzatzeak ez du zure ordez hartzen. Barne-izenak normalean sare pribatuak soilik irits dezakeen ebaztzaile baten bidez ebazten dira. Zerbitzariak DNS zerbitzari bat bultzatzen badu, izen guztiak haren bidez joaten dira; bultzatzen ez badu, barne-izenek huts egiten dute edo publikoki nahi ez zenuen zerbaitetara ebazten dira. DNS bananduak bilaketa-domeinu bat mantentzen du barne-ebaztzailean, baina bezeroaren laguntzaren araberakoa da, beraz hartu zeregin propio gisa, bideratzearen albo-ondorio gisa baino.

Egiaztatu, gero berrabiarazi eta egiaztatu berriro

Hiru probak estaltzen dute bideratzearen galdera. Galdetu kernelari urruneko helbide bat nora joango litzatekeen, jaitsi zerbait azpisarearen barnetik, eta gero egiaztatu ohiko eskaera publiko bat zure konexio arruntetik irteten jarraitzen duela.

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

Lehen lerroak interfaze bat izendatzen du. Zure interfaze fisikoa izendatzen badu, ibilbidea ez da inoiz heldu. Windowsen Find-NetRoute -RemoteIPAddress 10.20.5.7 k galdera berari erantzuten dio, eta azken probak zure ohiko helbidea erakusten jarraitu behar du, VPN zerbitzariarena ez.

Gero berrabiarazi. Eskuz gehitutako ibilbideak desagertu egiten dira, eta profiletik, bultzatutako konfiguraziotik edo AllowedIPs tik datozen ibilbideak itzuli egiten dira. Sarbide estuak berrabiarazi aurretik funtzionatzen badu eta ondoren huts egiten badu, errua tuneleko abioan dago, ez ibilbidean bertan.

Amatutzat eman aurretik, egiaztatu lau gauza: aurrizkia sarearen jabeari heldu zaiola eta ez dela ezer lokalekin gainjartzen, itzulerako bidea badagoela edo maskaratze-arau batek ordezkatzen duela, konfiguratu duzun mekanismoa zure plataforman bideratzea betearazten duena dela, eta proba berberak ondo pasatzen direla berrabiarazte garbi baten ondorengo. strongSwanen birbidaltze-oharrak irakurtzea merezi du itzulerako bidea behin eta berriz huts egiten duen zatia bada.

Erlazionatutako artikuluak