OpenVPN TLS-håndtryk mislykkedes: hvilken gren er du på?

Linjen, der siger, at TLS-håndtrykket mislykkedes, er slutningen på en historie, ikke begyndelsen. Det afgørende er hændelsen umiddelbart før, for den hændelse navngiver, hvilken af fire meget forskellige fejl du har. En timeout, en uoverensstemmelse i kontrolkanalen, et afvist certifikat og en fejl efter forhandlingen giver alle samme overskrift. Vælg grenen ud fra beviserne, og rettelsen er ikke længere et gæt.

Læs den sidste hændelse før fejlen

Rul op i stedet for at læse den sidste linje. Hændelsen før afbrydelsen navngiver som regel fasen: intet svar overhovedet, en fejl under udvekslingen af kontrolpakker, et verifikationsresultat eller en vellykket forhandling efterfulgt af et godkendelsesresultat. Hver af dem tilhører en forskellig ejer. Den ene linje afgør, hvilket afsnit nedenfor der gælder.

Gem fejlteksten med klientversionen, endepunktet og transporten. Hold nøgler, adgangskoder og uregerede profiler ude af alt, hvad du indsætter offentligt.

En præcis første fejl er mere værd end et langt loguddrag. Den navngiver fasen, og fasen navngiver ejeren.

Gren et: intet kom tilbage

Hvis klienten sendte sin første pakke og ikke modtog noget brugbart, ligger problemet på vejen eller hos lytteren. Bekræft, at profilen svarer til en mulighed, som operatøren faktisk tilbyder: adresse, port og UDP eller TCP. Kontroller derefter, om endepunktet overhovedet kan nås fra dette netværk. Noter, hvilken af de to kontroller der fejlede, før du går videre.

En browser, der indlæser en side på samme værtsnavn, beviser kun, at en webtjeneste svarede. Selv en accepteret TCP-forbindelse siger intet om, hvorvidt OpenVPN har afsluttet forhandlingen.

Hvis profilen virker på et andet betroet netværk, så behold den sammenligning. Den lokaliserer begrænsningen til en vej eller en mellemled.

Gren to: kontrolkanalen stemmer ikke

Når udvekslingen starter og derefter går i stå, er kontrolkanalens indstillinger den første mistænkte. tls-auth og tls-crypt skal stemme med udrulningen, og materiale fra en anden server giver ikke en brugbar udveksling. Denne fejl sker før enhver kontologin. En profil kopieret fra en ældre server er den sædvanlige kilde.

En nulstilling af adgangskoden erstatter ikke disse indstillinger, og at låne en nøgle fra en anden tjeneste er ikke en kompatibilitetsrettelse. Hent profilen gennem operatørens verificerede kanal, og noter den klientversion, den forventer.

Noter den konkrete forhandlingsfejl i stedet for at aktivere en bunke ældre algoritmer for at se, hvad der holder. En opfanget fejltekst er det, der gør det muligt for operatøren at kontrollere sin side.

Gren tre: et certifikat blev afvist

En udtrykkelig verifikationsfejl navngiver det certifikat, den ikke kan lide. Kontroller enhedens ur først, og læs så hvilket objekt der fejlede: servercertifikatet, klientcertifikatet eller en udsteder i kæden. Udløb, en ubetroet udsteder og en uventet identitet er tre forskellige meddelelser.

Hold verifikationen slået til, mens du skaffer rettet materiale. At acceptere et uvedkommende certifikat fjerner fejlen uden at bevise, at du nåede den tilsigtede server.

Noter, om fejlen følger netværket eller profilen. En certifikatfejl, der dukker op overalt, er ikke et vejproblem.

Gren fire: forhandlingen blev færdig, og noget andet fejlede

Når identitetsudvekslingen lykkes, tilhører den resterende fejl godkendelse eller routing. En udtrykkelig kontofejl er et godkendelsesspørgsmål, og en tilsluttet tunnel med utilgængelige websteder er et routing- eller DNS-spørgsmål. At fortsætte med at udskifte TLS-indstillinger på det tidspunkt skader en fase, der allerede virkede.

Når du rapporterer problemet, så sig, om alle netværk fejler, om en anden profil virker, og om serveren registrerede forsøget. Tavshed på serversiden og en afvisning fra den side ligger ved forskellige grænser.