OpenVPN faller etter en DHCP-fornyelse: behold ruten til endepunktet

Tunnelen kobler til, så dreper en leiefornyelse på aksesslenken den, og loggen gir en tidsavbrudd skylden i stedet for en rute. Ingenting i VPN-konfigurasjonen er endret, og det er selve sporet: noe utenfor den er. En DHCP-hendelse skrev om adressen eller gatewayen, og vertsruten som holdt tunnelens endepunkt tilgjengelig peker nå på et neste hopp som ikke finnes lenger. Dette er et eierskapsproblem før det er et ruteproblem.

Sammenlign symptomet med halvstandardrutene

Med redirect-gateway def1 installerer OpenVPN 0.0.0.0/1 og 128.0.0.0/1 i stedet for å erstatte standardruten. Sammen dekker de to hele adresserommet, og de slår 0.0.0.0/0 bare på prefikslengden. Derfor går enhver destinasjon uten et mer spesifikt treff inn i tunnelen.

Endepunktet trenger et unntak. OpenVPN legger til en vertsrute til serveradressen via den opprinnelige aksessgatewayen før halvstandardene legges inn, slik at innkapslede pakker kan komme ut. Når det unntaket forsvinner, eller beholder et neste hopp som ikke finnes lenger, treffer tunnelens egne ytre pakker en halvstandard og sendes tilbake inn i tunnelen. Resultatet er en forbindelse som dør ved neste keepalive eller håndtrykk, uten noe i loggen som ser ut som en rutefeil.

Bekreft tabellens form før du rører noe annet. ip route show bør liste begge halvdeler pluss en vertsrute for serveradressen; når vertsruten mangler, har resten av undersøkelsen et åpenbart startpunkt.

Hvorfor halvstandardene vinner uten en metrikkendring

En lavere metrikk slår ikke et lengre prefiks. Rutene /1 vinner fordi kjernen først matcher den mest spesifikke ruten, så å heve en metrikk på standardruten endrer ingenting for hvor trafikk mot tunnelen går. Å jage metrikker er den vanligste feilsvingen i denne diagnosen.

Kontroller valget med ip route get 203.0.113.10, og sett inn den virkelige serveradressen. Svaret navngir grensesnittet og neste hopp som kjernen faktisk ville brukt, noe som er mer informativt enn å lese en tabell og resonnere om den.

Kjør den kommandoen før tunnelen starter, mens den er oppe, og etter leiehendelsen. Tre svar fra én kommando, og divergenspunktet blir synlig.

Ta tre øyeblikksbilder, ikke ett

Samle aksessadressen, aksessgatewayen, endepunktets destinasjon, den valgte ruten og eventuelle policyregler på tre tidspunkter: etter at aksesslenken er konfigurert, etter at VPN kobler til, og etter leie- eller operatørhendelsen. Hvert øyeblikksbilde er en håndfull kommandoer, og de betyr bare noe sammen. Et enkelt øyeblikksbilde etter feilen registrerer tilstanden i stedet for overgangen. Skriv kommandoene i et lite skript slik at hvert øyeblikksbilde tas på samme måte.

Hold øyeblikksbildene i én fil med tidsstempler, fordi det interessante spørsmålet senere er rekkefølgen. Kom DHCP-hendelsen før eller etter at OpenVPN fornyet ruten sin? Svaret avgjør hvem som må rette det. Et tidsstempel fra en feil klokke er verre enn ingen, så ta det fra verten som eier rutetabellen.

Når endepunktet er konfigurert som et navn i stedet for en adresse, løs det opp i hvert øyeblikksbilde også. En DNS-endring på aksesslenken kan flytte endepunktet uten at noen rute blir rørt.

Bestem hvilken komponent som fornyer unntaket

På et dhcpcd-system kjører kroker fra krok-katalogen og fra utgangskroken, og ledermodus skiller seg i omfang fra modus per grensesnitt. Uansett hva kroken gjør, må den være idempotent, fordi fornyelser kan komme i byger.

Den pålitelige eieren er integrasjonen som allerede kjenner begge sider: en nettverksbehandler som administrerer VPN-forbindelsen, eller en unit ordnet etter at aksesslenken kommer opp. En statisk rute som en krok legger til virker til neste gatewayendring, og feiler deretter på nøyaktig samme måte. Hvis du likevel bruker en krok, la den lese gjeldende gateway under kjøring i stedet for å hardkode den du så i dag.

Noter eieren inne i konfigurasjonen. Den neste personen som feilsøker en gjenoppkobling må vite at en krok, ikke VPN, er ansvarlig for unntaksruten.

Test livssyklusen, ikke bare gjenoppkoblingen

Tving en fornyelse med dhcpcd -n eth0 eller ved å slippe og fornye leien, og sjekk deretter ip route get for endepunktet igjen. Gjør det to ganger, fordi andre kjøring fanger kroker som legger til dupliserte ruter. Start deretter på nytt, fordi persistens er en annen egenskap enn korrekthet.

En tunnel som overlever en fornyelse og en omstart har en eier og et fungerende unntak. En som bare overlever en manuell omstart har ingen av delene, og vil feile ved den neste hendelsen du ikke kan planlegge.