Hoe jo ien IPv4-bestimming bûten in OpenVPN-tunnel stjoere

De measte folsleine tunnelopsetten stjoere elk pakket troch de VPN, en redirect-gateway is de rjochtline dy't dat mooglik makket. Ien inkele bestimming kin dochs útsûndere wurde. In hostrûte foar dat adres mei de net_gateway-plakhâlder fertelt de kliïnt dat er it fia de oarspronklike gateway fan 'e masine berikke moat, wylst al it oare de tunnel bliuwt brûken.

De rigel liket ûnskuldich en is dat faak, mar hy beslist mar ien fraach: wêr't pakketten foar krekt dat IPv4-adres hinne geane. Hy feroaret DNS, IPv6, firewallbelied of hokker proses de ferbining iepene hat net, en elk dêrfan kin de útsûndering stilwei teniet dwaan.

Wat net_gateway eins beneamt

De profilyngong foar dy útsûndering is ien rigel: route 198.51.100.77 255.255.255.255 net_gateway. It earste adres is in dokumintaasjeplakhâlder foar de bestimming, it masker makket der in hostrûte fan ien host fan, en it lêste token beneamt de gateway-plakhâlder. OpenVPN lost gateway-plakhâlders op as er rûtes ynstallearret. vpn_gateway betsjut de eigen gateway fan 'e tunnel, de fiere kant fan 'e VPN-ferbining. net_gateway betsjut de standertgateway dy't de host hie foardat de VPN wat feroare, meastentiids de lokale router op it fysike netwurk.

In tredde plakhâlder, remote_host, ferwiist nei it adres fan 'e VPN-tsjinner, en hy bestiet sadat de tunnel de tsjinner oer it fysike paad berikke kin. Dizze trije trochinoar helje is de meast foarkommende reden dat in útsûndering op it ferkearde plak bedarret of hielendal net ynstallearret.

De wearde wurdt lêzen by it ferbinen, net yn it bestân skreaun. As de masine nei in oar netwurk ferhuzet, feroaret de gateway foar de VPN en folget de rûte de nije. Dat is meastentiids wat jo wolle, mar it betsjut ek dat it gedrach fan 'e útsûndering ôfhinget fan it netwurk dêr't de kliïnt út begûn.

Wêrom't in hostrûte de standertrûte fan 'e tunnel wint

Rûtering wurdt beslist troch it meast spesifike oerienkommende foarheaksel. redirect-gateway def1 ferfangt normaal net de standertrûte; hy foeget twa helten ta, in rûte foar de ûnderste helte fan 'e adresromte en ien foar de boppeste helte, sadat de oarspronklike standertrûte foar oar gebrûk bewarre bliuwt. Dy helten binne breder as ien adres.

In rûte foar ien adres mei masker 255.255.255.255 is in /32, wat sa spesifyk is as IPv4 wurde kin. As in pakket foar dat adres beoordeile wurdt, past de /32 en wint, itsij hokker rûte earst ynstallearre waard. Dat is it meganisme efter de útsûndering, en it wurket itselde op Linux, macOS en Windows salang't de rûte echt oanwêzich is.

Windows foeget in twadde diminsje ta. As twa rûtes like spesifyk binne, wint dy mei de legere metryk, en in VPN-adapter kin in ynterfacemetryk drage dy't it resultaat feroaret. In /32 is noch altyd spesifiker as de helten, dus de útsûndering hâldt normaal, mar in ferâlene rûte út in eardere sesje kin in ferwarjend resultaat jaan as dy like spesifyk is.

Wat de útsûndering net dekt

DNS is de earste gat. De kliïnt kin ynterne resolverynstellingen trochdrukke, en it bestjoeringssysteem sil dy foar opfragen bliuwe brûken. In applikaasje dy't in namme oplost foardat er ferbynt, kin in yntern adres krije foar in tsjinst dy't direkt gean moat, of in ekstern adres dat goed oplost mar dan oer it folgjende gat stroffelje.

IPv6 is de twadde. De rûterjochtline behannelt allinnich IPv4. In bestimming mei dûbele stapel kin IPv6 foarkarje, dat ôfhinklik fan belied de tunnel of de IPv6-standertrûte fan 'e host folget, sadat de IPv4-útsûndering nea yn wurking komt. Jo hawwe in bypassende IPv6-rûte nedich, of in bewust beslút om IPv6 foar dy kliïnt út te skeakeljen.

Applikaasjeberik is de tredde. De regel is op bestimming basearre, dus elk proses dat mei dat adres ferbynt, brûkt it direkte paad, oft it no dejinge is dy't jo yn 't sin hienen of net. Oarsom kin in webside fan ferskate adressen antwurdzje, dus ien /32 útsûnderje útsûndert de side net. As de echte eask rûtering per applikaasje is, dan is de rûttetabel fan 'e Community-kliïnt it ferkearde ark.

De útsûndering kontrolearje sûnder dysels te ferrifeljen

Begjin mei de ynstallearre rûte, net mei in browser. Freegje op Linux de kernel hokker rûte en folgjende hop er foar it spesifike adres brûke sil; lês op Windows de rûttetabel foar dy /32. Befêstigje dat de gateway de fysike is en net de tunnel. As de yngong mist, is it profyl net tapast of hie de kliïnt it foech net om rûtes te feroarjen.

Test dan twa bestimmingen. In fersyk nei it útsûndere adres moat fia de fysike ynterface fuortgean, en in fersyk nei in yntern kontrôleadres moat noch de tunnel brûke. Allinnich it útsûndere adres testen bewiist neat oer de rest fan 'e tunnel, en in iepenbiere webside testen test it adres dêr't dy side nei oplost is, dat miskien net it adres út 'e regel is.

Kontrolearje ta beslút de kontrôles dy't de rûte oerskriuwe kinne. In kill switch oan 'e kliïntkant of in Windows-ynstelling block-outside-dns kin direkte ferkear ferbiede, wat him sjen lit as in ferbining dy't mislearret ek al is de rûte korrekt. Skeakelje dy kontrôles net út om de útsûndering wurkje te litten lykje; as it belied it direkte paad ferbiedt, is de útsûndering in ûntwerpprobleem foar wa't de VPN-tsjinst besit.

Kontrolearje op 'e nij nei opnij ferbinen of netwurkferoaring, want de gateway foar de VPN en it beskikbere paad binne eigenskippen fan it momint, net fan it profyl.