VPN-tilkobling tidsavbrudd: DNS, transport, forhandling eller pålogging
Tidsavbrudd betyr bare at en frist har gått ut. Sammenlign fire trinn, navneoppslag, transport, forhandling og pålogging, for å se hvilket som ble fullført sist.
«Tilkoblingen fikk tidsavbrudd» er den minst konkrete feilen en VPN-klient kan skrive ut. Den betyr at én operasjon mistet fristen sin, og hvert trinn fra navneoppslag til påloggingssvaret har en frist. Klienter som bare viser den siste meldingen, får trinnene til å se identiske ut, så folk øker tidsavbruddet, bytter port og installerer profilen på nytt, i den rekkefølgen, uten å lære noe. Å sammenligne trinnene er raskere: hvert trinn feiler på et annet sted, og hver feil etterlater en annen type bevis.
Fire trinn, fire forskjellige feil
Rekkefølgen er fast selv når klienten skjuler den: navnet må slås opp, det må etableres transport til adressen som kommer ut, protokollen må forhandle parametrene og nøklene sine, og kontoen må autentiseres. OpenVPNs feilsøkingsveiledning for tilkoblinger følger samme rekkefølge for sin egen klient, og de andre følger den tett. Et tidsavbrudd i trinn to og et i trinn fire har ingenting til felles bortsett fra ordet på skjermen.
| 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 |
Les loggen etter den siste linjen som viser fremdrift, ikke den siste linjen før feilen. De fleste klienter skriver ut noe som en oppslått adresse, en etablert socket, en startet håndtrykk eller en autentiseringsforespørsel, og trinnet som følger den linjen, er det som fikk tidsavbrudd.
Navneoppslag feiler før noe kontaktes
Hvis endepunktet aldri slås opp, har klienten ingenting å koble til, og det har ikke skjedd noe transportarbeid. Den feilen er vanligvis umiddelbar i stedet for et fullt tidsavbrudd, og det er den billigste måten å skille den fra resten. Test navnet med systemets resolver og med en annen resolver, og sammenlign de to svarene før du konkluderer med at serveren er nede.
En gammel adresse kopiert fra et foruminnlegg er en vanlig årsak til tidsavbrudd som ser ut som et serverproblem, fordi adressen nå tilhører noe annet eller ingenting. Bruk operatørens gjeldende profil i stedet for å erstatte en adresse som fungerte før. Et manglende ping-svar er ikke bevis i noen retning: mange endepunkter dropper ICMP mens de tjener helt fint.
Transportoppsettet venter på en pakke som ikke kommer
Når DNS er i orden og klienten likevel brenner hele tidsavbruddet, er transportlaget den mistenkte. På TCP kan du teste porten direkte; Test-NetConnection på Windows eller nc -vz på Linux forteller deg om noe godtar tilkoblingen, og det er nyttigere enn en ping. På UDP kan du ikke teste på samme måte, fordi det ikke er noe håndtrykk å fullføre på det laget, og denne asymmetrien skaper mange feilaktige konklusjoner.
Det en TCP-test beviser, er begrenset: en tjeneste som godtar port 443 er ikke nødvendigvis VPN-lytteren, og et endepunkt med bare UDP har ingen TCP-port å godta noe på. Å skrive om en profil fra UDP til TCP lager ikke en lytter i den andre enden; det endrer bare hva klienten din venter på. Hvis nettverket filtrerer protokollen, gir endringen et annet tidsavbrudd i samme trinn.
Captive-portaler fortjener sin egen sjekk i dette trinnet. Inntil portalen autoriserer enheten, går utgående trafikk til portalen, og tunnel-forsøket henger bare. Fullfør portalen i en nettleser først, prøv deretter igjen, og ikke endre profilen mens portalen fortsatt venter.
Forhandling og pålogging betyr at serveren svarte
Når tunnelen når serveren, starter klienten et håndtrykk, og feilen skifter karakter. En stans her handler om kompatibilitet, ikke om tilgjengelighet: protokollversjoner som ikke passer, en cipher- eller datakanalinnstilling den andre siden ikke godtar, eller en profil som forventer en funksjon serveren ikke tilbyr. OpenVPN har flyttet standardinnstillingene for forhandling mellom hovedversjoner ofte nok til at en profil skrevet for én generasjon kan nå serveren og likevel ikke komme opp.
Autentisering er det siste trinnet og det letteste å lese feil. En tydelig avvisning er et svar, som betyr at veien virker og problemet er identiteten, sertifikatet eller kontotilstanden. En nettleserbasert innloggingsflyt er et tredje tilfelle: klienten venter på en handling du ikke har utført, eller på en nettleser den ikke kan starte, og ingenting kommer før du fullfører det trinnet.
Sammenlign bevisene før du endrer nye forsøk
Hold enheten og profilen fast og endre én ting om gangen, med utgangspunkt i nettverket. Hvis samme profil kobler til på et telefon-hotspot og får tidsavbrudd på hotell-Wi-Fi, er veien variabelen, ikke serveren. Hvis den feiler overalt, er profilen eller endepunktet variabelen. Hvis den bare feiler på et bestemt tidspunkt, fang tidsstempelet og sammenlign det med hendelser på serversiden før du antar noe om belastning.
For en tjeneste du administrerer, er den avgjørende sammenligningen om forsøket i det hele tatt ankommer. En tilkobling som når lytteren og deretter stopper, hører til forhandlingstrinnet; en som aldri dukker opp i lytterens synsfelt, er et transport- eller oppslagsproblem, og ingen justering av nye forsøk flytter det. Serverlogger skiller også en avvist pålogging fra et stille dropp, som er forskjellen mellom en identitetsretting og en brannmurretting.
Noter klientversjonen, profilnavnet, forsøkstiden med tidssonen og den første nyttige feilen i stedet for den siste frakoblede linjen. Fjern nøkler og legitimasjonsbærende materiale før du deler utdraget. Gjør deretter én meningsfull rettelse og prøv igjen, fordi en lengre frist bare hjelper den dokumenterte langsomme operasjonen og gjør ingenting for en feil adresse eller en blokkert port.