Hvorfor din VPN falder, hver gang nøglerne roteres

Forbindelsen virker i en time og dør derefter, og klienten rapporterer intet mere brugbart end disconnected. Den periode er ledetråden, fordi noget ved fornyelsesudvekslingen adskiller sig fra det indledende håndtryk. Timeren bestemmer kun, hvornår du møder den. Gem meddelelserne fra den udveksling i stedet for den endelige etiket.

Læs fasen, ikke etiketten

I IKEv2 fornyes IKE-associationen og CHILD-associationen efter separate tidsplaner. Et forslag, der var acceptabelt til den første forhandling, er ikke automatisk acceptabelt til den anden. Den ene kan gennemføres, mens den anden afvises, hvilket giver en tunnel, der halvt eksisterer. Optag udvekslingen med det værktøj, der ejer den, i stedet for en klientloglinje:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

For OpenVPN er den tilsvarende hændelse en genforhandling styret af versionen og udrulningsindstillingerne. Dets adfærd ved godkendelse har sine egne fejltilstande. Den meddelelse, der betyder noget, navngiver den fejlede fase, og du bør registrere den ordret i stedet for at omformulere den i en sag.

Skriv også tidsstemplerne ned. Et udfald med fast interval efter den sidste vellykkede forhandling er et helt andet fund end et, der kommer tilfældigt under brug, og intervallet er ofte det eneste bevis, der overlever.

Sammenlign det forslag, der fejler

Et afvist forslag giver en klar meddelelse på svareren. Den sædvanlige årsag er en forskel mellem de to ender i algoritme, nøglelængde, gruppe eller levetid. Den indledende CHILD-forhandling kan være lykkedes, fordi den anden side startede den, hvilket betyder, at den brugte den anden sides forslagsliste. Se på begge ender, før du ændrer noget.

Uoverensstemmelser i levetid fortjener særlig opmærksomhed, fordi en værdi, der så generøs ud i den ene ende, kan få den anden ende til at starte en fornyelse, den ikke kan gennemføre. Dokumentationen om nøglefornyelsesadfærd beskriver, hvordan associationsfornyelse udløses, og hvordan de to ender kan afvige i deres tidsforventninger. Sammenlign, hvad hver ende hævder at understøtte, i stedet for hvad konfigurationsfilen antyder.

En gammel profil eller en udbyder-skabelon kan fastlåse et forslag, som den nuværende version ikke længere tilbyder. Uoverensstemmelsen viser sig kun, når en ny forhandling tvinges igennem.

Adskil et legitimationsproblem fra en utilgængelig peer

En fornyelse, der fejler godkendelse, ser ens ud i klienten og helt anderledes på serveren. Hvis en legitimationsoplysning tjekkes igen ved genforhandlingen, vil et udløbet certifikat, en tilbagekaldt konto eller en ændret adgangskode give et udfald præcis i fornyelsesintervallet, mens hver tidligere forbindelse lykkedes. En utilgængelig peer er den tredje mulighed, og den giver slet ingen afvisning: pakkerne forlader og intet svarer. Det tilfælde følger normalt en netværksændring i stedet for en timer, så tjek, om fejlen følger roaming, en inaktiv periode eller en ruteændring.

Skeln de tre ved, hvad den fjerne ende loggede. En afvisning med en grund, en godkendelsesfejl og tavshed er tre forskellige rettelser. Genstart af klienten kollapser dem til én ubrugelig observation.

Tjek certifikatets datoer og kontoens tilstand, før du beskylder netværket. Begge er billige at undersøge, og begge er usynlige i klientens egen meddelelse.

Tving én fornyelse igennem og læs resultatet

Tving én fornyelse igennem med operatørens understøttede metode i stedet for at vente en time på den næste. Hold den krævede fejlpolicy intakt, mens du gør det. At slå verifikation fra eller strække levetider til en dag får symptomet til at forsvinde fra dine logs, uden at noget rettes. Det efterlader også et længere udfald, der venter på den næste person.

Når rettelsen er på plads, tjek den fornyede tunnel og lav derefter en ny anmodning fra applikationen. En applikationssession, der var i live, da associationen ændrede sig, kan have brug for sin egen genopretning, selvom tunnelen er sund igen. Brugere vil rapportere det som, at VPN'en stadig er i stykker.

Registrér versionsnumrene, de forhandlede timere og den fase, der fejlede. Den næste forekomst kan så sammenlignes med denne i stedet for at blive beskrevet igen fra hukommelsen.