VPN-tilkopling tidsavbrot: DNS, transport, forhandling eller pålogging
Eit tidsavbrot tyder berre at ein frist er passert. Samanlikne fire trinn, namneoppslag, transport, forhandling og pålogging, for å sjå kva som vart fullført sist.
«Tilkoplinga fekk tidsavbrot» er den minst konkrete feilen ein VPN-klient kan skrive ut. Han tyder at éin operasjon mista fristen sin, og kvart trinn frå namneoppslag til påloggingssvaret har ein frist. Klientar som berre viser den siste meldinga, gjer trinna identiske, så folk aukar tidsavbrotet, byter port og installerer profilen på nytt, i den rekkjefølgja, utan å lære noko. Å samanlikne trinna er raskare: kvart trinn feilar på ein annan stad, og kvar feil etterlèt ein annan type prov.
Fire trinn, fire ulike feil
Rekkjefølgja er fast sjølv når klienten skjuler ho: namnet må slåast opp, det må etablerast transport til adressa som kjem ut, protokollen må forhandle parametrane og nøklane sine, og kontoen må autentiserast. OpenVPNs feilsøkingsrettleiing for tilkoplingar følgjer same rekkjefølgje for sin eigen klient, og dei andre følgjer ho tett. Eit tidsavbrot i trinn to og eit i trinn fire har ingenting til felles bortsett frå 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 linja som viser framdrift, ikkje den siste linja før feilen. Dei fleste klientar skriv ut noko som ei oppløyst adresse, ein etablert socket, eit starta handtrykk eller ein autentiseringsførespurnad, og trinnet som følgjer den linja, er det som fekk tidsavbrot.
Namneoppslag feilar før noko vert kontakta
Viss endepunktet aldri vert slått opp, har klienten ingenting å kople til, og det har ikkje skjedd noko transportarbeid. Den feilen er vanlegvis augneblinkleg i staden for eit fullt tidsavbrot, og det er den billegaste måten å skilje han frå resten. Test namnet med systemresolveren og med ein annan resolver, og samanlikne dei to svara før du konkluderer med at tenaren er nede.
Ei gammal adresse kopiert frå eit foruminnlegg er ei vanleg årsak til tidsavbrot som ser ut som eit tenarproblem, fordi adressa no høyrer til noko anna eller ingenting. Bruk den gjeldande profilen til operatøren i staden for å erstatte ei adresse som fungerte før. Eit manglande ping-svar er ikkje prov i noka retning: mange endepunkt droppar ICMP medan dei tener heilt fint.
Transportoppsettet ventar på ein pakke som ikkje kjem
Når DNS er i orden og klienten likevel brenn heile tidsavbrotet, er transportlaget den mistenkte. På TCP kan du teste porten direkte; Test-NetConnection på Windows eller nc -vz på Linux fortel deg om noko godtek tilkoplinga, og det er nyttigare enn ein ping. På UDP kan du ikkje teste på same måte, fordi det ikkje er noko handtrykk å fullføre på det laget, og denne asymmetrien skaper mange feilaktige konklusjonar.
Det ein TCP-test provar, er avgrensa: ein teneste som godtek port 443 er ikkje nødvendigvis VPN-lyttaren, og eit endepunkt med berre UDP har ingen TCP-port å godta noko på. Å skrive om ein profil frå UDP til TCP lagar ikkje ein lyttar i den andre enden; det endrar berre kva klienten din ventar på. Viss nettverket filtrerer protokollen, gjev endringa eit anna tidsavbrot i same trinn.
Captive-portalar fortener si eiga sjekk i dette trinnet. Inntil portalen autoriserer eininga, går utgåande trafikk til portalen, og tunneleforsøket heng berre. Fullfør portalen i ein nettlesar først, prøv deretter igjen, og ikkje endre profilen medan portalen enno ventar.
Forhandling og pålogging tyder at tenaren svara
Når tunnelen når tenaren, startar klienten eit handtrykk, og feilen skiftar karakter. Ein stans her handlar om kompatibilitet, ikkje om tilgjenge: protokollversjonar som ikkje passar, ei cipher- eller datakanalinnstilling den andre sida ikkje godtek, eller ein profil som ventar ein funksjon tenaren ikkje tilbyr. OpenVPN har flytta standardinnstillingane for forhandling mellom hovudversjonar ofte nok til at ein profil skriven for éin generasjon kan nå tenaren og likevel ikkje kome opp.
Autentisering er det siste trinnet og det lettaste å lese feil. Ei tydeleg avvising er eit svar, som tyder at vegen verkar og problemet er identiteten, sertifikatet eller kontotilstanden. Ein nettlesarbasert innloggingsflyt er eit tredje tilfelle: klienten ventar på ei handling du ikkje har utført, eller på ein nettlesar han ikkje kan starte, og ingenting kjem før du fullfører det trinnet.
Samanlikne prova før du endrar nye forsøk
Hald eininga og profilen fast og endre éin ting om gongen, med utgangspunkt i nettverket. Viss same profil koplar til på ein telefon-hotspot og får tidsavbrot på hotell-Wi-Fi, er vegen variabelen, ikkje tenaren. Viss han feilar overalt, er profilen eller endepunktet variabelen. Viss han berre feilar på eit bestemt tidspunkt, fang tidsstempelet og samanlikne det med hendingar på tenarsida før du antar noko om belastning.
For ein teneste du administrerer, er den avgjerande samanlikninga om forsøket i det heile kjem fram. Ei tilkopling som når lyttaren og deretter stoppar, høyrer til forhandlingstrinnet; ei som aldri dukkar opp i synsfeltet til lyttaren, er eit transport- eller oppslagsproblem, og inga justering av nye forsøk flyttar ho. Tenarloggar skil òg ei avvist pålogging frå eit stille dropp, som er skilnaden mellom ei identitetsretting og ei brannmurretting.
Noter klientversjonen, profilnamnet, forsøkstida med tidssona og den første nyttige feilen i staden for den siste fråkopla linja. Fjern nøklar og legitimasjonsberande materiale før du deler utdraget. Gjer deretter éi meiningsfull retting og prøv igjen, fordi ein lengre frist berre hjelper den dokumenterte langsame operasjonen og gjer ingenting for ei feil adresse eller ein blokkert port.