Vilka protokoll erbjuder den här offentliga VPN-noden egentligen?
Att serverprogramvaran stöder ett protokoll betyder inte att den här noden har aktiverat det. Kontrollera slutpunkten, profilen och det steg som faktiskt misslyckas.
Programvaran stöder det, alltså erbjuder noden det. Slutsatsen är fel tillräckligt ofta för att vara en regel: en SoftEther-distribution kan aktivera vilken delmängd som helst av sina kompatibla anslutningsmetoder, och en offentlig nod är en distribution med en ägare och en konfiguration. Vad du kan ansluta till beror på den noden, inte på funktionslistan för projektet den kör. Det är i gapet mellan de två som de flesta «protokollet är trasigt»-ärenden faktiskt bor.
Vad projektlistan egentligen lovar
Projektets protokollfunktioner beskriver vad servern är kapabel till. En given nod aktiverar några av dessa lyssnare och inte andra, och operatören kan ändra den mängden utan att röra programvaruversionen. Därför beter sig två noder på samma bygge olika, och en profil som fungerar mot den ena bevisar ingenting om nästa mål. Nodens egen lista väger tyngre än projektsidan när du väljer var du ska ansluta.
Läs listan som fem fält, inte som en meny: slutpunkt, port, transport, protokollfamilj och autentiseringsmetod. En offentlig nod som annonserar SSTP har berättat om en lyssnare på en port; den har inte berättat vilket certifikat den presenterar eller om ditt konto fungerar där. Att jämföra de fem fälten med din profil går snabbare än någon mängd ominstallation av klienten, och det ger en skriftlig förväntan som du kan testa senare.
Anpassa profilen till den slutpunkt den namnger
En inbyggd SoftEther-post är inte automatiskt en OpenVPN-konfiguration, även när båda visas på en leverantörssida under en rubrik. När en nod publicerar både en TCP- och en UDP-lyssnare för OpenVPN, behandla dem som två slutpunkter: en profil som redigerats från den ena till den andra pekar på en lyssnare som ingen aktiverat. Transportetiketten i filen är en del av adressen, inte en kosmetisk inställning.
Att klienten accepterar en importerad fil fastställer att filen kan parsas. Det säger ingenting om huruvida en fjärrlyssnare väntar i andra änden, och därför är det första anslutningsförsöket det verkliga testet. Jämför profilens remote-rad med nodens annonserade värd och port innan du skyller på protokollet.
Undersök steget som misslyckas
En värd som svarar på webbtrafik kan fortfarande sakna den avsedda VPN-tjänsten, och en värd som avvisar ett protokoll är inte nödvändigtvis nere för alla. De två felen skickar folk i motsatta riktningar samma eftermiddag. Den ene jagar en brandvägg som är i ordning; den andre installerar om en klient som aldrig var problemet. Undersök varje väg separat, så att svaret beskriver en lyssnare och inte hela värden.
Dessa fem kontroller täcker de vanliga metoderna för offentliga noder. Kör dem från samma nätverk som klienten använder, eftersom en filtrerad port ser identisk ut med en saknad lyssnare på avstånd.
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 | Steg | Vad det utesluter |
|---|---|---|
| Anslutning nekad eller tidsgräns | Transport | Lyssnare saknas, är filtrerad eller fel port |
| TLS-handskaknings- eller identitetsfel | Certifikat | Protokollets tillgänglighet; lyssnaren svarade |
| AUTH_FAILED eller kontonekning | Autentisering | Slutpunkten; problemet är inloggningsuppgifterna |
| UDP 500 och 4500 tysta | IPsec-förhandling | ESP och L2TP är blockerade före autentisering |
Koppla varje observerat fel till dess rad innan du ändrar något. Ett TLS-identitetsfel bevisar att lyssnaren finns, så att skriva om profilen till ett annat protokoll skulle kasta bort fungerande bevis. En nekad anslutning bevisar bara att den här porten inte svarade, vilket är ett mycket snävare påstående än «noden stöder inte OpenVPN».
Bevara felet innan du ändrar något
Skriv ner det exakta resultatet: en tidsgräns, ett certifikatidentitetsfel, en kontonekning och en nekning på programnivå är fyra olika utfall. Bara det första handlar om ett protokoll som inte är tillgängligt, och bara det sista handlar om behörighet efter en lyckad anslutning. Att återställa klienten eller byta protokoll förstör den distinktionen, eftersom nästa fel kommer med en annan historia och utan en baslinje att jämföra med.
Försvaga inte verifieringen för att få en inkompatibel profil att se ut som om den fungerar. En avstängd certifikatkontroll förvandlar ett tydligt identitetsfel till en anslutning till något du inte avsåg att nå, och den resulterande framgången är värre än det ursprungliga felet eftersom den döljer vilket steg som var fel.
Kontrollera igen per nod, varje gång
De inbyggda valen SSL, OpenVPN, L2TP/IPsec och SSTP på en lista över offentliga noder beskriver den nodens konfiguration i det ögonblicket. Samma programvara någon annanstans kan presentera en annan uppsättning, och en leverantör kan dra tillbaka en lyssnare mellan ditt bokmärke och ditt nästa försök. Gamla anteckningar beskriver gamla distributioner.
Anteckna den verifierade profilen med dess slutpunkt och metod, och upprepa sedan undersökningen när noden ändras eller anslutningen börjar misslyckas. SoftEther-protokollspecifikationen är referensen för vad programvaran kan; nodens egen lista är referensen för vad den gör. Håll de två dokumenten åtskilda och diagnosen blir kortare.