Hvilke protokoller tilbyr denne offentlige VPN-noden egentlig?
At serverprogramvaren støtter en protokoll betyr ikke at denne noden har aktivert den. Kontroller endepunktet, profilen og trinnet som faktisk feiler.
Programvaren støtter det, altså tilbyr noden det. Den slutningen er feil ofte nok til å være en regel: en SoftEther-utrulling kan aktivere en vilkårlig delmengde av sine kompatible tilkoblingsmetoder, og en offentlig node er en utrulling med en eier og en konfigurasjon. Hva du kan koble til, avhenger av den noden, ikke av funksjonslisten til prosjektet den kjører. Det er i gapet mellom de to at de fleste «protokollen er ødelagt»-sakene faktisk bor.
Hva prosjektlisten egentlig lover
Prosjektets protokollfunksjoner beskriver hva serveren er i stand til. En gitt node aktiverer noen av disse lytterne og ikke andre, og operatøren kan endre det settet uten å røre programvareversjonen. To noder på samme bygg oppfører seg derfor forskjellig, og en profil som virker mot den ene, beviser ingenting om neste mål. Nodens egen liste veier tyngre enn prosjektsiden når du velger hvor du vil koble til.
Les listen som fem felt, ikke som en meny: endepunkt, port, transport, protokollfamilie og autentiseringsmetode. En offentlig node som annonserer SSTP har fortalt deg om en lytter på en port; den har ikke fortalt deg hvilket sertifikat den presenterer eller om kontoen din virker der. Å sammenligne de fem feltene med profilen din er raskere enn noen mengde reinstallasjon av klienten, og det gir en skriftlig forventning du kan teste senere.
Tilpass profilen til endepunktet den navngir
En innebygd SoftEther-oppføring er ikke automatisk en OpenVPN-konfigurasjon, selv når begge vises på én leverandørside under én overskrift. Når en node publiserer både en TCP- og en UDP-lytter for OpenVPN, behandle dem som to endepunkter: en profil som er redigert fra den ene til den andre, peker på en lytter som ingen har aktivert. Transportetiketten i filen er en del av adressen, ikke en kosmetisk innstilling.
At klienten godtar en importert fil, fastslår at filen kan parses. Det sier ingenting om hvorvidt en ekstern lytter venter i den andre enden, og derfor er det første tilkoblingsforsøket den egentlige testen. Sammenlign profilens remote-linje med nodens annonserte vert og port før du gir protokollen skylden.
Undersøk trinnet som feiler
En vert som svarer på webtrafikk, kan fortsatt mangle den tiltenkte VPN-tjenesten, og en vert som avviser én protokoll, er ikke nødvendigvis nede for alle. De to feilene sender folk i motsatte retninger samme ettermiddag. Den ene jager en brannmur som er i orden; den andre installerer på nytt en klient som aldri var problemet. Undersøk hver vei separat, slik at svaret beskriver én lytter i stedet for hele verten.
Disse fem kontrollene dekker de vanlige metodene for offentlige noder. Kjør dem fra det samme nettverket som klienten bruker, fordi en filtrert port ser identisk ut med en manglende lytter på avstand.
nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example
| Resultat | Trinn | Hva det utelukker |
|---|---|---|
| Tilkobling avvist eller tidsavbrudd | Transport | Lytter mangler, er filtrert eller feil port |
| TLS-håndtrykk- eller identitetsfeil | Sertifikat | Protokollens tilgjengelighet; lytteren svarte |
| AUTH_FAILED eller kontoavvisning | Autentisering | Endepunktet; problemet er påloggingsinformasjonen |
| UDP 500 og 4500 tause | IPsec-forhandling | ESP og L2TP er blokkert før autentisering |
Knytt hver observerte feil til raden sin før du endrer noe. En TLS-identitetsfeil beviser at lytteren finnes, så å skrive om profilen til en annen protokoll ville kaste bort fungerende bevis. En avvist tilkobling beviser bare at denne porten ikke svarte, noe som er en mye snevrere påstand enn «noden støtter ikke OpenVPN».
Bevar feilen før du endrer noe
Skriv ned det nøyaktige resultatet: et tidsavbrudd, en sertifikatidentitetsfeil, en kontoavvisning og en avvisning på applikasjonsnivå er fire forskjellige utfall. Bare den første handler om en protokoll som ikke er tilgjengelig, og bare den siste handler om tillatelse etter en vellykket tilkobling. Nullstilling av klienten eller bytte av protokoller ødelegger den forskjellen, fordi neste feil kommer med en annen historikk og uten en grunnlinje å sammenligne med.
Ikke svekk verifiseringen for å få en inkompatibel profil til å se ut som den virker. En deaktivert sertifikatkontroll gjør en klar identitetsfeil om til en tilkobling til noe du ikke hadde til hensikt å nå, og den resulterende suksessen er verre enn den opprinnelige feilen fordi den skjuler hvilket trinn som var feil.
Kontroller på nytt per node, hver gang
De innebygde valgene SSL, OpenVPN, L2TP/IPsec og SSTP på en offentlig nodeliste beskriver den nodens konfigurasjon i det øyeblikket. Den samme programvaren andre steder kan presentere et annet sett, og en leverandør kan trekke tilbake en lytter mellom bokmerket ditt og ditt neste forsøk. Gamle notater beskriver gamle utrullinger.
Noter den verifiserte profilen med endepunktet og metoden, og gjenta deretter undersøkelsen når noden endres eller tilkoblingen begynner å feile. SoftEther-protokollspesifikasjonen er referansen for hva programvaren kan; nodens egen liste er referansen for hva den gjør. Hold de to dokumentene atskilt, så blir diagnosen kortere.