Kako skozi VPN poslati samo eno zasebno podomrežje

Eno zasebno podomrežje skozi tunel in vse ostalo po običajni poti je majhna zahteva z veliko načini, kako jo pokvariti. Rezultata ne odloča potrditveno polje z imenom split tunneling, ampak kje se odločitev uveljavlja: v lastni tabeli poti odjemalca, v poti, ki jo pošilja strežnik, ali v politiki, o kateri se dogovorita oba konca. Izberite napačen sloj in dobite bodisi celoten tunel, ki ga nikoli niste želeli, bodisi pot v tunel, ki ga druga stran noče sprejeti. Preden odprem katero koli konfiguracijo, uporabim preizkus s tremi pogoji, nato izberem enega od spodnjih mehanizmov.

Trije pogoji, ki določijo zasnovo

Najprej potrebujete natančen predponek in masko od lastnika omrežja. Omrežje 10.x ni predponek; 10.20.0.0/16 je. Preverite, da se ne prekriva z vašim domačim omrežjem LAN, mostom Docker ali drugim VPN, ki ga poganjate, ker prekrivanje naredi pot dvoumno in jedro izbere vnos, ki ga niste nameravali.

Drugič, kdo odgovarja na povratni promet. Usmerjanje paketa v tunel ga pripelje le do strežnika VPN. Če podomrežje leži za drugim usmerjevalnikom, ki nima poti nazaj v vaš nabor odjemalcev, mora strežnik promet maskirati, ali pa se mora ta usmerjevalnik naučiti vašega nabora. Nobena pot na strani odjemalca ne popravi manjkajoče povratne poti.

Tretjič, točka uveljavljanja. Nekateri odjemalci namestijo pot in operacijski sistem naredi ostalo. Drugi se pogajajo o politiki, in politika, ki je prehod ne sprejme, ne ustvari nobenega tunela: paketi se zavržejo brez očitne napake. Ugotovite, kateri od obeh primerov je vaš, preden karkoli napišete.

WireGuard: AllowedIPs je tabela poti

Na odjemalcu AllowedIPs našteje cilje, ki smejo vstopiti v tunel, in wg-quick vsak vnos spremeni v običajno pot. Odjemalska polovica te naloge je torej ena vrstica.

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

Zdaj primerjajte vnos strežnika za istega odjemalca. Opisuje, kaj bo strežnik poslal odjemalcu, kar je običajno naslov tunela odjemalca, ne zasebno podomrežje.

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

Zamenjava teh dveh je napaka, ki jo vidim najpogosteje. Če 10.20.0.0/16 postavite pod peer razdelek strežnika, to trdi, da celotno podomrežje leži za tem odjemalcem, in to je zahteva od lokacije do lokacije, ne dovoljenje. Paketi, ki se ne ujemajo z AllowedIPs nobenega peera, se tiho zavržejo, zato napačen vnos izgleda natanko kot težava z požarnim zidom.

Če poti upravljate sami, nastavite Table = off pod [Interface] in dodajte pot, ki jo želite. Takrat se nič ne doda samodejno, zato pot spada k tistemu, kar dvigne vmesnik.

OpenVPN: potisnite pot in nato poskrbite, da prispe

Na običajnem strežniku je sprememba ena direktiva v konfiguraciji strežnika, ob naboru odjemalcev.

push "route 10.20.0.0 255.255.0.0"

Odjemalec jo doda ob povezavi. Način okvare se pokaže, ko isti profil potisne tudi redirect-gateway, ali ko je nekdo že dodal route-nopull: prvo spremeni sejo v celoten tunel, drugo zavrže vsako potisnjeno pot, tudi vašo.

Odjemalec, ki potrebuje ozko vedenje proti strežniku s celotnim tunelom, naj prezre le dele, ki jih ne želi. V OpenVPN 2.4 in novejših obstaja pull-filter prav za to.

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

Držite naslovne družine ločene: potisnjena pot IPv4 ne naredi nič za notranjo storitev, ki se razrešuje v IPv6, in ta storitev odpove skozi tunel, medtem ko je vse drugo videti v redu.

