Den offentlige VPN-listen sier på nett; klienten din sier nei
En katalog viser en sjekk fra noen minutter siden, ikke et løfte for ditt neste forsøk. Gå gjennom tilkoblingens faser i rekkefølge og se hvor noden faktisk svikter.
Du åpner katalogen, sorterer etter hastighet, velger en node merket som på nett, og klienten gir opp før den er ferdig med å koble til. Listen løy ikke, strengt tatt. Den rapporterte resultatet av noen andres sondering, fra et annet nettverk, på et tidligere tidspunkt, mot en tjeneste som en frivillig kan slå av når som helst. Å forstå dette gapet gjør en frustrerende jakt om til en kort rekke sjekker du kan kjøre på hvilken som helst kandidat.
Hva listen faktisk målte
En offentlig katalog holder felt som tidspunktet for siste sjekk, en observert rundturtall, et sesjonstall og noen ganger en protokolliste. Hvert av dem beskriver den siste vellykkede observasjonen fra prosjektets eget ståsted, ikke nodens tilstand når pakken din ankommer.
Ferskheten betyr mer enn tallet. En node som ble sjekket for fire minutter siden, og en node som ble sjekket for fire timer siden, kan vise samme grønne markør, og bare én av dem ligner fortsatt på den registrerte tilstanden. Se etter tidsstempelet, ikke fargen.
Frivillig drift legger til en andre endringskilde som ingen overvåking kan rette. Operatøren starter kanskje en bærbar PC på nytt, går tom for båndbredde, bytter leverandør eller lukker bare lokket. En oppføring i listen er en kandidat, og å behandle den som en tjenestenivåavtale er en kategorifeil.
Følg klientens faser, ikke snurren
Hver VPN-klient går gjennom den samme brede sekvensen: løs opp navnet, åpne en transportforbindelse, forhandle sikkerhet, autentiser, og sett deretter opp tunnelen og send data. Et svikt i hver fase etterlater forskjellige spor, og snurren viser ingen av dem.
Begynn med navneoppslag. Hvis vertsnavnet ikke løses opp, er ingenting om nodens tilgjengelighet testet, fordi forbindelsen aldri forlot maskinen din. Deretter transporten: en avvist eller tidsavbrutt TCP- eller UDP-utveksling forteller deg at endepunktet ikke svarer på den porten, noe som er et reelt funn om noden. Så forhandling og autentisering, der et feil sertifikat, en utløpt profil eller en mismatch av chiffer feiler mens noden er helt frisk. Først etter at tunnelen er satt opp, kan en ruting- eller DNS-feil forklare det siste trinnet.
Les klientloggen med den høyeste detaljgraden som fortsatt får plass på skjermen, og noter den siste linjen som lyktes. Den linjen er der diagnosen begynner, og den er vanligvis mer informativ enn noe katalogen viser.
Én variabel per forsøk
Sammenlign kandidater med samme klient, samme aksessnett og samme profilformat, og endre bare endepunktet. Ellers kan en feil være din, og du vil tilskrive den noden.
To forsøk er nok til å fastslå et mønster, og et tredje bekrefter det. Hvis node A svikter i transportfasen og node B i autentiseringen, har du to uavhengige problemer i stedet for én utdatert liste.
Når hver node svikter på samme måte
En universell svikt i den første fasen peker mot din side: en oppløser som ikke kan svare, en lokal brannmur som blokkerer protokollen, eller et nettverk som bare tillater webtrafikk. Katalogen kan ikke rapportere det, fordi sonderingene ikke kjører fra din plass.
Test tilfellet med et formet nettverk med vilje. Noen aksessnett tillater HTTPS til nettet og slipper andre protokoller, noe som får hver kandidat til å se død ut mens listen er nøyaktig. Å sammenligne en sideinnlasting i nettleseren med et rått tilkoblingsforsøk skiller de to situasjonene på under et minutt.
Les feilen i den fasen der den oppstod
Reproduser forsøket fra en terminal slik at fasene er synlige. De tre kommandoene nedenfor løser opp navnet, tester om porten svarer, og skriver ut forhandlingslinjene fra en OpenVPN-profil:
dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"Hvis porten svarer og forhandlingslinjen rapporterer et sertifikatproblem, er noden oppe og profilen din utdatert. Hvis porten ikke svarer i det hele tatt, er oppføringen en kandidat som feilet, og å gå videre til den neste er riktig svar i stedet for å feilsøke klienten din. Noter fasen på en kort linje, og neste forsøk begynner med kunnskap i stedet for håp.