Kiel sendi nur unu privatan subreton tra la VPN

Elektu inter itinero sur la kliento, itinero puŝata de la servilo kaj negocitaj selektiloj, poste portu unu privatan subreton sen plena tunelo.

Unu privata subreto tra la tunelo kaj ĉio alia laŭ via normala vojo estas malgranda peto kun multaj manieroj erari. La rezulton decidas ne la markobutono nomata split tunneling, sed kie la decido estas trudata: la propra itinertabelo de la kliento, itinero kiun la servilo puŝas, aŭ politiko kiun la du flankoj negocas. Elektu la malĝustan tavolon kaj vi ricevas aŭ plenan tunelon, kiun vi neniam volis, aŭ itineron en tunelon, kiun la alia flanko rifuzas akcepti. Mi uzas teston kun tri kondiĉoj antaŭ malfermi iun ajn agordon, poste mi elektas unu el la mekanismoj sube.

Tri kondiĉoj, kiuj decidas la dezajnon

Unue, vi bezonas la precizan prefikson kaj maskon de la posedanto de la reto. La reto 10.x ne estas prefikso; 10.20.0.0/16 estas. Konfirmu, ke ĝi ne interkovras vian hejman LAN, Docker-ponton aŭ alian VPN, kiun vi funkciigas, ĉar interkovro igas la itineron ambigua kaj la kerno elektas la eron, kiun vi ne intencis.

Due, kiu respondas la revenan trafikon. Enitinerigi paketon en la tunelon nur alportas ĝin al la VPN-servilo. Se la subreto troviĝas malantaŭ alia enkursigilo, kiu havas neniun itineron reen al via klienta baseno, la servilo devas maski la trafikon, aŭ tiu enkursigilo devas lerni vian basenon. Neniu itinero ĉe la klienta flanko riparas mankantan revenan vojon.

Trie, la punkto de trudado. Iuj klientoj instalas itineron kaj la operaciumo faras la reston. Aliaj negocas politikon, kaj politiko, kiun la enirejo ne akceptas, tute ne produktas tunelon: pakaĵoj estas forĵetitaj sen videbla eraro. Eltrovu, kiun el la du vi havas, antaŭ ol skribi ion ajn.

WireGuard: AllowedIPs estas la itinertabelo

Ĉe la kliento, AllowedIPs listigas la celojn rajtantajn eniri la tunelon, kaj wg-quick transformas ĉiun eron en ordinaran itineron. Do la klienta duono de tiu ĉi tasko estas unu linio.

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

Nun komparu la eron de la servilo por tiu sama kliento. Ĝi priskribas, kion la servilo sendos al la kliento, kio kutime estas la tunela adreso de la kliento, ne la privata subreto.

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

Interŝanĝi tiujn du estas la eraro, kiun mi vidas plej ofte. Meti 10.20.0.0/16 sub la peer-sekcion de la servilo asertas, ke la tuta subreto loĝas malantaŭ tiu kliento, kio estas aserto de ejo-al-ejo, ne permeso. Pakaĵoj, kiuj kongruas kun la AllowedIPs de neniu peer, estas silenteme forĵetitaj, do malĝusta ero aspektas precize kiel fajroŝirma problemo.

Se vi mem administras la itinerojn, agordu Table = off sub [Interface] kaj aldonu la itineron, kiun vi volas. Tiam nenio aldoniĝas aŭtomate, do la itinero apartenas al tio, kio levigas la interfacon.

OpenVPN: puŝu la itineron, poste certiĝu, ke ĝi alvenas

Ĉe normala servilo la ŝanĝo estas unu direktivo en la servila agordo, apud la klienta baseno.

push "route 10.20.0.0 255.255.0.0"

La kliento aldonas ĝin, kiam ĝi konektiĝas. La fiaskmaniero aperas, kiam la sama profilo ankaŭ puŝas redirect-gateway, aŭ kiam iu jam aldonis route-nopull: la unua igas la seancon plena tunelo, kaj la dua forĵetas ĉiun puŝitan itineron, inkluzive vian.

Kliento, kiu bezonas mallarĝan konduton kontraŭ plentunela servilo, devus ignori nur la partojn, kiujn ĝi ne volas. En OpenVPN 2.4 kaj poste, pull-filter ekzistas ĝuste por tio.

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

Tenu adresfamiliojn aparte: puŝita itinero IPv4 faras nenion por interna servo, kiu solviĝas al IPv6, kaj tiu servo fiaskas tra la tunelo, dum ĉio alia aspektas bone.