Ko zasebno podomrežje ni na strežniku VPN, ampak za drugim odjemalcem, je treba strežnik obvestiti. Dodajte datoteko za vsakega odjemalca prek client-config-dir, ki vsebuje iroute 10.20.0.0 255.255.0.0, plus ustrezno route, da se drugi odjemalci naučijo poti. Brez iroute strežnik nima razloga pošiljati te predpone prav skozi tisti tunel.

IPsec: izbirniki prometa se morajo ujemati

Pri IPsec ni poti za potiskanje. Oba konca se dogovorita, kateri naslovi živijo v tunelu, promet zunaj dogovorjenih izbirnikov pa ni šifriran in ne gre skozenj. Na odjemalcu strongSwan so izbirniki izrecni.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Če je prehod na obeh straneh konfiguriran z 0.0.0.0/0, zoženje IKEv2 običajno zmanjša podrejeni SA na presečišče obeh predlogov, kar je želeni izid. Nekateri prehodi namesto tega zavrnejo predlog, ki se ne ujema z njihovimi konfiguriranimi izbirniki, in dnevnik takrat pokaže neuspeli podrejeni SA, ne pritožbe zaradi usmerjanja. Ko se to zgodi, sprememba pripada prehodu, ker pot na odjemalcu ne more ustvariti tunela za izbirnik, ki ga druga stran ne bo sprejela.

V Windows vgrajeni odjemalec skriva isto odločitev za dvema nastavitvama. Razdelitev tunela mora biti vklopljena, predponek pa mora biti registriran v profilu.

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

Prav registracija predponka mu omogoči, da preživi ponovno povezavo, česar ročno dodana pot ne stori.

Držite končno točko in DNS zunaj odločitve

Končna točka VPN mora ostati dosegljiva brez tunela, sicer se tunel zruši sam vase. Ko se usmerja samo 10.20.0.0/16, je to samodejno, ker je končna točka javni naslov. V profilu celotnega tunela ni tako, in odjemalec potrebuje izrecno pot do gostitelja končne točke, preden se tunel dvigne.

DNS je druga odločitev, ki je potiskanje poti ne sprejme namesto vas. Notranja imena se običajno razrešujejo prek razreševalnika, ki mu lahko dostopa le zasebno omrežje. Če strežnik potisne strežnik DNS, gre vsako ime skozenj; če ga ne, notranja imena bodisi odpovejo bodisi se javno razrešijo v nekaj, česar niste nameravali. Razdeljeni DNS ohrani eno iskalno domeno na notranjem razreševalniku, a to je odvisno od podpore odjemalca, zato to obravnavajte kot ločeno nalogo in ne kot stranski učinek usmerjanja.

Preverite, nato znova zaženite in znova preverite

Trije preizkusi pokrijejo vprašanje usmerjanja. Vprašajte jedro, kam bi šel oddaljen naslov, prenesite nekaj iz notranjosti podomrežja in nato potrdite, da običajna javna zahteva še vedno odhaja po vaši običajni povezavi.

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

Prva vrstica poimenuje vmesnik. Če poimenuje vaš fizični vmesnik, pot ni nikoli prispela. V Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 odgovori na isto vprašanje, zadnji preizkus pa bi moral še vedno kazati vaš običajni naslov in ne naslova strežnika VPN.

Nato znova zaženite. Ročno dodane poti izginejo, medtem ko se poti iz profila, iz potisnjene konfiguracije ali iz AllowedIPs vrnejo. Če ozek dostop deluje pred ponovnim zagonom in po njem odpove, je krivda v tem, kako se tunel zažene, ne v sami poti.

Preden to razglasite za končano, potrdite štiri stvari: predponek je prišel od lastnika omrežja in se ne prekriva z ničimer lokalnim, povratna pot obstaja ali jo nadomesti pravilo maskiranja, mehanizem, ki ste ga konfigurirali, je tisti, ki uveljavlja usmerjanje na vaši platformi, in isti preizkusi uspejo po čistem ponovnem zagonu. Opombe strongSwan o posredovanju so vredne branja, če je povratna pot tisti del, ki vedno znova odpove.