Hvilke protokoller tilbyder denne offentlige VPN-node egentlig?

Softwaren understøtter det, altså tilbyder noden det. Den slutning er forkert ofte nok til at være en regel: en SoftEther-udrulning kan aktivere en vilkårlig delmængde af sine kompatible forbindelsesmetoder, og en offentlig node er en udrulning med en ejer og en konfiguration. Hvad du kan forbinde med, afhænger af den node, ikke af funktionslisten for det projekt, den kører. Det er i gabet mellem de to, at de fleste “protokollen er i stykker”-sager faktisk bor.

Hvad projektlisten egentlig lover

Projektets protokolfunktioner beskriver, hvad serveren er i stand til. En given node aktiverer nogle af disse lyttere og ikke andre, og operatøren kan ændre det sæt uden at røre softwareversionen. To noder på samme build opfører sig derfor forskelligt, og en profil, der virker mod den ene, beviser intet om det næste mål. Nodens egen liste vejer tungere end projektsiden, når du vælger, hvor du vil forbinde.

Læs listen som fem felter, ikke som en menu: endepunkt, port, transport, protokolfamilie og godkendelsesmetode. En offentlig node, der annoncerer SSTP har fortalt dig om en lytter på en port; den har ikke fortalt dig, hvilket certifikat den fremviser, eller om din konto virker der. At sammenligne de fem felter med din profil er hurtigere end nogen mængde geninstallation af klienten, og det giver en skriftlig forventning, du kan teste senere.

Tilpas profilen til det endepunkt, den nævner

En indbygget SoftEther-post er ikke automatisk en OpenVPN-konfiguration, selv når begge optræder på én udbyderside under én overskrift. Når en node udgiver både en TCP- og en UDP-lytter til OpenVPN, skal du behandle dem som to endepunkter: en profil, der er redigeret fra den ene til den anden, peger på en lytter, som ingen har aktiveret. Transportmærket i filen er en del af adressen, ikke en kosmetisk indstilling.

At klienten accepterer en importeret fil, fastslår, at filen kan parses. Det siger intet om, hvorvidt en fjern lytter venter i den anden ende, og derfor er det første forbindelsesforsøg den rigtige test. Sammenlign profilens remote-linje med nodens annoncerede vært og port, før du giver protokollen skylden.

Undersøg det trin, der fejler

En vært, der svarer på webtrafik, kan stadig mangle den tilsigtede VPN-tjeneste, og en vært, der afviser én protokol, er ikke nødvendigvis nede for dem alle. De to fejl sender folk i modsatte retninger samme eftermiddag. Den ene jager en firewall, der er i orden; den anden geninstallerer en klient, der aldrig var problemet. Undersøg hver vej separat, så svaret beskriver én lytter i stedet for hele værten.

Disse fem kontroller dækker de almindelige metoder til offentlige noder. Kør dem fra det samme netværk, som klienten bruger, fordi en filtreret port ser identisk ud med en manglende lytter på afstand.

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

Knyt hver observeret fejl til dens række, før du ændrer noget. En TLS-identitetsfejl beviser, at lytteren findes, så at omskrive profilen til en anden protokol ville kassere fungerende bevis. En afvist forbindelse beviser kun, at denne port ikke svarede, hvilket er et meget snævrere udsagn end “noden understøtter ikke OpenVPN”.

Bevar fejlen, før du ændrer noget

Skriv det præcise resultat ned: en timeout, en certifikatidentitetsfejl, en kontoafvisning og en afvisning på applikationsniveau er fire forskellige udfald. Kun det første handler om en protokol, der ikke er tilgængelig, og kun det sidste handler om tilladelse efter en vellykket forbindelse. Nulstilling af klienten eller udskiftning af protokoller ødelægger den sondring, fordi den næste fejl kommer med en anden historik og ingen basislinje at sammenligne med.

Svækk ikke verifikationen for at få en inkompatibel profil til at se ud, som om den virker. En deaktiveret certifikatkontrol forvandler en klar identitetsfejl til en forbindelse til noget, du ikke havde til hensigt at nå, og den resulterende succes er værre end den oprindelige fejl, fordi den skjuler, hvilket trin der var forkert.

Kontroller hver node igen, hver gang

De indbyggede valg SSL, OpenVPN, L2TP/IPsec og SSTP på en offentlig nodeliste beskriver den nodes konfiguration i det øjeblik. Den samme software andre steder kan præsentere et andet sæt, og en udbyder kan trække en lytter tilbage mellem dit bogmærke og dit næste forsøg. Gamle noter beskriver gamle udrulninger.

Notér den verificerede profil med dens endepunkt og metode, og gentag derefter undersøgelsen, når noden ændres, eller forbindelsen begynder at fejle. SoftEther-protokolspecifikationen er referencen for, hvad softwaren kan; nodens egen liste er referencen for, hvad den gør. Hold de to dokumenter adskilt, så bliver diagnosen kortere.