VPN-forbindelse timeout: DNS, transport, forhandling eller login

“Forbindelsen fik timeout” er den mindst specifikke fejl, en VPN-klient kan udskrive. Den betyder, at én handling missede sin frist, og hvert trin fra navneopslag til login-svaret har en frist. Klienter, der kun viser den sidste besked, får trinnene til at se ens ud, så folk hæver timeoutet, skifter port og geninstallerer profilen, i den rækkefølge, uden at lære noget. Det er hurtigere at sammenligne trinnene: hvert trin fejler et forskelligt sted, og hver fejl efterlader en anden slags bevis.

Fire trin, fire forskellige fejl

Rækkefølgen er fast, selv når klienten skjuler den: navnet skal slås op, der skal oprettes en transport til den resulterende adresse, protokollen skal forhandle sine parametre og nøgler, og kontoen skal godkendes. OpenVPN's fejlfindingsguide til forbindelser følger samme rækkefølge for sin egen klient, og de øvrige følger den tæt. Et timeout i trin to og et timeout i trin fire har intet til fælles undtagen ordet på skærmen.

Læs loggen efter den sidste linje, der viser fremskridt, ikke den sidste linje før fejlen. De fleste klienter udskriver noget som en opløst adresse, en etableret socket, et startet handshake eller en godkendelsesanmodning, og det trin, der følger efter den linje, er det, der fik timeout.

Navneopslag fejler, før noget kontaktes

Hvis endepunktet aldrig slås op, har klienten intet at forbinde til, og der er ikke sket noget transportarbejde. Den fejl er normalt øjeblikkelig i stedet for et fuldt timeout, hvilket er den billigste måde at skelne den fra resten. Test navnet med systemets resolver og med en anden resolver, og sammenlign de to svar, før du konkluderer, at serveren er nede.

En gammel adresse kopieret fra et forumindlæg er en almindelig årsag til et timeout, der ligner et serverproblem, fordi adressen nu tilhører noget andet eller ingenting. Brug operatørens aktuelle profil i stedet for at erstatte en adresse, der tidligere virkede. Et manglende ping-svar er ikke bevis i nogen retning: mange endepunkter dropper ICMP, mens de tjener helt fint.

Transportopsætning venter på en pakke, der ikke kommer

Når DNS er i orden, og klienten stadig brænder hele timeoutet, er transportlaget den mistænkte. På TCP kan du teste porten direkte; Test-NetConnection på Windows eller nc -vz på Linux fortæller dig, om noget accepterer forbindelsen, og det er mere nyttigt end en ping. På UDP kan du ikke teste på samme måde, fordi der ikke er noget handshake at fuldføre på det lag, og denne asymmetri skaber mange forkerte konklusioner.

Hvad en TCP-test beviser, er begrænset: en tjeneste, der accepterer port 443, er ikke nødvendigvis VPN-lytteren, og et endepunkt med kun UDP har ingen TCP-port at acceptere noget på. At skrive en profil om fra UDP til TCP skaber ikke en lytter i den anden ende; det ændrer kun, hvad din klient venter på. Hvis netværket filtrerer protokollen, giver ændringen et andet timeout på samme trin.

Captive-portaler fortjener deres egen kontrol på dette trin. Indtil portalen godkender enheden, går udgående trafik til portalen, og tunnel-forsøget hænger blot. Fuldfør først portalen i en browser, prøv derefter igen, og skift ikke profilen, mens portalen stadig venter.

Forhandling og login betyder, at serveren svarede

Når tunnelen når serveren, starter klienten et handshake, og fejlen skifter karakter. Et stop her handler om kompatibilitet snarere end om nåbarhed: uoverensstemmende protokolversioner, en cipher- eller datakanalindstilling, som den anden side ikke accepterer, eller en profil, der forventer en funktion, serveren ikke tilbyder. OpenVPN har flyttet sine standardindstillinger for forhandling mellem hovedversioner så ofte, at en profil skrevet til én generation kan nå serveren og stadig ikke komme op.

Godkendelse er det sidste trin og det nemmeste at læse forkert. En eksplicit afvisning er et svar, hvilket betyder, at vejen virker, og problemet er identiteten, certifikatet eller kontoens tilstand. Et browserbaseret single sign-on-flow er et tredje tilfælde: klienten venter på en handling, du ikke har foretaget, eller på en browser, den ikke kan starte, og der kommer intet, før du fuldfører det trin.

Sammenlign beviserne, før du ændrer gentagelsen

Hold enheden og profilen fast og ændr én ting ad gangen, begyndende med netværket. Hvis samme profil forbinder på et telefon-hotspot og får timeout på hotel-Wi-Fi, er vejen variablen, ikke serveren. Hvis den fejler overalt, er profilen eller endepunktet variablen. Hvis den kun fejler på et bestemt tidspunkt, skal du fange tidsstemplet og sammenligne det med begivenheder på serversiden, før du antager noget om belastning.

For en tjeneste, du administrerer, er den afgørende sammenligning, om forsøget overhovedet ankommer. En forbindelse, der når lytteren og derefter går i stå, hører til forhandlingstrinnet; en, der aldrig dukker op i lytterens synsfelt, er et transport- eller opløsningsproblem, og ingen justering af gentagelser flytter det. Serverlogge adskiller også et afvist login fra et tavst drop, hvilket er forskellen mellem en identitetsrettelse og en firewall-rettelse.

Notér klientversionen, profilnavnet, forsøgstidspunktet med tidszone og den første brugbare fejl i stedet for den sidste afbrudte linje. Fjern nøgler og legitimationsbærende materiale, før du deler uddraget. Lav derefter én meningsfuld rettelse og prøv igen, for en længere frist hjælper kun den dokumenterede langsomme handling og gør intet for en forkert adresse eller en blokeret port.