Så väljer OpenVPN data-ciphers datakanalens chiffer

Tunneln kommer upp, loggen visar ett chiffer och profilgenomgången fortsätter. Sedan landar en uppgradering hos en motpart och samma profil misslyckas med ett meddelande om inget delat chiffer, vilket skickar folk att leta efter ett direktiv att radera. Det användbara att förstå är att data-ciphers beskriver en förhandling, inte en inställning. Ena sidan erbjuder en lista, den andra väljer ur den, och resultatet är en enda algoritm som båda stöder. Att läsa det utbytet förklarar de flesta av dessa fel innan du ändrar en rad.

Två kanaler, två konfigurationer

En OpenVPN-session har en kontrollkanal och en datakanal. Kontrollkanalen kör TLS-handskakningen som autentiserar motparterna och förhandlar nycklar. Datakanalen krypterar paketen som bär din trafik.

data-ciphers konfigurerar den andra. Kontrollkanalen har egna alternativ, och profilens identitetskontroller är en tredje, separat sak. En ändring i den ena lagar inte den andra, och därför kan en profil se korrekt ut och ändå misslyckas i ett visst skede.

Håll de tre i var sin låda när du läser en konfigurationsfil.

Läs förhandlingen ur loggen

Klientloggen namnger båda resultaten när anslutningen lyckas. En rad rapporterar kontrollkanalen och dess TLS-detaljer, och en annan rapporterar det valda chiffret för datakanalen.

Läs båda, eftersom de svarar på olika frågor. Ett fel i kontrollkanalen stoppar anslutningen innan något datachiffer spelar roll. En avvikelse i datakanalen visas efter en lyckad handskakning, med ett meddelande om inget delat chiffer.

Jämför sedan de erbjudna listorna på båda sidor. Ett namn som den ena motpartens version eller dess kryptobakgrund inte tillhandahåller kan inte väljas, oavsett hur tidigt det står på den andra motpartens lista.

Hur valet faktiskt går till

Servern skjuter sin data-ciphers-lista till klienten under handskakningen, och klienten väljer den första posten på listan som den också stöder. Ordningen tillhör därför serverns konfiguration, inte klientens.

Den detaljen förklarar en klass förvirrande resultat. Att ordna om klientens lista ändrar ingenting så länge serverns lista bestämmer. Att lägga till ett chiffer som klienten inte kan tillhandahålla ändrar ingenting heller, eftersom klienten måste kunna använda posten den väljer.

Nyare utgåvor ändrade standardlistan och döpte om alternativet som brukade hålla den, så två motparter på olika versioner kan vara oense utan att någon redigerar en profil. Kontrollera versionen på varje sida innan du antar ett skrivfel.

En lista är inte en styrkerangordning i abstrakt mening. Det är en uppsättning kandidater, och den valda är den första ömsesidigt stödda posten i serverns ordning. Därför kan två listor som ser olika ut förhandla samma chiffer. Det är också därför två listor som ser identiska ut kan misslyckas.

Äldre motparter behöver en medveten reserv

En motpart som inte kan förhandla alls, eftersom den är äldre än mekanismen eller har den avstängd, behöver en dokumenterad kompatibilitetsordning. Reservalternativet finns just för det fallet och gäller motparter som inte deltar i förhandlingen.

Det är inte samma sak som att aktivera varje gammalt chiffer för att få ett meddelande att försvinna. En bred lista försvagar sessionen för varje motpart, även de som skulle ha förhandlat fram något starkt.

Samordna de två sidorna i stället för att redigera orelaterade algoritmnamn. Om en serveruppgradering tog bort ett gammalt alternativ hör rättelsen hemma i versionsplanen, inte i en hetsig jakt på klienten.

Behåll verifieringen intakt

En avvikelse i datakanalen är inte skäl att acceptera en overifierad server. Certifikatverifiering, det förväntade servernamnet och kontrollkanalens skyddsinställningar är åtskilda från chifferurvalet och bör överleva varje kompatibilitetsändring.

Notera det förhandlade datachiffret, klientversionen och serverversionen tillsammans, så att nästa jämförelse börjar från fakta och inte från profilfilen.

Efter en stödd rättelse, testa den inledande anslutningen och en omförhandling, eftersom en session som upprättas en gång fortfarande kan misslyckas när nycklarna förnyas.

Om tunneln upprättas och webbplatser fortfarande misslyckas är chiffret inte längre den misstänkta. Fortsätt med routing och DNS. Arbetsordning: läs båda loggraderna, jämför båda listorna, kontrollera versioner, lägg till en reserv bara för en motpart som behöver den, och testa sedan förnyelsevägen igen.