Sådan vælger OpenVPN data-ciphers datakanalens chiffer

Tunnelen kommer op, loggen viser et chiffer, og profilgennemgangen fortsætter. Så lander en opgradering hos en modpart, og den samme profil fejler med en meddelelse om intet fælles chiffer, hvilket sender folk på jagt efter en direktiv, der skal slettes. Det nyttige at forstå er, at data-ciphers beskriver en forhandling, ikke en indstilling. Den ene side tilbyder en liste, den anden vælger fra den, og resultatet er en enkelt algoritme, som begge understøtter. At læse den udveksling forklarer de fleste af disse fejl, før du ændrer en linje.

To kanaler, to konfigurationer

En OpenVPN-session har en kontrolkanal og en datakanal. Kontrolkanalen kører TLS-håndtrykket, som autentificerer parterne og forhandler nøgler. Datakanalen krypterer de pakker, der bærer din trafik.

data-ciphers konfigurerer den anden. Kontrolkanalen har sine egne valgmuligheder, og profilernes identitetskontrol er et tredje, særskilt anliggende. En ændring i den ene retter ikke den anden, og derfor kan en profil se korrekt ud og alligevel fejle på et bestemt trin.

Hold de tre i hver deres boks, når du læser en konfigurationsfil.

Læs forhandlingen fra loggen

Klientloggen navngiver begge resultater, når forbindelsen lykkes. En linje rapporterer kontrolkanalen og dens TLS-detaljer, og en anden rapporterer det valgte chiffer til datakanalen.

Læs begge, fordi de svarer på forskellige spørgsmål. En fejl i kontrolkanalen stopper forbindelsen, før noget datachiffer bliver relevant. En uoverensstemmelse i datakanalen vises efter et vellykket håndtryk, med en meddelelse om intet fælles chiffer.

Sammenlign derefter de tilbudte lister på begge sider. Et navn, som den ene modparts version eller kryptobaggrund ikke leverer, kan ikke vælges, uanset hvor tidligt det optræder på den anden modparts liste.

Sådan foregår valget i virkeligheden

Serveren sender sin data-ciphers-liste til klienten under håndtrykket, og klienten vælger den første post på listen, som den også understøtter. Rækkefølgen tilhører derfor serverens konfiguration, ikke klientens.

Den detalje forklarer en klasse af forvirrende resultater. At omarrangere klientens liste ændrer intet, mens serverens liste bestemmer. At tilføje et chiffer, som klienten ikke kan levere, ændrer heller intet, fordi klienten skal kunne bruge den post, den vælger.

Nyere udgivelser ændrede standardlisten og omdøbte den valgmulighed, der plejede at rumme den, så to modparter på forskellige versioner kan være uenige, uden at nogen redigerer en profil. Kontroller versionen på hver side, før du antager en tastefejl.

En liste er ikke en styrkerangering i abstrakt forstand. Det er et sæt kandidater, og den valgte er den første gensidigt understøttede post i serverens rækkefølge. Derfor kan to lister, der ser forskellige ud, forhandle det samme chiffer. Det er også derfor, at to lister, der ser identiske ud, kan fejle.

Ældre modparter har brug for en bevidst reserve

En modpart, der slet ikke kan forhandle, fordi den er ældre end mekanismen eller har den deaktiveret, har brug for en dokumenteret kompatibilitetsordning. Reservevalgmuligheden findes netop til det tilfælde og gælder for modparter, der ikke deltager i forhandlingen.

Det er ikke det samme som at aktivere hvert gammelt chiffer for at få en meddelelse til at forsvinde. En bred liste svækker sessionen for hver modpart, også dem, der ville have forhandlet noget stærkt.

Koordinér de to sider i stedet for at redigere ubeslægtede algoritmenavne. Hvis en serveropgradering fjernede en gammel valgmulighed, hører rettelsen hjemme i versionsplanen, ikke i en hektisk jagt på klienten.

Bevar verifikationen intakt

En uoverensstemmelse i datakanalen er ikke en grund til at acceptere en uverificeret server. Certifikatverifikation, det forventede servernavn og kontrolkanalens beskyttelsesindstillinger er adskilt fra chiffervalget og bør overleve enhver kompatibilitetsændring.

Notér det forhandlede datachiffer, klientversionen og serverversionen sammen, så den næste sammenligning starter fra fakta i stedet for fra profilfilen.

Efter en understøttet rettelse skal du teste den indledende forbindelse og en genforhandling, fordi en session, der etableres én gang, stadig kan fejle, når nøglerne fornyes.

Hvis tunnelen etableres, og websteder stadig fejler, er chifferet ikke længere den mistænkte. Fortsæt med routing og DNS. Arbejdsrækkefølge: læs begge loglinjer, sammenlign begge lister, kontroller versioner, tilføj kun en reserve til en modpart, der har brug for den, og test derefter fornyelsesvejen igen.