Kiujn protokolojn ĉi tiu publika VPN-nodo vere ofertas?

La programaro subtenas ĝin, do la nodo ofertas ĝin. Tiu konkludo estas erara sufiĉe ofte por esti regulo: SoftEther-starigo povas ebligi ajnan subaron de siaj kongruaj konektometodoj, kaj publika nodo estas starigo kun posedanto kaj agordo. Kun kio vi povas konektiĝi dependas de tiu nodo, ne de la funkciolisto de la projekto, kiun ĝi rulas. Ĝuste en la breĉo inter la du vivas plej multaj biletoj „la protokolo estas difektita“.

Kion la projekta listo vere promesas

La protokolaj funkcioj de la projekto priskribas, kion la servilo kapablas. Donita nodo ebligas kelkajn el tiuj aŭskultantoj kaj ne aliajn, kaj la operatoro povas ŝanĝi tiun aron sen tuŝi la programversion. Du nodoj en la sama konstruo do kondutas malsame, kaj profilo, kiu funkcias kontraŭ unu, pruvas nenion pri la sekva celo. La propra listo de la nodo superas la projektan paĝon, kiam vi elektas, kien konektiĝi.

Legu la liston kiel kvin kampojn, ne kiel menuon: finpunkto, pordo, transporto, protokola familio kaj aŭtentiga metodo. Publika nodo, kiu reklamas SSTP rakontis al vi pri aŭskultanto sur pordo; ĝi ne diris al vi, kiun atestilon ĝi prezentas aŭ ĉu via konto funkcias tie. Kompari tiujn kvin kampojn kun via profilo estas pli rapida ol iu ajn kvanto da reinstalado de la kliento, kaj ĝi produktas skriban atendo, kiun vi povas testi poste.

Aguordigu la profilon al la finpunkto, kiun ĝi nomas

Indiĝena SoftEther-enskribo ne estas aŭtomate OpenVPN-agordo, eĉ kiam ambaŭ aperas sur unu provizanta paĝo sub unu titolo. Kiam nodo publikigas kaj TCP- kaj UDP-aŭskultanton por OpenVPN, traktu ilin kiel du finpunktojn: profilo redaktita de unu al la alia montras al aŭskultanto, kiun neniu ebligis. La transporta etikedo en la dosiero estas parto de la adreso, ne kosmetika agordo.

Tio, ke la kliento akceptas importitan dosieron, pruvas, ke la dosiero analiziĝas. Ĝi diras nenion pri tio, ĉu fora aŭskultanto atendas ĉe la alia fino, kaj tial la unua konektoprovo estas la vera testo. Komparu la forecan linion de la profilo kun la anoncita gastiganto kaj pordo de la nodo antaŭ ol kulpigi la protokolon.

Sondi la etapon, kiu malsukcesas

Gastiganto, kiu respondas al reta trafiko, povas ankoraŭ manki la celatan VPN-servon, kaj gastiganto, kiu rifuzas unu protokolon, ne nepre estas malsupra por ĉiuj. Tiuj du eraroj sendas homojn en kontraŭajn direktojn la saman posttagmezon. Unu postkuras fajromuron, kiu estas en ordo; la alia reinstalas klienton, kiu neniam estis la problemo. Sondi ĉiun vojon aparte, por ke la respondo priskribu unu aŭskultanton anstataŭ la tutan gastiganton.

Ĉi tiuj kvin kontroloj kovras la oftajn metodojn de publikaj nodoj. Plenumu ilin el la sama reto, kiun uzas la kliento, ĉar filtrita pordo aspektas idente al mankanta aŭskultanto de malproksime.

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

Ligu ĉiun observitan eraron al ĝia vico antaŭ ol ŝanĝi ion ajn. TLS-identeca malsukceso pruvas, ke la aŭskultanto ekzistas, do reverki la profilon al alia protokolo forĵetus funkciantan pruvon. Rifuzita konekto pruvas nur, ke ĉi tiu pordo ne respondis, kio estas multe pli mallarĝa aserto ol „la nodo ne subtenas OpenVPN“.

Konservu la eraron antaŭ ol ŝanĝi ion ajn

Notu la precizan rezulton: tempolimo, atestila identeca malsukceso, konta malakcepto kaj aplikaĵnivela rifuzo estas kvar malsamaj rezultoj. Nur la unua temas pri nehavebla protokolo, kaj nur la lasta temas pri permeso post sukcesa konekto. Restarigi la klienton aŭ ŝanĝi protokolojn detruas tiun distingon, ĉar la sekva malsukceso alvenas kun alia historio kaj sen bazlinio por kompari.

Ne malfortigu la kontroladon por igi nekongruan profilon ŝajni funkcii. Malŝaltita atestila kontrolo transformas klaran identecan malsukceson en konekton al io, al kio vi ne intencis atingi, kaj la rezulta sukceso estas pli malbona ol la origina eraro, ĉar ĝi kaŝas, kiu etapo estis malĝusta.

Rekontrolu por ĉiu nodo, ĉiufoje

La indiĝenaj elektoj SSL, OpenVPN, L2TP/IPsec kaj SSTP sur publika noda listo priskribas la agordon de tiu nodo en tiu momento. La sama programaro aliloke povas prezenti alian aron, kaj provizanto povas retiri aŭskultanton inter via legosigno kaj via sekva provo. Malnovaj notoj priskribas malnovajn starigojn.

Notu la kontrolitan profilon kun ĝia finpunkto kaj metodo, poste ripetu la sondadon, kiam la nodo ŝanĝiĝos aŭ la konekto komencos malsukcesi. La specifo de la SoftEther-protokolo estas la referenco por tio, kion la programaro povas fari; la propra listo de la nodo estas la referenco por tio, kion ĝi faras. Tenu la du dokumentojn aparte kaj la diagnozo pli mallongiĝos.