Går VPN:en sönder efter en klientuppdatering? Jämför förhandlingen

Uppdateringar ersätter komponenten som tolkar din profil och förhandlar om tunneln. Det första felet efter en uppgradering är bevis om en specifik ändring, inte en dom över utgåvan. Att spara felet tillsammans med version och tidsstämpel är det mest värdefulla steget du kan ta innan du installerar om något.

Två mekanismer förklarar de flesta av dessa brott. Att skilja dem åt är arbetet.

Vad förhandlingen ändrade under dig

OpenVPN förhandlar om datakanalens chiffer i stället för att ta det från ett enda direktiv, och de alternativ som styr den förhandlingen har bytt betydelse mellan utgåvorna. En profil skriven för en äldre klient kan ansluta och sedan inte komma överens om en datakanal, vilket visar sig som en frånkoppling i stället för ett tydligt konfigurationsfel. Nyare utgåvor skärper eller tar också bort ärvt beteende och levererar ett kompatibilitetsläge för parter som ännu inte flyttat. En uppgradering kan därför bryta en fungerande profil utan att röra en enda byte i filen.

Effekten på klienten är asymmetrisk. Kontrollkanalen kommer upp, autentiseringen lyckas och tunneln dör efteråt, vilket är signaturen för en oenighet i förhandlingen och inte för en avvisad profil.

Läs den installerade versionen innan du teoretiserar om servern. Den strängen är ett lokalt faktum som du kan kontrollera utan att be någon om åtkomst.

Profilen kan tolkas och betyda något annat

Ett direktiv som överlever tolkningen är inte nödvändigtvis ett direktiv som fortfarande gör det författaren avsåg. Alternativ kan accepteras av kompatibilitetsskäl och ignoreras, byta namn eller tillämpas i ett snävare fall än tidigare. Eftersom ingenting ger ett fel ser profilen korrekt ut medan beteendet under den har ändrats. Just den tystnaden gör dessa regressioner dyra.

Fråga vilka rader som verkligen ansvarar för det förhandlade resultatet och jämför dem sedan med dokumentationen för den version du kör nu. Den jämförelsen är kort, och den är skillnaden mellan en rättelse och en återställning.

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

Plattformen rörde sig samtidigt

Klientutgåvor kommer sällan ensamma. En uppdatering av operativsystemet, en behörighetsfråga som nu kräver ett uttryckligt medgivande eller en hanterad policy som tillämpas på enheten kan landa samma vecka och ge ett fel som klienten får skulden för. Mobila plattformar lägger till sitt eget lager, eftersom appen ber systemet om en tunnel och systemet avgör vad den tunneln får dirigera.

Anteckna dessa ändringar separat i tidslinjen. När autentiseringen lyckas men rutter eller namnmatchning misslyckas är det intressanta steget efter handskakningen, och en försvagad certifikatvalidering kommer inte att röra det.

Testa händelsen som startade rapporten igen

Återge den ursprungliga sekvensen i stället för en förenklad version: den första anslutningen, programmet som misslyckades och en vanlig återanslutning efter ett nätverksbyte. En tunnel som kommer upp under testförhållanden och ändå faller på återanslutningsvägen är inte åtgärdad, och skillnaden markerar oftast var det verkliga felet sitter. En rapport som utelämnar återanslutningssteget stänger en bugg som fortfarande är öppen.

Skaffa operatörens stödda profil eller leverantörens rättelse via den verifierade kanalen i stället för att rulla tillbaka allt. En bred nedgradering återställer också de säkerhetsrättelser som uppdateringen förde med sig, och den byteshandeln är sällan en fungerande anslutning värd.