OpenVPN fell etter ei DHCP-fornying: hald på ruta til endepunktet

Tunnelen koplar til, så drep ei leigefornying på aksesslenkja han, og loggen gir ein tidsavbrot skulda i staden for ei rute. Ingenting i VPN-konfigurasjonen er endra, og det er sjølve sporet: noko utanfor han er. Ein DHCP-hending skreiv om adressa eller gatewayen, og vertsruta som heldt endepunktet til tunnelen tilgjengeleg peikar no på eit neste hopp som ikkje finst lenger. Dette er eit eigarskapsproblem før det er eit ruteproblem.

Samanlikn symptomet med halvstandardrutene

Med redirect-gateway def1 installerer OpenVPN 0.0.0.0/1 og 128.0.0.0/1 i staden for å erstatta standardruta. Saman dekkjer dei to heile adresserommet, og dei slår 0.0.0.0/0 berre på prefikslengda. Difor går kvar destinasjon utan eit meir spesifikt treff inn i tunnelen.

Endepunktet treng eit unntak. OpenVPN legg til ei vertsrute til serveradressa via den opphavlege aksessgatewayen før halvstandardane vert lagde inn, slik at innkapsla pakkar kan koma ut. Når det unntaket forsvinn, eller held på eit neste hopp som ikkje finst lenger, treffer dei eigne ytre pakkane til tunnelen ein halvstandard og vert sende attende inn i tunnelen. Resultatet er ei tilkopling som døyr ved neste keepalive eller handtrykk, utan noko i loggen som ser ut som ein rutefeil.

Stadfest forma på tabellen før du rører noko anna. ip route show bør lista båe halvdelane pluss ei vertsrute for serveradressa; når vertsruta manglar, har resten av granskinga eit openbert startpunkt.

Kvifor halvstandardane vinn utan ei metrikkendring

Ein lågare metrikk slår ikkje eit lengre prefiks. Rutene /1 vinn fordi kjernen først matchar den mest spesifikke ruta, så å heva ein metrikk på standardruta endrar ingenting for kvar trafikk mot tunnelen går. Å jaga metrikkar er den vanlegaste feilsvingen i denne diagnosen.

Kontroller valet med ip route get 203.0.113.10, og set inn den verkelege serveradressa. Svaret namngir grensesnittet og neste hopp som kjernen faktisk ville bruka, noko som er meir informativt enn å lesa ein tabell og resonnera om han.

Køyr den kommandoen før tunnelen startar, medan han er oppe, og etter leigehendinga. Tre svar frå éin kommando, og divergenspunktet vert synleg.

Ta tre augneblinksbilete, ikkje eitt

Samla aksessadressa, aksessgatewayen, destinasjonen til endepunktet, den valde ruta og eventuelle policyreglar på tre tidspunkt: etter at aksesslenkja er konfigurert, etter at VPN koplar til, og etter leige- eller operatørhendinga. Kvart augneblinksbilete er ein handfull kommandoar, og dei tyder berre noko saman. Eitt einskilt augneblinksbilete etter feilen registrerer tilstanden i staden for overgangen. Skriv kommandoane i eit lite skript slik at kvart augneblinksbilete vert teke på same måte.

Hald augneblinksbileta i éi fil med tidsstempel, fordi det interessante spørsmålet seinare er rekkjefølgja. Kom DHCP-hendinga før eller etter at OpenVPN fornya ruta si? Svaret avgjer kven som må retta det. Eit tidsstempel frå ei feil klokke er verre enn ingen, så ta det frå verten som eig rutetabellen.

Når endepunktet er konfigurert som eit namn i staden for ei adresse, løys det opp i kvart augneblinksbilete òg. Ei DNS-endring på aksesslenkja kan flytta endepunktet utan at noka rute vert rørt.

Avgjer kva komponent som fornyar unntaket

På eit dhcpcd-system køyrer krokar frå krok-katalogen og frå utgangskroken, og leiar-modus skil seg i omfang frå modus per grensesnitt. Uansett kva kroken gjer, må han vera idempotent, fordi fornyingar kan koma i byer.

Den pålitelege eigaren er integrasjonen som alt kjenner båe sider: ein nettverkshandsamar som administrerer VPN-tilkoplinga, eller ein unit ordna etter at aksesslenkja kjem opp. Ei statisk rute som ein krok legg til, verkar til neste gatewayendring, og feilar deretter på nøyaktig same måte. Viss du likevel brukar ein krok, la han lesa gjeldande gateway under køyring i staden for å hardkoda den du såg i dag.

Noter eigaren inne i konfigurasjonen. Den neste personen som feilsøkjer ei attoppkopling må vita at ein krok, ikkje VPN, er ansvarleg for unntaksruta.

Test livssyklusen, ikkje berre attoppkoplinga

Tving ei fornying med dhcpcd -n eth0 eller ved å sleppa og fornya leiga, og sjekk deretter ip route get for endepunktet igjen. Gjer det to gonger, fordi andre køyring fangar krokar som legg til dupliserte ruter. Start deretter på nytt, fordi persistens er ein annan eigenskap enn korrektheit.

Ein tunnel som overlever ei fornying og ein omstart har ein eigar og eit fungerande unntak. Ein som berre overlever ein manuell omstart har ingen av delane, og vil feila ved den neste hendinga du ikkje kan planleggja.