Via malnova defaŭlta vojo intence postvivas OpenVPN

Vi konektas la tunelon, rulas ip route, kaj la origina defaŭlta enirejo ankoraŭ staras tie. La sekva penso estas, ke la kliento ne transprenis la vojon, do vi forigas la defaŭltan permane kaj tute perdas la konektecon. Tiu rikordo devas resti. Kun redirect-gateway def1, OpenVPN instalas du pli specifajn vojojn, kiuj superas la ordinaran defaŭltan anstataŭ anstataŭigi ĝin. La malnova enirejo restas kaj ĉesas porti la trafikon, kiun vi testis.

Kion def1 efektive faras

La flago aldonas 0.0.0.0/1 kaj 128.0.0.0/1, ambaŭ kondukantaj al la tunelo. 0.0.0.0/1 prenas ĉiun adreson, kies unua okteto estas 0 ĝis 127, kaj 128.0.0.0/1 prenas 128 ĝis 255, do ĉiu IPv4-celo havas pli specifan kongruon ol la malnova defaŭlta. La longo de la prefikso, ne la metriko, decidas, kiu vojo venkas.

Lasi la originan defaŭltan en loko estas intenca. La kliento ne devas memori, kion ĝi anstataŭigis, kaj ĝi ne reverkas la vojon, kiu portas ĝian propran konekton al la VPN-servilo. Ĉe malkonekto ĝi forigas la du duonvojojn kaj la tabelo revenas al tio, kio ĝi estis.

Kial /1 kaj ne /0

Enkursigado elektas la plej longan kongruan prefikson, ne la plej malaltan metrikon, do /1 venkas /0 kion ajn diras la metriko de la defaŭlta. Ambaŭ duonoj ekzistas ĉar unu /1 kovras nur duonon de la spaco; kun nur 0.0.0.0/1 ĉeestanta, ĉio de 128.0.0.0 supren daŭre sekvas la malnovan defaŭltan, kio produktas la konfuzan simptomon, ke iuj retejoj funkcias kaj aliaj ne.

Altigi aŭ malaltigi la metrikon de la malnova defaŭlta ŝanĝas nenion, kaj defaŭlta kun pli malalta metriko sur alia interfaco ankaŭ ne ŝtelas la trafikon. Unue decidas la longo de la prefikso, kaj nur egalaj prefiksoj fidas la metrikon.

Legu realan enkursigadan tabelon

Konektita gastiganto povas montri ĉiujn tri rikordojn samtempe, kun la tunelo portanta la duonojn kaj la origina enirejo ankoraŭ listigita. La adresoj estas ekzemploj, ne agordo por kopii, ĉar interfacaj nomoj, tunela topologio kaj pliaj vojoj varias laŭ platformo kaj kliento.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Grava estas la rilato: du apartaj duonoj super unu ĝenerala defaŭlta. La linio de la malnova enirejo restas ĉar nenio anstataŭigis ĝin.

Kontrolu, kiun vojon la paketo efektive prenas

Pli specifaj vojoj ankoraŭ povas venki: vojo por privata gamo, loka subreto aŭ la propra adreso de la VPN-servilo estas pli longa ol /1. La tunelo bezonas eksteran vojon al sia servilo, kaj sendi tiun konekton reen en la tunelon tuj rompus ĝin. En Linux demandu la kernon anstataŭ legi la tabelon per okulo: ip route get kun la celo, kiu interesas vin, presas la elektitan vojon, interfacon kaj fonton. Se politika enkursigado estas agordita, kontrolu ankaŭ la regulojn, ĉar regulo povas elekti alian tabelon antaŭ ol oni konsultas la ĉefan.

Se nur parto de IPv4 miskondutas, konfirmu, ke ambaŭ duonoj estas instalitaj, kaj poste serĉu escepton kongruan kun la malsukcesa celo. Forigi la malnovan defaŭltan ne estas solvo, kaj ĝi forprenas la vojon, kiun la kliento bezonas por purigi la tunelon.

Kion def1 ne kovras

Du IPv4-rikordoj diras nenion pri IPv6: gastiganto kun IPv6-konekto daŭre uzas sian propran defaŭltan ĝis io alidirektas tiun familion aparte, kaj tial sur dual-stack-reto parto de la trafiko ŝajne preterpasas la tunelon. Aliaj klientoj kaj retadministriloj implementas plentunelan enkursigadon alimaniere, kaj iliaj tabeloj ne kongruos. La ĉi tie priskribita konduto de def1 apartenas al la dokumentita flago de OpenVPN, ne al ĉiu VPN sur la maŝino.

Kill switch respondas al alia demando: kion la maŝino faras, kiam la tunelo falas. Vojprioritato decidas, kien la trafiko iras dum la tunelo estas aktiva; ĝi ne decidas, kion fajroŝirmilo faras poste. Ordo de la laboro: legu la tabelon, konfirmu, ke ambaŭ duonoj ekzistas, rulu ip route get por la malsukcesa celo, kontrolu la politikajn regulojn, kaj poste rigardu IPv6 aparte. Lasu la malnovan defaŭltan tie, kie ĝi estas.