Openbare VPN-konfigurasie werk nie meer nie? Lees die mislukkingstadium

Die profiel het Dinsdag gewerk, en Vrydag tol die kliënt dertig sekondes rond en gee op. Niks op jou masjien het verander nie. Dit is juis die punt: ’n afgelaai konfigurasie beskryf een gasheer op een oomblik, en die operateur aan die ander kant is nie verplig om daardie beskrywing waar te hou nie. Die versoeking is om sekuriteitsinstellings te begin verander totdat die tonnel weer opkom. Daardie instink is die rede waarom mense uiteindelik ’n profiel met sertifikaatverifikasie afgeskakel hardloop, wat erger is as om glad geen tonnel te hê nie.

Die lêer beskryf ’n oomblik, nie ’n kontrak nie

’n Konfigurasielêer is ’n stel bewerings: hierdie gasheernaam luister op hierdie poort met hierdie protokol, bied ’n sertifikaat aan wat by hierdie naam pas, en aanvaar hierdie geloofsbriewe. Wanneer enige een daarvan ophou waar wees, is die lêer verouderd en hoort die oplossing aan die operateur se kant van die grens, nie in jou instellings nie.

Openbare noduslyste maak dit uit hul aard duidelik. Nodusse word deur vrywilligers bedryf, hulle verskyn en verdwyn, adresse word hergebruik en poorte word geblokkeer deur watter netwerk ook al agter hulle sit. Die lys is ’n momentopname wat herbou word, en die kopie op jou skyf is ’n foto van ’n ouer momentopname.

Kommersiële dienste verander stadiger, maar nie nooit nie. Sertifikaatowerhede roteer, ’n luisteraar skuif van ’n gedeelde adres na ’n toegewyde een, ’n ou protokol word uit diens gestel en ’n nuwe syferlys kom in. Elkeen daarvan is onsigbaar totdat jou kliënt probeer konekteer en ’n ander antwoord kry as dié wat die lêer verwag.

Lees die mislukkingstadium voordat jy aan ’n instelling raak

Die foutboodskap sê watter bewering misluk het, en elke bewering het ’n heeltemal ander herstel. Om syfers te verander wanneer die gasheernaam nie meer opgelos word nie, mors ’n middag en leer niemand iets nie.

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

Die middelste reël skei ’n geblokkeerde pad van ’n stukkende handdruk, en die derde wys die uitreiker en geldigheidsdatums van die sertifikaat wat werklik aangebied word. As daardie uitreiker nie die een is wat die profiel vasgepen het nie, het die sertifikaat verander, en geen kliëntopsie sal die ou pen weer korrek maak nie.

Sertifikaat- en identiteitsveranderings is die stille

Die meeste mislukkings kondig hulself aan. Identiteitsveranderings doen dit nie, want ’n kliënt wat ’n sertifikaatnaam vaspen, sal ’n heeltemal goeie nuwe sertifikaat weier met ’n boodskap wat baie mense as ’n fout lees. Die tonnel is reg. Die pen is verouderd.

Soek die identiteitsopsies voordat jy enigiets aflei:

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

As die profiel ’n ingebedde CA dra en die operateur het na ’n nuwe owerheid geroteer, kan die ou lêer nie die nuwe bediener valideer nie. Om die CA-blok met die operateur se gepubliseerde een te vervang, is ’n legitieme oplossing. Om die verifikasieriglyn te skrap is dit nie, en dit is dieselfde toetsaanslae met ’n heel ander uitkoms.

’n Kliëntopgradering kan dieselfde simptoom veroorsaak sonder enige verandering by die operateur. Opsies wat stilweg geduld is, word nou verwerp, of ’n uitgefaseerde protokol word verwyder. Dit is ’n versoenbaarheidsbeperking in jou sagteware, en dit loon om ’n tweede profiel teen dieselfde kliënt te toets voordat jy die bediener blameer.

Net die operateur kan ’n geldige vervanging publiseer

Wanneer ’n nodus verdwyn, moet die vervanging van dieselfde bron kom wat die oorspronklike gepubliseer het. ’n Profiel wat per direkte boodskap aankom omdat dit “dieselfde bedienernaam gebruik”, is ’n ongeverifieerde konfigurasie van ’n onbekende party, en om dit in te voer gee daardie party beheer oor jou roetering.

Die toets is goedkoop. Haal die huidige lêer by die gepubliseerde ligging, vergelyk die eindpunt en die protokol met die lys, en bevestig die vingerafdruk van die CA-materiaal eerder as om die lêernaam te vertrou:

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

As die twee hashes net in witruimte verskil, het jy ’n formaatverandering. As hulle in eindpunte verskil, het die operateur iets geskuif en die gepubliseerde lêer is die gesag. As die gepubliseerde lêer ouer is as die een wat jy het, kyk jy waarskynlik na ’n kas, en die verouderde antwoord sal jou die verkeerde rigting in stuur.

Neem die ou inskrywing uit diens en teken op wat gebeur het

Sodra ’n werkende vervanging geverifieer is, skrap die ou profiel eerder as om dit as ’n terugval te hou. ’n Verouderde inskrywing wat halfpad konekteer is ’n lokval: dit sal tydens ’n onderbreking gekies word, dit sal stadig misluk, en die persoon wat ontfout sal die eerste tien minute aan die verkeerde lêer spandeer.

Hou ’n kort rekord buite die konfigurasie: die datum, die ou eindpunt, die mislukkingstadium en wat dit vervang het. Openbare nodusse verander, en ses weke later kom dieselfde vraag met ’n ander persoon daaraan. Een reël in ’n notaslêer antwoord dit in sekondes.

As elke nodus op dieselfde manier misluk vanaf een netwerk en nie een vanaf ’n ander nie, hou op om profiele te redigeer en kyk na die plaaslike pad. ’n Captive portal, ’n gefiltreerde poortreeks of ’n onderskeppende proxy sal identiese foute by onverwante verskaffers produseer, en daardie patroon is die enigste sein dat die probleem nooit die lêer was nie.