OpenVPN falder efter en DHCP-fornyelse: behold ruten til endepunktet

Tunnelen opretter forbindelse, så dræber en lejefornyelse på adgangsforbindelsen den, og loggen giver en timeout skylden i stedet for en rute. Intet i VPN-konfigurationen er ændret, og det er selve sporet: noget uden for den er. En DHCP-hændelse har overskrevet adressen eller gatewayen, og den værtsrute, der holdt tunnelens endepunkt tilgængeligt, peger nu på et næste hop, som ikke findes længere. Det er et ejerskabsproblem, før det er et routingproblem.

Sammenhold symptomet med halvstandardruterne

Med redirect-gateway def1 installerer OpenVPN 0.0.0.0/1 og 128.0.0.0/1 i stedet for at erstatte standardruten. Sammen dækker de to hele adresserummet, og de slår 0.0.0.0/0 alene på præfiksets længde. Derfor går enhver destination uden et mere specifikt match ind i tunnelen.

Endepunktet har brug for en undtagelse. OpenVPN tilføjer en værtsrute til serveradressen gennem den oprindelige adgangsgateway, før halvstandardruterne lægges ind, så indkapslede pakker kan komme ud. Når undtagelsen forsvinder eller beholder et næste hop, som ikke findes længere, matcher tunnelens egne ydre pakker en halvstandardrute og sendes tilbage i tunnelen. Resultatet er en forbindelse, der dør ved næste keepalive eller håndtryk, uden noget i loggen, der ligner en routingfejl.

Bekræft tabellens form, før du rører noget andet. ip route show bør vise begge halvdele plus en værtsrute til serveradressen; når værtsruten mangler, har resten af undersøgelsen et oplagt startpunkt.

Hvorfor halvstandardruterne vinder uden en metrikændring

En lavere metrik slår ikke et længere præfiks. Ruterne /1 vinder, fordi kernen matcher den mest specifikke rute først, så en højere metrik på standardruten ændrer intet ved, hvor trafik mod tunnelen går hen. At jage metrikker er den mest almindelige forkerte drejning i denne diagnose.

Kontrollér valget med ip route get 203.0.113.10, og indsæt den rigtige serveradresse. Svaret navngiver det interface og næste hop, som kernen faktisk ville bruge, hvilket er mere informativt end at læse en tabel og ræsonnere over den.

Kør den kommando, før tunnelen starter, mens den kører, og efter lejehændelsen. Tre svar fra én kommando, og divergenspunktet bliver synligt.

Tag tre snapshots, ikke ét

Indsaml adgangsadressen, adgangsgatewayen, endepunktets destination, den valgte rute og eventuelle politikregler på tre tidspunkter: efter adgangsforbindelsen er konfigureret, efter VPN er forbundet, og efter leje- eller operatørshændelsen. Hvert snapshot er en håndfuld kommandoer, og de betyder kun noget sammen. Et enkelt snapshot efter fejlen registrerer tilstanden i stedet for overgangen. Skriv kommandoerne i et lille script, så hvert snapshot tages på samme måde.

Hold snapshots i én fil med tidsstempler, fordi det interessante spørgsmål senere er rækkefølgen. Kom DHCP-hændelsen før eller efter, at OpenVPN fornyede sin rute? Svaret afgør, hvem der skal rette det. Et tidsstempel fra et forkert ur er værre end intet, så tag det fra den vært, der ejer routingtabellen.

Når endepunktet er konfigureret som et navn i stedet for en adresse, skal du også slå det op i hvert snapshot. En DNS-ændring på adgangsforbindelsen kan flytte endepunktet, uden at nogen rute bliver rørt.

Beslut, hvilken komponent der fornyer undtagelsen

På et dhcpcd-system kører hooks fra hook-mappen og fra exit-hooket, og managertilstand adskiller sig i omfang fra tilstanden for hvert interface. Uanset hvad hooket gør, skal det være idempotent, fordi fornyelser kan komme i klumper.

Den pålidelige ejer er integrationen, der allerede kender begge sider: en netværksmanager, der styrer VPN-forbindelsen, eller en unit, der er ordnet efter adgangsforbindelsen kommer op. En statisk rute, som et hook tilføjer, virker indtil den næste gatewayændring og fejler derefter på præcis samme måde. Hvis du endelig bruger et hook, så lad det læse den aktuelle gateway under kørslen i stedet for at hardkode den, du så i dag.

Notér ejeren inde i konfigurationen. Den næste person, der fejlretter en genopkobling, skal vide, at et hook, ikke VPN, er ansvarlig for undtagelsesruten.

Test livscyklussen, ikke bare genopkoblingen

Tving en fornyelse med dhcpcd -n eth0 eller ved at frigive og forny lejen, og tjek derefter ip route get for endepunktet igen. Gør det to gange, fordi den anden kørsel fanger hooks, der tilføjer dobbelte ruter. Genstart derefter, fordi persistens er en anden egenskab end korrekthed.

En tunnel, der overlever en fornyelse og en genstart, har en ejer og en fungerende undtagelse. En, der kun overlever en manuel genstart, har ingen af delene og vil fejle ved den næste hændelse, du ikke kan planlægge.