Tidsgräns för VPN-anslutningen: DNS, transport, förhandling eller inloggning
En tidsgräns betyder bara att en frist har passerat. Jämför fyra steg, namnmatchning, transport, förhandling och inloggning, för att se vilket som slutfördes sist.
”Anslutningen tog slut på tid” är det minst specifika fel en VPN-klient kan skriva ut. Det betyder att en operation missade sin tidsfrist, och varje steg från namnmatchning till inloggningssvaret har en tidsfrist. Klienter som bara visar det sista meddelandet får stegen att se identiska ut, så folk höjer tidsgränsen, byter port och installerar om profilen, i den ordningen, utan att lära sig något. Att jämföra stegen är snabbare: varje steg misslyckas på olika ställen, och varje misslyckande lämnar en annan typ av bevis.
Fyra steg, fyra olika fel
Sekvensen är fast även när klienten döljer den: namnet måste slås upp, en transport måste upprättas till den resulterande adressen, protokollet måste förhandla sina parametrar och nycklar, och kontot måste autentiseras. OpenVPN:s felsökningsguide för anslutningar följer samma ordning för sin egen klient, och de andra följer den nära. En tidsgräns i steg två och en i steg fyra har inget gemensamt utom ordet på skärmen.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
Läs loggen efter den sista raden som visar framsteg, inte den sista raden före felet. De flesta klienter skriver ut något som en uppslagen adress, en upprättad socket, en startad handskakning eller en autentiseringsbegäran, och steget som följer den raden är det som tog slut på tid.
Namnmatchning misslyckas innan något kontaktas
Om slutpunkten aldrig slås upp har klienten inget att ansluta till och inget transportarbete har skett. Det felet är oftast omedelbart i stället för en full tidsgräns, vilket är det billigaste sättet att skilja det från resten. Testa namnet med systemets resolver och med en andra resolver, och jämför de två svaren innan du drar slutsatsen att servern ligger nere.
En gammal adress kopierad från ett foruminlägg är en vanlig orsak till en tidsgräns som ser ut som ett serverproblem, eftersom adressen nu tillhör något annat eller ingenting. Använd operatörens aktuella profil i stället för att ersätta en adress som fungerade tidigare. Ett uteblivet ping-svar är inte bevis i någon riktning: många slutpunkter släpper ICMP medan de tjänar alldeles utmärkt.
Transportuppsättningen väntar på ett paket som inte kommer
När DNS är i ordning och klienten ändå bränner hela tidsgränsen är transportlagret den misstänkta. På TCP kan du testa porten direkt; Test-NetConnection i Windows eller nc -vz i Linux berättar om något accepterar anslutningen, och det är mer användbart än en ping. På UDP kan du inte testa på samma sätt, eftersom det inte finns någon handskakning att slutföra i det lagret, och den asymmetrin orsakar många felaktiga slutsatser.
Vad ett TCP-test bevisar är begränsat: en tjänst som accepterar port 443 är inte nödvändigtvis VPN-lyssnaren, och en slutpunkt med bara UDP har ingen TCP-port att acceptera något på. Att skriva om en profil från UDP till TCP skapar ingen lyssnare på andra sidan; det ändrar bara vad din klient väntar på. Om nätet filtrerar protokollet ger ändringen en annan tidsgräns i samma steg.
Captive-portaler förtjänar en egen kontroll i detta steg. Tills portalen auktoriserar enheten går utgående trafik till portalen och tunnel-försöket bara hänger. Slutför portalen i en webbläsare först, försök sedan igen, och ändra inte profilen medan portalen fortfarande väntar.
Förhandling och inloggning betyder att servern svarade
Så snart tunneln når servern startar klienten en handskakning och felet byter karaktär. Ett stopp här handlar om kompatibilitet, inte om nåbarhet: protokollversioner som inte passar, en cipher- eller datakanalinställning som andra sidan inte accepterar, eller en profil som förväntar sig en funktion servern inte erbjuder. OpenVPN har flyttat sina standardvärden för förhandling mellan huvudversioner tillräckligt ofta för att en profil skriven för en generation kan nå servern och ändå inte komma upp.
Autentisering är det sista steget och det lättaste att läsa fel. Ett tydligt avslag är ett svar, vilket betyder att vägen fungerar och problemet är identiteten, certifikatet eller kontots tillstånd. Ett webbläsarbaserat single sign-on-flöde är ett tredje fall: klienten väntar på en åtgärd du inte gjort, eller på en webbläsare den inte kan starta, och ingenting kommer förrän du slutför det steget.
Jämför bevisen innan du ändrar nya försök
Håll enheten och profilen fasta och ändra en sak i taget, med början i nätet. Om samma profil ansluter på en telefonhotspot och får tidsgräns på hotell-Wi-Fi är vägen variabeln, inte servern. Om den misslyckas överallt är profilen eller slutpunkten variabeln. Om den bara misslyckas vid en viss tid på dygnet, fånga tidsstämpeln och jämför den med händelser på serversidan innan du antar något om belastning.
För en tjänst du administrerar är den avgörande jämförelsen om försöket ens anländer. En anslutning som når lyssnaren och sedan stannar hör till förhandlingssteget; en som aldrig dyker upp i lyssnarens synfält är ett transport- eller uppslagsproblem, och ingen justering av nya försök flyttar den. Serverloggar skiljer också en avvisad inloggning från ett tyst tapp, vilket är skillnaden mellan en identitetsrättelse och en brandväggsrättelse.
Notera klientversionen, profilnamnet, försökstiden med dess tidszon och det första användbara felet i stället för den sista frånkopplade raden. Ta bort nycklar och uppgifter som bär legitimation innan du delar utdraget. Gör sedan en meningsfull rättelse och försök igen, eftersom en längre tidsfrist bara hjälper den dokumenterat långsamma operationen och inte gör något för en felaktig adress eller en blockerad port.