Varför din VPN faller varje gång nycklarna roterar

Anslutningen fungerar i en timme och dör sedan, och klienten rapporterar inget mer användbart än disconnected. Just den perioden är ledtråden, eftersom något i förnyelseutbytet skiljer sig från den första handskakningen. Timern avgör bara när du möter den. Spara meddelandena från det utbytet i stället för den slutliga etiketten.

Läs fasen, inte etiketten

I IKEv2 förnyas IKE-associationen och CHILD-associationen enligt separata scheman. Ett förslag som var godtagbart för den första förhandlingen är inte automatiskt godtagbart för den andra. Den ena kan slutföras medan den andra avvisas, vilket ger en tunnel som halvt existerar. Fånga utbytet med verktyget som äger det, inte med en klientloggrad:

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

För OpenVPN är motsvarande händelse en omförhandling som styrs av versionen och utrullningsinställningarna. Dess autentiseringsbeteende har egna fellägen. Meddelandet som spelar roll namnger den misslyckade fasen, och du bör anteckna det ordagrant i stället för att omformulera det i ett ärende.

Skriv också ner tidsstämplarna. Ett avbrott med fast intervall efter den senaste lyckade förhandlingen är ett helt annat fynd än ett som kommer slumpmässigt under användning, och intervallet är ofta det enda beviset som överlever.

Jämför förslaget som misslyckas

Ett avvisat förslag ger ett tydligt meddelande hos svararen. Den vanliga orsaken är en skillnad mellan de två ändarna i algoritm, nyckellängd, grupp eller livslängd. Den första CHILD-förhandlingen kan ha lyckats eftersom den andra sidan startade den, vilket betyder att den andra sidans förslagslista användes. Titta på båda ändarna innan du ändrar något.

Avvikelser i livslängd förtjänar särskild uppmärksamhet, eftersom ett värde som såg generöst ut i ena änden kan få den andra änden att starta en förnyelse som den inte kan slutföra. Dokumentationen om nyckelförnyelsebeteende beskriver hur associationsförnyelse utlöses och hur de två ändarna kan skilja sig i sina tidsförväntningar. Jämför vad varje ände uppger sig stödja i stället för vad konfigurationsfilen antyder.

En gammal profil eller en leverantörsmall kan låsa ett förslag som den aktuella versionen inte längre erbjuder. Avvikelsen visar sig först när en ny förhandling tvingas fram.

Skilj ett problem med inloggningsuppgifter från en oåtkomlig motpart

En förnyelse som misslyckas i autentiseringen ser likadan ut i klienten och helt annorlunda på servern. Om en inloggningsuppgift kontrolleras igen vid omförhandlingen, kommer ett utgånget certifikat, ett återkallat konto eller ett ändrat lösenord att ge ett avbrott exakt i förnyelseintervallet, medan varje tidigare anslutning lyckades. En oåtkomlig motpart är den tredje möjligheten, och den ger ingen avvisning alls: paketen går ut och ingenting svarar. Det fallet följer oftast en nätverksändring i stället för en timer, så kontrollera om felet kommer efter en roaming, en inaktiv period eller en ruttändring.

Skilj de tre åt genom vad den bortre änden loggade. En avvisning med skäl, ett autentiseringsfel och tystnad är tre olika åtgärder. En omstart av klienten slår ihop dem till en enda oanvändbar observation.

Kontrollera certifikatets datum och kontots status innan du skyller på nätverket. Båda är billiga att inspektera och båda är osynliga i klientens eget meddelande.

Tvinga fram en förnyelse och läs resultatet

Tvinga fram en förnyelse med operatörens stödda metod i stället för att vänta en timme på nästa. Håll den krävda felpolicyn intakt medan du gör det. Att stänga av verifieringen eller sträcka ut livslängderna till ett dygn får symptomet att försvinna ur dina loggar utan att något rättas till. Det lämnar också ett längre avbrott som väntar på nästa person.

När rättelsen är på plats, kontrollera den förnyade tunneln och gör sedan en ny begäran från applikationen. En applikationssession som levde när associationen ändrades kan behöva sin egen återhämtning även om tunneln är frisk igen. Användare kommer att rapportera det som att VPN:et fortfarande är trasigt.

Anteckna versionsnumren, de förhandlade timrarna och den fas som misslyckades. Nästa förekomst kan då jämföras med denna i stället för att beskrivas på nytt ur minnet.