Publika VPN-agordo ĉesis funkcii? Legu la malsukcesan stadion

La profilo funkciis marde, kaj vendrede la kliento turniĝas tridek sekundojn kaj rezignas. Nenio ŝanĝiĝis en via maŝino. Ĝuste tio estas la punkto: elŝutita agordo priskribas unu gastiganton en unu momento, kaj la operatoro ĉe la alia fino havas neniun devon teni tiun priskribon vera. La tento estas komenci redakti sekurecajn agordojn ĝis la tunelo revenos. Ĝuste tiu instinkto kaŭzas, ke homoj finas per profilo kun malŝaltita atestila kontrolado, kio estas pli malbona ol tute ne havi tunelon.

La dosiero priskribas momenton, ne kontrakton

Agorda dosiero estas aro da asertoj: ĉi tiu gastigantnomo aŭskultas sur ĉi tiu pordo kun ĉi tiu protokolo, prezentas atestilon kongruan al ĉi tiu nomo, kaj akceptas ĉi tiujn legitimilojn. Kiam iu ajn el ili ĉesas esti vera, la dosiero estas malaktuala kaj la riparo apartenas al la operatora flanko de la limo, ne al viaj agordoj.

Publikaj listoj de nodoj tion evidentigas per sia naturo. Nodojn funkciigas volontuloj, ili aperas kaj malaperas, adresoj estas recikligataj kaj pordoj estas blokataj de la reto, malantaŭ kiu ili staras. La listo estas momenta bildo, kiu estas regenerata, kaj la kopio sur via disko estas foto de pli malnova momenta bildo.

Komercaj servoj ŝanĝiĝas pli malrapide sed ne neniam. Atestilaj aŭtoritatoj rotacias, aŭskultanto moviĝas de kunhavigita adreso al dediĉita, malnova protokolo estas retirita kaj nova ĉifra listo alvenas. Ĉiu el tiuj estas nevidebla ĝis via kliento provas konektiĝi kaj ricevas alian respondon ol tiu, kiun la dosiero atendas.

Legu la malsukcesan stadion antaŭ ol tuŝi agordon

La erarmesaĝo diras, kiu aserto rompiĝis, kaj ĉiu aserto havas tute alian riparon. Redakti ĉifrojn, kiam la gastigantnomo jam ne solviĝas, malŝparas posttagmezon kaj instruas al neniu ion ajn.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

La meza linio apartigas blokitan vojon de rompita manpremo, kaj la tria montras la eldonanton kaj la validigajn datojn de la atestilo, kiu fakte estas prezentata. Se tiu eldonanto ne estas la unu, kiun la profilo fiksigis, la atestilo ŝanĝiĝis, kaj neniu klienta opcio faros la malnovan fiksigon denove ĝusta.

Atestilaj kaj identecaj ŝanĝoj estas la silentaj

Plej multaj malsukcesoj anoncas sin. Identecaj ŝanĝoj ne, ĉar kliento, kiu fiksigas atestilan nomon, rifuzos tute bonan novan atestilon per mesaĝo, kiun multaj legas kiel programaran eraron. La tunelo estas en ordo. La fiksigo estas malaktuala.

Serĉu la identecajn opciojn antaŭ ol konkludi ion ajn:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Se la profilo portas enkonstruitan CA kaj la operatoro transiris al nova aŭtoritato, la malnova dosiero ne povas validigi la novan servilon. Anstataŭigi la CA-blokon per la publikigita de la operatoro estas legitima riparo. Forigi la kontrolan direktivon ne estas, kaj temas pri la samaj klavaj puŝoj kun tre malsama rezulto.

Klienta ĝisdatigo povas produkti la saman simptomon sen iu ajn ŝanĝo ĉe la operatoro. Opcioj, kiuj estis silente tolerataj, nun estas rifuzataj, aŭ malaktuala protokolo estas forigita. Tio estas kongrueca limo en via programaro, kaj indas testi duan profilon per la sama kliento antaŭ ol kulpi la servilon.

Nur la operatoro povas publikigi validan anstataŭaĵon

Kiam nodo malaperas, la anstataŭaĵo devas veni de la sama fonto, kiu publikigis la originalon. Profilo, kiu alvenas en rekta mesaĝo ĉar ĝi «uzas la saman servilnomon», estas nekontrolita agordo de nekonata partio, kaj ĝia enporto donas al tiu partio regadon super via enkursigo.

La kontrolo estas malmultekosta. Elprenu la nunan dosieron el la publikigita loko, komparu la finpunkton kaj la protokolon kun la listo, kaj konfirmu la fingrospuron de la CA-materialo anstataŭ fidi la dosiernomon:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Se la du haŝoj diferencas nur en blankaĵo, vi havas formatan ŝanĝon. Se ili diferencas en finpunktoj, la operatoro movis ion kaj la publikigita dosiero estas la aŭtoritato. Se la publikigita dosiero estas pli malnova ol tiu, kiun vi tenas, vi probable rigardas kaŝmemoron, kaj la malaktuala respondo sendos vin en la malĝusta direkto.

Retiru la malnovan enskribon kaj notu, kio okazis

Post kiam funkcianta anstataŭaĵo estas kontrolita, forigu la malnovan profilon anstataŭ teni ĝin kiel rezervon. Malaktuala enskribo, kiu duone konektiĝas, estas kaptilo: ĝi estos elektita dum paneo, ĝi malsukcesos malrapide, kaj la persono, kiu sencimigas, pasigos la unuajn dek minutojn ĉe la malĝusta dosiero.

Tenu mallongan registron ekster la agordo: la daton, la malnovan finpunkton, la malsukcesan stadion kaj kio anstataŭigis ĝin. Publikaj nodoj ŝanĝiĝas, kaj ses semajnojn poste la sama demando alvenas kun alia persono. Unu linio en nota dosiero respondas ĝin en sekundoj.

Se el unu reto ĉiu nodo malsukcesas same kaj el alia neniu, ĉesu redakti profilojn kaj rigardu la lokan vojon. Kaptita portalo, filtrita pordogamo aŭ interkapta prokura servilo produktos identajn erarojn ĉe nerilataj provizantoj, kaj ĝuste tiu ŝablono estas la sola signo, ke la problemo neniam estis la dosiero.