OpenVPN: TLS-håndtrykket mislyktes – hvilken gren er du på?

Linjen som sier at TLS-håndtrykket mislyktes, er slutten på en historie, ikke begynnelsen. Det avgjørende er hendelsen rett før, for den hendelsen navngir hvilken av fire svært forskjellige feil du har. En tidsavbrudd, en uoverensstemmelse i kontrollkanalen, et avvist sertifikat og en feil etter forhandlingen gir alle samme overskrift. Velg grenen ut fra bevisene, og rettelsen er ikke lenger en gjetning.

Les den siste hendelsen før feilen

Rull opp i stedet for å lese den siste linjen. Hendelsen før frakoblingen navngir vanligvis fasen: ikke noe svar i det hele tatt, en feil under utvekslingen av kontrollpakker, et verifiseringsresultat eller en vellykket forhandling etterfulgt av et autentiseringsresultat. Hver av dem tilhører en annen eier. Den ene linjen avgjør hvilken del nedenfor som gjelder.

Lagre feilteksten med klientversjonen, endepunktet og transporten. Hold nøkler, passord og uredigerte profiler unna alt du limer inn offentlig.

En presis første feil er mer verdt enn et langt loggutdrag. Den navngir fasen, og fasen navngir eieren.

Gren én: ingenting kom tilbake

Hvis klienten sendte sin første pakke og ikke mottok noe brukbart, ligger problemet på veien eller hos lytteren. Bekreft at profilen samsvarer med et alternativ operatøren faktisk tilbyr: adresse, port og UDP eller TCP. Sjekk deretter om endepunktet i det hele tatt er nåbart fra dette nettverket. Noter hvilken av de to sjekkene som feilet før du går videre.

En nettleser som laster en side på samme vertsnavn, beviser bare at en nettjeneste svarte. Selv en akseptert TCP-tilkobling sier ingenting om hvorvidt OpenVPN fullførte forhandlingen.

Hvis profilen fungerer på et annet klarert nettverk, behold den sammenligningen. Den lokaliserer begrensningen til en vei eller et mellomledd.

Gren to: kontrollkanalen stemmer ikke

Når utvekslingen starter og deretter stopper, er innstillingene for kontrollkanalen den første mistenkte. tls-auth og tls-crypt må stemme med utrullingen, og materiale fra en annen server gir ikke en brukbar utveksling. Denne feilen oppstår før enhver kontopålogging. En profil kopiert fra en eldre server er den vanlige kilden.

En tilbakestilling av passordet erstatter ikke disse innstillingene, og å låne en nøkkel fra en annen tjeneste er ikke en kompatibilitetsrettelse. Skaff profilen gjennom operatørens verifiserte kanal, og noter klientversjonen den forventer.

Noter den konkrete forhandlingsfeilen i stedet for å aktivere en haug med eldre algoritmer for å se hva som holder. En fanget feiltekst er det som gjør det mulig for operatøren å sjekke sin side.

Gren tre: et sertifikat ble avvist

En uttrykkelig verifiseringsfeil navngir sertifikatet den ikke liker. Sjekk enhetens klokke først, og les deretter hvilket objekt som feilet: serverens sertifikat, klientens sertifikat eller en utsteder i kjeden. Utløp, en ikke-klarert utsteder og en uventet identitet er tre forskjellige meldinger.

Hold verifiseringen på mens du skaffer rettet materiale. Å godta et urelatert sertifikat fjerner feilen uten å bevise at du nådde den tiltenkte serveren.

Noter om feilen følger nettverket eller profilen. En sertifikatfeil som dukker opp overalt, er ikke et veiproblem.

Gren fire: forhandlingen var ferdig og noe annet feilet

Når identitetsutvekslingen lykkes, tilhører den gjenværende feilen autentisering eller ruting. En uttrykkelig kontoavvisning er et autentiseringsspørsmål, og en tilkoblet tunnel med utilgjengelige nettsteder er et ruting- eller DNS-spørsmål. Å fortsette å bytte ut TLS-alternativer på det tidspunktet skader en fase som allerede fungerte.

Når du rapporterer problemet, si om hvert nettverk feiler, om en annen profil virker, og om serveren registrerte forsøket. Taushet på serversiden og en avvisning derfra står ved forskjellige grenser.