Slik velger OpenVPN data-ciphers chifferen for datakanalen

Tunnelen kommer opp, loggen viser en chiffer, og profilgjennomgangen går videre. Så lander en oppgradering hos en motpart, og samme profil feiler med en melding om ingen delt chiffer, noe som sender folk på jakt etter et direktiv som skal slettes. Det nyttige å forstå er at data-ciphers beskriver en forhandling, ikke en innstilling. Den ene siden tilbyr en liste, den andre velger fra den, og resultatet er én algoritme som begge støtter. Å lese den utvekslingen forklarer de fleste av disse feilene før du endrer en linje.

To kanaler, to konfigurasjoner

En OpenVPN-økt har en kontrollkanal og en datakanal. Kontrollkanalen kjører TLS-håndtrykket som autentiserer motpartene og forhandler nøkler. Datakanalen krypterer pakkene som bærer trafikken din.

data-ciphers konfigurerer den andre. Kontrollkanalen har egne valg, og profilenes identitetskontroller er en tredje, atskilt sak. En endring i den ene retter ikke den andre, og derfor kan en profil se riktig ut og likevel feile på et bestemt trinn.

Hold de tre i hver sin boks når du leser en konfigurasjonsfil.

Les forhandlingen fra loggen

Klientloggen navngir begge resultatene når tilkoblingen lykkes. Én linje rapporterer kontrollkanalen og TLS-detaljene dens, og en annen rapporterer chifferen for datakanalen som ble valgt.

Les begge, fordi de svarer på forskjellige spørsmål. En feil i kontrollkanalen stopper tilkoblingen før noen datachiffer blir viktig. Et avvik i datakanalen vises etter et vellykket håndtrykk, med en melding om ingen delt chiffer.

Sammenlign deretter listene som tilbys på begge sider. Et navn som versjonen til den ene motparten eller kryptobakgrunnen dens ikke tilbyr, kan ikke velges, uansett hvor tidlig det står på listen til den andre motparten.

Hvordan valget faktisk skjer

Serveren skyver data-ciphers-listen sin til klienten under håndtrykket, og klienten velger den første oppføringen på listen som den også støtter. Rekkefølgen tilhører derfor serverens konfigurasjon, ikke klientens.

Den detaljen forklarer en klasse forvirrende resultater. Å omorganisere klientens liste endrer ingenting så lenge serverens liste bestemmer. Å legge til en chiffer klienten ikke kan tilby endrer heller ingenting, fordi klienten må kunne bruke oppføringen den velger.

Nyere utgivelser endret standardlisten og ga nytt navn til valget som pleide å holde den, så to motparter på ulike versjoner kan være uenige uten at noen redigerer en profil. Sjekk versjonen på hver side før du antar en skrivefeil.

En liste er ikke en styrkerangering i abstrakt forstand. Det er et sett kandidater, og den valgte er den første gjensidig støttede oppføringen i serverens rekkefølge. Derfor kan to lister som ser forskjellige ut forhandle samme chiffer. Det er også derfor to lister som ser identiske ut kan feile.

Eldre motparter trenger en bevisst reserveløsning

En motpart som ikke kan forhandle i det hele tatt, fordi den er eldre enn mekanismen eller har den deaktivert, trenger en dokumentert kompatibilitetsordning. Reservevalget finnes nettopp for det tilfellet og gjelder motparter som ikke deltar i forhandlingen.

Det er ikke det samme som å aktivere hver gammel chiffer for å få en melding til å forsvinne. En bred liste svekker økten for hver motpart, også dem som ville ha forhandlet noe sterkt.

Koordiner de to sidene i stedet for å redigere urelaterte algoritmenavn. Hvis en serveroppgradering fjernet et gammelt valg, hører rettelsen hjemme i versjonsplanen, ikke i en hektisk jakt på klienten.

Behold verifiseringen intakt

Et avvik i datakanalen er ikke grunn til å godta en uverifisert server. Sertifikatverifisering, det forventede servernavnet og kontrollkanalens beskyttelsesinnstillinger er atskilt fra chiffervalget og bør overleve enhver kompatibilitetsendring.

Noter den forhandlede datachifferen, klientversjonen og serverversjonen sammen, slik at neste sammenligning starter fra fakta og ikke fra profilfilen.

Etter en støttet rettelse, test den innledende tilkoblingen og en ny forhandling, fordi en økt som etableres én gang fortsatt kan feile når nøklene fornyes.

Hvis tunnelen etableres og nettsteder fortsatt feiler, er chifferen ikke lenger den mistenkte. Fortsett med ruting og DNS. Arbeidsrekkefølge: les begge logglinjene, sammenlign begge listene, sjekk versjoner, legg til en reserveløsning bare for en motpart som trenger det, og test deretter fornyelsesveien på nytt.