Tempa limo de VPN-konekto: DNS, transporto, intertraktado aŭ ensaluto
Templimo signifas nur, ke limo pasis. Komparu kvar etapojn, nomresolvon, transporton, intertraktadon kaj ensaluton, por vidi, kiu lasta finiĝis.
“La konekto tempis” estas la plej malpreciza eraro, kiun VPN-kliento povas presi. Ĝi signifas, ke unu operacio maltrafis sian limon, kaj ĉiu etapo de nomresolvo ĝis la ensaluta respondo havas limon. Klientoj, kiuj montras nur la finan mesaĝon, igas la etapojn aspekti identaj, do homoj plialtigas la templimon, ŝanĝas la pordon kaj reinstalas la profilon, en tiu ordo, sen lerni ion. Kompari la etapojn estas pli rapida: ĉiu malsukcesas en alia loko, kaj ĉiu malsukceso lasas alian specon de pruvo.
Kvar etapoj, kvar malsamaj malsukcesoj
La sinsekvo estas fiksa eĉ kiam la kliento kaŝas ĝin: la nomo devas esti solvita, transporto devas esti starigita al la rezulta adreso, la protokolo devas intertrakti siajn parametrojn kaj ŝlosilojn, kaj la konto devas esti aŭtentigita. La gvidilo de OpenVPN pri solvado de konektaj problemoj sekvas la saman ordon por sia propra kliento, kaj la aliaj sekvas ĝin proksime. Templimo ĉe la dua etapo kaj templimo ĉe la kvara havas nenion komunan krom la vorto sur la ekrano.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
Legas la protokolon por la lasta linio, kiu indikas progreson, ne por la lasta linio antaŭ la eraro. Plej multaj klientoj presas ion kiel solvitan adreson, starigitan ingon, komencitan manpremon aŭ aŭtentigan peton, kaj la etapo, kiu sekvas tiun linion, estas la tempinta.
Nomresolvo malsukcesas antaŭ ol io ajn estas kontaktita
Se la finpunkto neniam solviĝas, la kliento havas nenion, al kio konekti, kaj neniu transporta laboro okazis. Tiu malsukceso kutime estas tuja anstataŭ plena templimo, kio estas la plej malmultekosta maniero distingi ĝin de la cetero. Testu la nomon per la sistema solvilo kaj per dua solvilo, kaj komparu la du respondojn antaŭ ol konkludi, ke la servilo estas haltinta.
Malnova adreso kopiita el forumafiŝo estas ofta kaŭzo de templimo, kiu aspektas kiel servila problemo, ĉar la adreso nun apartenas al io alia aŭ al nenio. Uzu la aktualan profilon de la funkciiganto anstataŭ anstataŭigi adreson, kiu iam funkciis. Mankanta ping-respondo ne estas pruvo en iu ajn direkto: multaj finpunktoj forĵetas ICMP dum ili tute bone servas.
Transporta starigo atendas paketon, kiu ne venos
Kiam DNS estas en ordo kaj la kliento tamen bruligas la tutan templimon, la transporta tavolo estas la suspektato. Ĉe TCP vi povas testi la pordon rekte; Test-NetConnection en Vindozo aŭ nc -vz en Linukso diras al vi, ĉu io akceptas la konekton, kaj tio pli utilas ol ping. Ĉe UDP vi ne povas testi same, ĉar en tiu tavolo ne estas manpremo por fini, kaj tiu malsimetrio kaŭzas multajn erarajn konkludojn.
Tio, kion TCP-testo pruvas, estas limigita: servo akceptanta pordon 443 ne nepre estas la VPN-aŭskultanto, kaj finpunkto nur-UDP havas neniun TCP-pordon por akcepti ion ajn. Rekontroli profilon de UDP al TCP ne kreas aŭskultanton aliflanke; ĝi nur ŝanĝas, kion via kliento atendas. Se la reto filtradas la protokolon, la ŝanĝo produktas alian templimon ĉe la sama etapo.
Kaptitaj portaloj meritas sian propran kontrolon ĉe tiu etapo. Ĝis la portalo rajtigos la aparaton, elira trafiko iras al la portalo kaj la tunela provo simple pendas. Unue finu la portalon en retumilo, poste reprovu, kaj ne ŝanĝu la profilon dum la portalo ankoraŭ pritraktatas.
Intertraktado kaj ensaluto signifas, ke la servilo respondis
Post kiam la tunelo atingas la servilon, la kliento komencas manpremon kaj la eraro ŝanĝas karakteron. Halto ĉi tie temas pri kongruo, ne pri atingeblo: malkongruaj protokolversioj, ĉifra aŭ datenkanala agordo, kiun la alia flanko ne akceptos, aŭ profilo, kiu atendas funkcion, kiun la servilo ne ofertas. OpenVPN movis siajn intertraktaĵajn defaŭltojn inter ĉefaj versioj sufiĉe ofte, ke profilo skribita por unu generacio povas atingi la servilon kaj tamen ne ekfunkcii.
Aŭtentigo estas la lasta etapo kaj la plej facile mislega. Rifuzo eksplicita estas respondo, kio signifas, ke la vojo funkcias kaj la problemo estas la identeco, la atestilo aŭ la konta stato. Retumila unuopa ensaluta fluo estas tria kazo: la kliento atendas agon, kiun vi ne faris, aŭ retumilon, kiun ĝi ne povas lanĉi, kaj nenio venos ĝis vi finos tiun paŝon.
Komparu la pruvojn antaŭ ol ŝanĝi la reprovon
Tenu la aparaton kaj la profilon fiksitaj kaj ŝanĝu unu aĵon samtempe, komencante per la reto. Se la sama profilo konektiĝas per telefona poŝa aliro kaj tempas ĉe la hotela Wi-Fi, la vojo estas la variablo, ne la servilo. Se ĝi malsukcesas ĉie, la profilo aŭ la finpunkto estas la variablo. Se ĝi malsukcesas nur je unu horo de la tago, kaptu la horstampon kaj komparu ĝin kun servilflankaj eventoj antaŭ ol supozi ion pri ŝarĝo.
Por servo, kiun vi administras, la decida komparo estas, ĉu la provo entute alvenas. Konekto, kiu atingas la aŭskultanton kaj poste haltas, apartenas al la intertrakta etapo; unu, kiu neniam aperas en la vido de la aŭskultanto, estas transporta aŭ solva problemo, kaj nenia agordado de reprovoj movos ĝin. Servilaj protokoloj ankaŭ apartigas rifuzitan ensaluton de silenta forĵeto, kio estas la diferenco inter identeca korekto kaj fajroŝirma korekto.
Notu la klientan version, la profilan nomon, la provan tempon kun ĝia horzono kaj la unuan utilan eraron anstataŭ la finan malkonektan linion. Forigu ŝlosilojn kaj identigilportan materialon antaŭ ol dividi la eltiraĵon. Poste faru unu signifan korekton kaj reprovu, ĉar pli longa limo nur helpas la dokumentitan malrapidan operacion, kaj ĝi faras nenion por malĝusta adreso aŭ blokita pordo.