OpenVPN falas post DHCP-renovigo: konservu la itineron de la finpunkto

La tunelo konektiĝas, poste lu-renovigo sur la alira ligilo mortigas ĝin, kaj la protokolo kulpigas tempolimon anstataŭ itineron. Nenio en la VPN-agordo ŝanĝiĝis, kaj tio estas la postsigno: io ekster ĝi ŝanĝiĝis. DHCP-okazaĵo reskribis la adreson aŭ la kluzon, kaj la gastigila itinero, kiu tenis la finpunkton de la tunelo atingebla, nun montras al sekva salto, kiu ne plu ekzistas. Tio estas posedproblemo antaŭ ol ĝi estas itinerproblemo.

Komparu la simptomon kun la duondefaŭltaj itineroj

Kun redirect-gateway def1, OpenVPN instalas 0.0.0.0/1 kaj 128.0.0.0/1 anstataŭ anstataŭigi la defaŭltan itineron. Kune la du kovras la tutan adresspacon, kaj ili venkas 0.0.0.0/0 nur per la longeco de la prefikso. Tial ĉiu celo sen pli specifa kongruo eniras la tunelon.

La finpunkto bezonas escepton. OpenVPN aldonas gastigilan itineron al la servila adreso tra la origina alira kluzo antaŭ ol la duondefaŭltoj eniras, por ke enkapsulitaj pakaĵoj povu eliri. Kiam tiu escepto malaperas, aŭ retenas sekvan salton, kiu ne plu ekzistas, la propraj eksteraj pakaĵoj de la tunelo kongruas kun duondefaŭlto kaj estas resenditaj en la tunelon. La rezulto estas konekto, kiu mortas ĉe la sekva keepalive aŭ manpremo, sen io en la protokolo, kio aspektas kiel itinera eraro.

Konfirmu la formon de la tabelo antaŭ ol tuŝi ion alian. ip route show devus listigi ambaŭ duonojn plus gastigilan itineron por la servila adreso; kiam la gastigila itinero mankas, la resto de la esploro havas evidentan komencpunkton.

Kial la duondefaŭltoj venkas sen metrika ŝanĝo

Malpli alta metriko ne venkas pli longan prefikson. La itineroj /1 venkas ĉar la kerno unue kongruigas la plej specifan itineron, do plialtigi metrikon sur la defaŭlta itinero tute ne ŝanĝas, kien iras trafiko direktita al la tunelo. Ĉasi metrikojn estas la plej ofta malĝusta turno en ĉi tiu diagnozo.

Kontrolu la elekton per ip route get 203.0.113.10, anstataŭigante la realan servilan adreson. La respondo nomas la interfacon kaj la sekvan salton, kiujn la kerno efektive uzus, kio estas pli informe ol legi tabelon kaj rezonadi pri ĝi.

Rulu tiun komandon antaŭ ol la tunelo ekfunkcias, dum ĝi funkcias, kaj post la lu-okazaĵo. Tri respondoj el unu komando, kaj la diverĝa punkto fariĝas videbla.

Prenu tri momentaĵojn, ne unu

Kolektu la aliran adreson, la aliran kluzon, la celon de la finpunkto, la elektitan itineron kaj ajnajn politikajn regulojn en tri momentoj: post kiam la alira ligilo estas agordita, post kiam la VPN konektiĝis, kaj post la lu- aŭ operatora okazaĵo. Ĉiu momentaĵo estas plenmano da komandoj, kaj ili havas sencon nur kune. Unuopa momentaĵo post la fiasko registras la staton, ne la transiron. Skribu la komandojn en malgrandan skripton, por ke ĉiu momentaĵo estu prenita same.

Tenu la momentaĵojn en unu dosiero kun tempomarkoj, ĉar la interesa demando poste estas la ordo. Ĉu la DHCP-okazaĵo alvenis antaŭ aŭ post kiam OpenVPN ĝisdatigis sian itineron? La respondo decidas, kiu devas ripari ĝin. Tempomarko el malĝusta horloĝo estas pli malbona ol nenia, do prenu ĝin el la gastiganto, kiu posedas la itineran tabelon.

Kiam la finpunkto estas agordita kiel nomo anstataŭ adreso, solvu ĝin ankaŭ en ĉiu momentaĵo. DNS-ŝanĝo sur la alira ligilo povas movi la finpunkton tute sen tuŝi ajnan itineron.

Decidu, kiu komponanto ĝisdatigas la escepton

En dhcpcd-sistemo, hokoj ruliĝas el la hoka dosierujo kaj el la elira hoko, kaj la administra reĝimo diferencas laŭ amplekso de la reĝimo por unuopa interfaco. Kion ajn la hoko faras, ĝi devas esti idempotenta, ĉar renovigoj povas alveni en rafaloj.

La fidinda posedanto estas la integriĝo, kiu jam konas ambaŭ flankojn: retadministrilo, kiu administras la VPN-konekton, aŭ unuo ordigita post kiam la alira ligilo ekfunkcias. Statika itinero aldonita de hoko funkcias ĝis la sekva kluzoŝanĝo, kaj tiam fiaskas tute same. Se vi ja uzas hokon, igru ĝin legi la nunan kluzon dum rultempo anstataŭ malmole kodigi tiun, kiun vi vidis hodiaŭ.

Registru la posedanton ene de la agordo. La sekva persono, kiu sencimigos rekonekton, devas scii, ke hoko, ne la VPN, respondecas pri la escepta itinero.

Testu la vivciklon, ne nur la rekonekton

Devigu renovigon per dhcpcd -n eth0 aŭ liberigante kaj renove akirante la luon, poste kontrolu denove ip route get por la finpunkto. Faru ĝin dufoje, ĉar la dua pasigo kaptas hokojn, kiuj aldonas duoblajn itinerojn. Poste restartigu, ĉar persisto estas alia eco ol ĝusteco.

Tunelo, kiu postvivas renovigon kaj restartigon, havas posedanton kaj funkciantan escepton. Unu, kiu postvivas nur manan restartigon, havas nek unu nek la alian, kaj fiaskos ĉe la sekva okazaĵo, kiun vi ne povas plani.