En fejl om ingen fælles chiffer lyder som én indstilling, der skal ændres, og den indstilling, de fleste ændrer, er den forkerte. OpenVPN holder adskilte politikker for kontrolkanalen, der udfører TLS-handshaket, og for datakanalen, der bærer pakker inde i tunnelen, og fejlen nævner den første, mens folk redigerer den anden. At sammenligne, hvad hver part tillader, i den rigtige rækkefølge, gør gætværket til to eller tre beslutninger: version, derefter suiteliste, derefter legitimationsoplysninger.

Tager du fejl af rækkefølgen, kan du bruge en time på at føje et AES-navn til en liste, der aldrig blev læst.

To chifferlister, og kun én ødelægger handshaket

Kontrolkanalen forhandler en TLS-session, og dens politik skrives med tls-cipher til TLS 1.2 og tls-ciphersuites til TLS 1.3. Datakanalen konfigureres separat med data-ciphers, hvor en uoverensstemmelse giver en forbindelse, der oprettes og derefter ikke kan føre trafik. Begge giver fejl, der nævner chiffere, og derfor forveksles de. Et handshake, der aldrig fuldføres, peger på kontrolkanalen, mens en etableret tunnel, der taber pakker, peger på datakanalen.

Læs hele meddelelsen i stedet for den første linje. En versionsuoverensstemmelse, en manglende suite, en certifikatsignaturalgoritme, som parten afviser, og en mislykket værtsnavnskontrol ender alle i en TLS-fejl, og kun én af dem handler om din suiteliste. At holde de kategorier adskilt er det meste af diagnosen.

Sammenlign versioner, før du sammenligner suites

En part begrænset til TLS 1.2 og en part, der kræver 1.3, deler ingen version, og ingen chifferstreng bygger bro over det. Notér tls-version-min og tls-version-max på begge sider, eller standardværdierne for de builds, der bruges, fordi en distributions OpenSSL-politik kan hæve gulvet, uden at nogen OpenVPN-indstilling siger det. Hvis den ene side er et apparat eller en tredjepartsklient, er dens vindue det, dens firmware tillader. Først når vinduerne overlapper, betyder en suitesammenligning noget.

De noter bør også navngive de faktiske binære filer. En kommandolinje-openvpn på din bærbare computer er ikke nødvendigvis den klient, der håndterer en importeret profil.

Lister til TLS 1.2 og TLS 1.3 blandes ikke

Suittenavne til TLS 1.2 ser sådan ud: ECDHE-RSA-AES256-GCM-SHA384 og hører til i tls-cipher, som tager en OpenSSL-chifferstreng. TLS 1.3-suites hedder TLS_AES_256_GCM_SHA384 og hører til i tls-ciphersuites; at føje en til 1.2-strengen konfigurerer ikke 1.3-listen, og parseren kan acceptere teksten uden nogensinde at matche den. Et filter, der er rigtigt for én version, siger intet om den anden. Skriv ned, hvilken version hver liste er beregnet til.

openvpn --show-tls udskriver, hvad det lokale build understøtter, og det er en fortegnelse, ikke et løfte: den fjerneste part tillader måske ikke de suites, og den aktive profil aktiverer dem måske ikke. Brug det til at udelukke et build, der slet ikke kan tilbyde en suite, og sammenlign derefter de konfigurerede lister.

Bevis forhandlingen på en ny forbindelse

Et vellykket handshake er det eneste bevis, der tæller, og det skal komme fra den rigtige klient med den rigtige profil. Skru op for serverens detaljeringsgrad, forbind én gang, og læs den forhandlede protokolversion og suite fra loggen i stedet for at antage, at den første tilbudte værdi vandt. Bekræft derefter datakanalen separat med trafik gennem tunnelen, fordi et fungerende handshake og en svigtende datakanal er forskellige reparationer. Gentag efter enhver konfigurationsændring, fordi en forældet klientprofil er en almindelig falsk negativ.

Findes der ingen godkendt fælles konfiguration, er svaret en opgradering eller en migreringsplan, ikke en svækket politik. At sænke tls-version-min, slå verifikation fra eller aktivere alle gamle suites fjerner afvisningen uden at opfylde det sikkerhedskrav, der skabte den.

Notér den forhandlede version, suiten og datachifferen i ændringsbilletten. Den næste, der møder en TLS-fejl, starter fra den note i stedet for fra en chifferstreng fundet i et forumindlæg.

Relaterede artikler