Kako poslati en cilj IPv4 izven tunela OpenVPN

Večina konfiguracij s polnim tunelom pošlje vsak paket skozi VPN, in prav direktiva redirect-gateway to omogoča. En cilj je vseeno mogoče izvzeti. Dodajanje poti gostitelja za ta naslov z nadomestnim znakom net_gateway pove odjemalcu, naj ga doseže skozi izvirni prehod stroja, medtem ko vse ostalo še naprej uporablja tunel.

Vrstica je videti neškodljiva in pogosto tudi je, vendar reši samo eno vprašanje: kam gredo paketi za točno ta naslov IPv4. Ne spremeni DNS, IPv6, politike požarnega zidu ali tega, kateri proces je odprl povezavo, in vsaka od teh lahko izjemo tiho izniči.

Kaj net_gateway pravzaprav poimenuje

Vnos profila za to izjemo je ena vrstica: route 198.51.100.77 255.255.255.255 net_gateway. Prvi naslov je dokumentacijski nadomestni znak za cilj, maska ga spremeni v pot enega gostitelja, zadnji žeton pa poimenuje nadomestni znak prehoda. OpenVPN pri nameščanju poti razreši nadomestne znake prehodov. vpn_gateway pomeni lastni prehod tunela, oddaljeno stran povezave VPN. net_gateway pomeni privzeti prehod, ki ga je gostitelj imel, preden je VPN kar koli spremenil, kar je običajno lokalni usmerjevalnik v fizičnem omrežju.

Tretji nadomestni znak, remote_host, se nanaša na naslov strežnika VPN in obstaja zato, da lahko tunel doseže strežnik po fizični poti. Zamenjati te tri je najpogostejši razlog, da izjema konča na napačnem mestu ali se sploh ne namesti.

Vrednost se prebere ob povezavi, ne zapiše v datoteko. Če se stroj premakne v drugo omrežje, se prehod pred VPN spremeni in pot sledi novemu. To je običajno tisto, kar želite, vendar pomeni tudi, da je vedenje izjeme odvisno od omrežja, iz katerega je odjemalec začel.

Zakaj pot gostitelja premaga privzeto pot tunela

Usmerjanje odloči najbolj specifična ujemajoča predpona. redirect-gateway def1 običajno ne nadomesti privzete poti; doda dve polovici, pot za spodnjo polovico naslovnega prostora in eno za zgornjo, tako da prvotna privzeta pot ostane ohranjena za druge namene. Ti polovici sta širši od enega naslova.

Pot za en naslov z masko 255.255.255.255 je /32, kar je največja specifičnost, ki jo IPv4 lahko doseže. Ko se ocenjuje paket za ta naslov, se /32 ujema in zmaga ne glede na to, katera pot je bila nameščena prva. To je mehanizem za izjemo in deluje enako v Linuxu, macOS in Windows, dokler pot res obstaja.

Windows doda drugo dimenzijo. Ko sta dve poti enako specifični, zmaga tista z nižjo metriko, omrežni vmesnik VPN pa lahko nosi metriko vmesnika, ki spremeni izid. /32 je še vedno bolj specifična od polovic, zato izjema običajno velja, vendar zastarela pot iz prejšnje seje lahko da zavajajoč rezultat, če je enako specifična.

Česa izjema ne pokriva

DNS je prva vrzel. Odjemalec lahko potisne notranje nastavitve razreševalnika, operacijski sistem pa jih bo še naprej uporabljal za poizvedbe. Aplikacija, ki razreši ime pred povezavo, lahko dobi notranji naslov za storitev, ki bi morala iti neposredno, ali zunanji naslov, ki se pravilno razreši, a se nato spotakne ob naslednjo vrzel.

IPv6 je druga. Direktiva poti obravnava samo IPv4. Cilj z dvojnim skladom lahko daje prednost IPv6, ki glede na politiko sledi tunelu ali privzeti poti IPv6 gostitelja, zato izjema IPv4 nikoli ne stopi v veljavo. Potrebujete ustrezno pot IPv6 ali zavestno odločitev, da za tega odjemalca onemogočite IPv6.

Obseg aplikacij je tretji. Pravilo temelji na cilju, zato vsak proces, ki se poveže na ta naslov, uporablja neposredno pot, ne glede na to, ali je to tisti, ki ste ga imeli v mislih. Nasprotno pa lahko spletno mesto odgovarja z več naslovov, zato izvzetje enega /32 ne izvzame mesta. Če je resnična zahteva usmerjanje po aplikacijah, je usmerjevalna tabela odjemalca Community napačno orodje.

Preverjanje izjeme brez zavajanja sebe

Začnite z nameščeno potjo, ne s pregledovalnikom. V Linuxu vprašajte jedro, katero pot in naslednji skok bo uporabilo za določen naslov; v Windows preberite usmerjevalno tabelo za ta /32. Potrdite, da je prehod fizični in ne tunel. Če vnosa ni, profil ni bil uporabljen ali pa odjemalec ni imel pravice spreminjati poti.

Nato preizkusite dva cilja. Zahteva na izvzeti naslov bi morala oditi skozi fizični vmesnik, zahteva na notranji kontrolni naslov pa bi še vedno morala uporabljati tunel. Preizkušanje samo izvzetega naslova ne dokaže ničesar o preostalem delu tunela, preizkušanje javnega spletnega mesta pa preizkusi naslov, na katerega se je to mesto razrešilo, ki morda ni tisti iz pravila.

Na koncu preverite kontrolnike, ki lahko preglasijo pot. Kill switch na strani odjemalca ali nastavitev block-outside-dns v Windows lahko prepove neposreden promet, kar se pokaže kot povezava, ki ne uspe, čeprav je pot pravilna. Teh kontrolnikov ne izklopite zato, da bi izjema delovala; če politika prepoveduje neposredno pot, je izjema oblikovalski problem za lastnika storitve VPN.

Ponovno preverite po ponovni povezavi ali menjavi omrežja, ker sta prehod pred VPN in razpoložljiva pot lastnosti trenutka, ne profila.