Kiam la privata subreto ne estas ĉe la VPN-servilo sed malantaŭ alia kliento, la servilo devas esti informita. Aldonu dosieron por ĉiu kliento per client-config-dir enhavantan iroute 10.20.0.0 255.255.0.0, plus la kongruan route, por ke aliaj klientoj lernu la vojon. Sen iroute la servilo havas neniun kialon sendi tiun prefikson tra ĝuste tiu tunelo.

IPsec: la trafikselektiloj devas konsenti

Ĉe IPsec ne ekzistas itinero por puŝi. La du flankoj negocas, kiuj adresoj loĝas interne de la tunelo, kaj trafiko ekster la interkonsentitaj selektiloj nek estas ĉifrita nek sendita tra ĝi. Ĉe strongSwan-kliento la selektiloj estas eksplicitaj.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Se la enirejo estas agordita kun 0.0.0.0/0 ĉe ambaŭ flankoj, la mallarĝigo de IKEv2 kutime reduktas la infanan SA al la komunaĵo de la du proponoj, kio estas la dezirata rezulto. Iuj enirejoj anstataŭe rifuzas proponon, kiu ne kongruas kun iliaj agorditaj selektiloj, kaj la protokolo tiam montras fiaskintan infanan SA anstataŭ plendon pri enitinerigo. Kiam tio okazas, la ŝanĝo apartenas al la enirejo, ĉar klienta itinero ne povas krei tunelon por selektilo, kiun la alia flanko ne akceptos.

Ĉe Windows la enkonstruita kliento kaŝas la saman decidon malantaŭ du agordoj. Divido de la tunelo devas esti ŝaltita, kaj la prefikso devas esti registrita ĉe la profilo.

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

Ĝuste la registrado de la prefikso faras, ke ĝi postvivas rekonekton, kion mane aldonita itinero ne faras.

Tenu la finpunkton kaj DNS ekster la decido

La VPN-finpunkto devas resti atingebla sen la tunelo, alie la tunelo kolapsas en sin mem. Kiam nur 10.20.0.0/16 estas enitinerigita, tio estas aŭtomata, ĉar la finpunkto estas publika adreso. Ĉe plentunela profilo ĝi ne estas, kaj la kliento bezonas eksplicitan gastigan itineron al la finpunkto antaŭ ol la tunelo leviĝas.

DNS estas dua decido, kiun puŝo de itinero ne faras por vi. Internaj nomoj kutime solviĝas per solvilo, kiun nur la privata reto povas atingi. Se la servilo puŝas DNS-servilon, ĉiu nomo trapasas ĝin, dum se ĝi ne faras tion, internaj nomoj aŭ fiaskas aŭ solviĝas publike al io, kion vi ne intencis. Dividita DNS tenas unu serĉdomajnon ĉe la interna solvilo, sed tio dependas de klienta subteno, do traktu ĝin kiel propran taskon anstataŭ kiel flankefikon de enitinerigo.

Kontrolu, poste restartigu kaj kontrolu denove

Tri provoj kovras la demandon pri enitinerigo. Demandu la kernon, kien irus fora adreso, elŝutu ion el la interno de la subreto, poste konfirmu, ke ordinara publika peto ankoraŭ eliras per via normala konekto.

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

La unua linio nomas interfacon. Se ĝi nomas vian fizikan interfacon, la itinero neniam alvenis. Ĉe Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 respondas la saman demandon, kaj la lasta provo devus ankoraŭ montri vian ordinaran adreson anstataŭ tiun de la VPN-servilo.

Poste restartigu. Itineroj aldonitaj mane malaperas, dum itineroj el la profilo, el puŝita agordo aŭ el AllowedIPs revenas. Se mallarĝa aliro funkcias antaŭ la restartigo kaj fiaskas poste, la kaŭzo estas en kiel la tunelo startas, ne en la itinero mem.

Antaŭ ol nomi ĝin preta, konfirmu kvar aferojn: la prefikso venis de la posedanto de la reto kaj interkovras nenion lokan, la reena vojo ekzistas aŭ anstataŭigas ĝin maska regulo, la mekanismo, kiun vi agordis, estas tiu, kiu trudas enitinerigon sur via platformo, kaj la samaj provoj pasas post pura restartigo. La notoj de strongSwan pri plusendo indas legi, se la reena vojo estas la parto, kiu daŭre fiaskas.

Rilataj artikoloj