Watter protokolle bied hierdie openbare VPN-nodus werklik aan?
Dat bedienerprogrammatuur 'n protokol ondersteun, beteken nie dat hierdie nodus dit geaktiveer het nie. Kontroleer die eindpunt, die profiel en die fase wat werklik faal.
Die programmatuur ondersteun dit, dus bied die nodus dit aan. Daardie afleiding is dikwels genoeg verkeerd om 'n reël te wees: 'n SoftEther-ontplooiing kan enige subset van sy versoenbare verbindingsmetodes aktiveer, en 'n openbare nodus is 'n ontplooiing met 'n eienaar en 'n konfigurasie. Waarmee jy kan verbind, hang van daardie nodus af, nie van die kenmerke-lys van die projek wat dit gebruik nie. Die gaping tussen die twee is waar die meeste “die protokol is stukkend”-kaartjies werklik woon.
Wat die projeklys werklik belowe
Die projek se protokolfunksies beskryf waartoe die bediener in staat is. 'n Gegewe nodus aktiveer sommige van daardie luisteraars en nie ander nie, en die operateur kan daardie stel verander sonder om die sagteware-weergawe aan te raak. Twee nodusse op dieselfde bouwerk gedra hulle dus anders, en 'n profiel wat teen een werk, bewys niks oor die volgende teiken nie. Die nodus se eie lys oortref die projekblad wanneer jy kies waar om te verbind.
Lees die lys as vyf velde, nie as 'n spyskaart nie: eindpunt, poort, vervoer, protokolfamilie en verifikasiemetode. 'n Openbare nodus wat SSTP adverteer, het jou van 'n luisteraar op 'n poort vertel; dit het jou nie vertel watter sertifikaat dit voorlê, of jou rekening daar werk nie. Om daardie vyf velde teen jou profiel te vergelyk, is vinniger as enige hoeveelheid herinstallasie van die kliënt, en dit lewer 'n geskrewe verwagting wat jy later kan toets.
Pas die profiel by die eindpunt wat dit noem
'n Inheemse SoftEther-inskrywing is nie outomaties 'n OpenVPN-konfigurasie nie, selfs wanneer albei op een verskafferblad onder een opskrif verskyn. Wanneer 'n nodus beide 'n TCP- en 'n UDP-luisteraar vir OpenVPN publiseer, behandel hulle as twee eindpunte: 'n profiel wat van een na die ander geredigeer is, wys na 'n luisteraar wat niemand geaktiveer het nie. Die vervoeretiket in die lêer is deel van die adres, nie 'n kosmetiese instelling nie.
Dat die kliënt 'n ingevoerde lêer aanvaar, bewys dat die lêer parseer. Dit sê niks oor of 'n afgeleë luisteraar aan die ander kant wag nie, en daarom is die eerste verbindingspoging die werklike toets. Vergelyk die profiel se remote-lyn met die nodus se geadverteerde gasheer en poort voordat jy die protokol blameer.
Toets die fase wat faal
'n Gasheer wat webverkeer beantwoord, kan steeds die beoogde VPN-diens ontbreek, en 'n gasheer wat een protokol weier, is nie noodwendig vir almal af nie. Daardie twee foute stuur mense op dieselfde middag in teenoorgestelde rigtings. Een jaag 'n brandmuur wat heeltemal reg is; die ander herinstalleer 'n kliënt wat nooit die probleem was nie. Toets elke pad afsonderlik sodat die antwoord een luisteraar beskryf eerder as die hele gasheer.
Hierdie vyf kontroles dek die algemene metodes van openbare nodusse. Voer hulle uit vanaf dieselfde netwerk wat die kliënt gebruik, want 'n gefiltreerde poort lyk van ver af identies aan 'n ontbrekende luisteraar.
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| Resultaat | Fase | Wat dit uitsluit |
|---|---|---|
| Verbinding geweier of tyd uit | Vervoer | Luisteraar afwesig, gefiltreer of verkeerde poort |
| TLS-handdruk of identiteitsfout | Sertifikaat | Protokolbeskikbaarheid; die luisteraar het geantwoord |
| AUTH_FAILED of rekeningverwerping | Verifikasie | Die eindpunt; geloofsbriewe is die probleem |
| UDP 500 en 4500 stil | IPsec-onderhandeling | ESP en L2TP word voor verifikasie geblok |
Koppel elke waargenome fout aan sy ry voordat jy enigiets verander. 'n TLS-identiteitsfout bewys die luisteraar bestaan, so om die profiel na 'n ander protokol te herskryf, sou werkende bewyse weggooi. 'n Geweierde verbinding bewys net dat hierdie poort nie geantwoord het nie, wat 'n baie smaller stelling is as “die nodus ondersteun nie OpenVPN nie”.
Bewaar die fout voordat jy enigiets verander
Skryf die presiese resultaat neer: 'n tydverstryking, 'n sertifikaat-identiteitsfout, 'n rekeningverwerping en 'n weiering op toepassingsvlak is vier verskillende uitkomste. Net die eerste een gaan oor 'n protokol wat onbeskikbaar is, en net die laaste een gaan oor toestemming ná 'n suksesvolle verbinding. Om die kliënt te herstel of protokolle te ruil, vernietig daardie onderskeid, want die volgende fout kom met 'n ander geskiedenis en geen basislyn om teen te vergelyk nie.
Moet nie verifikasie verswak om 'n onversoenbare profiel te laat werk nie. 'n Gedeaktiveerde sertifikaatkontrole verander 'n duidelike identiteitsfout in 'n verbinding na iets wat jy nie bedoel het om te bereik nie, en die gevolglike sukses is erger as die oorspronklike fout omdat dit verberg watter fase verkeerd was.
Hercontroleer per nodus, elke keer
Die inheemse SSL-, OpenVPN-, L2TP/IPsec- en SSTP-keuses op 'n openbare noduslys beskryf daardie nodus se konfigurasie op daardie oomblik. Dieselfde sagteware elders kan 'n ander stel bied, en 'n verskaffer kan 'n luisteraar aftree tussen jou boekmerk en jou volgende poging. Ou notas beskryf ou ontplooiings.
Teken die geverifieerde profiel met sy eindpunt en metode aan, en herhaal dan die toets wanneer die nodus verander of die verbinding begin faal. Die SoftEther-protokolspesifikasie is die verwysing vir wat die sagteware kan doen; die nodus se eie lys is die verwysing vir wat dit doen. Hou die twee dokumente apart en die diagnose word korter.