Kiel sendi unu IPv4-celon ekster OpenVPN-tunelon

Plej multaj plen-tunelaj agordoj sendas ĉiun paketon tra la VPN, kaj la direktivo redirect-gateway ebligas tion. Unu sola celo tamen povas esti esceptita. Aldoni gastigilan vojon por tiu adreso kun la anstataŭilo net_gateway diras al la kliento atingi ĝin tra la origina kluzo de la maŝino, dum ĉio alia daŭre uzas la tunelon.

La linio ŝajnas sendanĝera kaj ofte estas, sed ĝi solvas nur unu demandon: kien iras paketoj por ĝuste tiu IPv4-adreso. Ĝi ŝanĝas nek DNS, nek IPv6, nek fajroŝirmilan politikon, nek kiun procezon malfermis la konekton, kaj ĉiu el tiuj povas silente nuligi la escepton.

Kion net_gateway fakte nomas

La profilerco por tiu escepto estas unu linio: route 198.51.100.77 255.255.255.255 net_gateway. La unua adreso estas dokumenta anstataŭilo por la celo, la masko faras ĝin unu-gastigila vojo, kaj la lasta ĵetono nomas la kluzan anstataŭilon. OpenVPN solvas kluzajn anstataŭilojn kiam ĝi instalas vojojn. vpn_gateway signifas la propran kluzon de la tunelo, la malproksiman flankon de la VPN-ligilo. net_gateway signifas la implican kluzon, kiun la gastigilo havis antaŭ ol la VPN ŝanĝis ion ajn, kiu kutime estas la loka enkursigilo sur la fizika reto.

Tria anstataŭilo, remote_host, rilatas al la adreso de la VPN-servilo, kaj ĝi ekzistas por ke la tunelo povu atingi la servilon laŭ la fizika vojo. Konfuzi ĉi tiujn tri estas la plej ofta kaŭzo, ke escepto iras al la malĝusta loko aŭ tute ne instaliĝas.

La valoro estas legata ĉe konekta tempo, ne skribata en la dosieron. Se la maŝino transiras al alia reto, la kluzo antaŭ la VPN ŝanĝiĝas kaj la vojo sekvas la novan. Tio kutime estas tio, kion vi volas, sed ĝi ankaŭ signifas, ke la konduto de la escepto dependas de la reto, el kiu la kliento ekis.

Kial gastigila vojo venkas la implican vojon de la tunelo

Enkursigado estas decidata per la plej specifa kongrua prefikso. redirect-gateway def1 kutime ne anstataŭas la implican vojon; ĝi aldonas du duonojn, vojon por la malsupra duono de la adresaro kaj unu por la supra duono, tiel ke la origina implica vojo restas konservita por aliaj uzoj. Tiuj duonoj estas pli larĝaj ol unu sola adreso.

Vojo por unu adreso kun la masko 255.255.255.255 estas /32, kio estas tiel specifa kiel IPv4 povas esti. Kiam paketo por tiu adreso estas taksata, la /32 kongruas kaj venkas sendepende de tio, kiu vojo estis instalita unue. Tio estas la mekanismo malantaŭ la escepto, kaj ĝi funkcias same sur Linux, macOS kaj Windows kondiĉe ke la vojo efektive ĉeestas.

Windows aldonas duan dimension. Kiam du vojoj estas same specifaj, venkas tiu kun la pli malalta metriko, kaj VPN-adaptilo povas porti interfacan metrikon, kiu ŝanĝas la rezulton. /32 ankoraŭ estas pli specifa ol la duonoj, do la escepto kutime teniĝas, sed malnova vojo el antaŭa seanco povas produkti konfuzan rezulton se ĝi estas same specifa.

Kion la escepto ne kovras

DNS estas la unua breĉo. La kliento povas puŝi internajn solvajn agordojn, kaj la operaciumo daŭre uzos ilin por serĉoj. Aplikaĵo, kiu solvas nomon antaŭ konekti, povas ricevi internan adreson por servo, kiu devus iri rekte, aŭ eksteran adreson, kiu solviĝas ĝuste sed poste stumblas je la sekva breĉo.

IPv6 estas la dua. La direktivo pri vojoj traktas nur IPv4. Dual-staka celo povas preferi IPv6, kiu sekvas la tunelon aŭ la implican IPv6-vojon de la gastigilo laŭ politiko, do la escepto por IPv4 neniam validiĝas. Vi bezonas kongruan IPv6-vojon, aŭ konscian decidon malŝalti IPv6 por tiu kliento.

La aplikaĵa amplekso estas la tria. La regulo baziĝas sur la celo, do ĉiu procezo, kiu konektiĝas al tiu adreso, uzas la rektan vojon, ĉu ĝi estas la intencita ĉu ne. Inverse, retejo povas respondi el pluraj adresoj, do escepti unu /32 ne esceptas la retejon. Se la reala postulo estas enkursigado laŭ aplikaĵo, la vojaro de la Community-kliento estas la malĝusta ilo.

Kontroli la escepton sen trompi vin mem

Komencu per la instalita vojo, ne per retumilo. Sur Linux, demandu la kernon, kiun vojon kaj sekvan salteton ĝi uzos por la specifa adreso; sur Windows, legu la vojaron por tiu /32. Konfirmu, ke la kluzo estas la fizika kaj ne la tunelo. Se la ero mankas, la profilo ne estis aplikita aŭ la kliento ne havis la rajton ŝanĝi vojojn.

Poste testu du celojn. Peto al la esceptita adreso devus eliri tra la fizika interfaco, kaj peto al kontrola interna adreso devus daŭre uzi la tunelon. Testi nur la esceptitan adreson pruvas nenion pri la resto de la tunelo, kaj testi publikan retejon testas tiun adreson, al kiu tiu retejo solviĝis, kiu eble ne estas tiu en la regulo.

Fine, kontrolu la regilojn, kiuj povas superregi la vojon. Klientflanka mortigŝaltilo aŭ Windows-agordo block-outside-dns povas malpermesi rektan trafikon, kio montriĝas kiel konekto, kiu malsukcesas kvankam la vojo estas ĝusta. Ne malŝaltu tiujn regilojn por ŝajnigi, ke la escepto funkcias; se la politiko malpermesas la rektan vojon, la escepto estas projektproblemo por tiu, kiu posedas la VPN-servon.

Rekontrolu post rekonekto aŭ retŝanĝo, ĉar la kluzo antaŭ la VPN kaj la havebla vojo estas ecoj de la momento, ne de la profilo.