A nyilvános VPN-konfiguráció nem működik tovább? Olvasd el a hiba szakaszát

A profil kedden működött, pénteken pedig a kliens harminc másodpercig forog, majd feladja. A gépeden semmi sem változott. Pontosan ez a lényeg: a letöltött konfiguráció egy gazdagépet ír le egyetlen pillanatban, és a túloldali üzemeltetőnek nincs kötelezettsége arra, hogy ezt a leírást igaznak tartsa. A kísértés az, hogy elkezded szerkeszteni a biztonsági beállításokat, amíg az alagút újra fel nem jön. Ez az ösztön az oka annak, hogy az emberek végül kikapcsolt tanúsítvány-ellenőrzéssel futtatnak egy profilt, ami rosszabb, mint ha egyáltalán nem lenne alagút.

A fájl egy pillanatot ír le, nem szerződést

Egy konfigurációs fájl állítások halmaza: ez a gazdagépnév ezen a porton ezzel a protokollal figyel, ehhez a névhez illő tanúsítványt mutat be, és elfogadja ezeket a hitelesítő adatokat. Amint bármelyikük már nem igaz, a fájl elavult, és a javítás a határ üzemeltetői oldalára tartozik, nem a beállításaidba.

Nyilvános csomópontlisták természetüknél fogva nyilvánvalóvá teszik ezt. A csomópontokat önkéntesek üzemeltetik, megjelennek és eltűnnek, a címek újrahasznosulnak, a portokat pedig az a hálózat blokkolja, amely mögött vannak. A lista egy pillanatkép, amely újragenerálódik, a lemezeden lévő példány pedig egy régebbi pillanatkép fényképe.

A kereskedelmi szolgáltatások lassabban változnak, de nem soha. A tanúsító hatóságok váltakoznak, egy figyelő megosztott címről dedikált címre költözik, egy régi protokollt kivezetnek, és új titkosítási lista érkezik. Mindegyik láthatatlan addig, amíg a klienseid meg nem próbál csatlakozni, és nem a fájl által várt választól eltérő választ kap.

Olvasd el a hiba szakaszát, mielőtt bármely beállításhoz nyúlsz

A hibaüzenet megmondja, melyik állítás bukott meg, és minden állításnak teljesen más a javítása. A titkosítás szerkesztése, amikor a gazdagépnév már nem oldódik fel, egy délutánt pazarol el, és senkinek sem tanít semmit.

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

A középső sor elválasztja a blokkolt útvonalat a törött kézfogástól, a harmadik pedig a ténylegesen bemutatott tanúsítvány kibocsátóját és érvényességi dátumait mutatja. Ha ez a kibocsátó nem az, amelyet a profil rögzített, a tanúsítvány megváltozott, és semmilyen kliensoldali opció nem teszi újra helyessé a régi rögzítést.

A tanúsítvány- és identitásváltozások a csendesek

A legtöbb hiba bejelenti magát. Az identitásváltozások nem, mert az a kliens, amely rögzít egy tanúsítványnevet, egy teljesen jó új tanúsítványt is elutasít egy olyan üzenettel, amelyet sokan szoftverhibának olvasnak. Az alagút rendben van. A rögzítés elavult.

Keresd az identitás-beállításokat, mielőtt bármit is megállapítanál:

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

Ha a profil beágyazott CA-t hordoz, és az üzemeltető új hatóságra váltott, a régi fájl nem tudja érvényesíteni az új szervert. A CA-blokk lecserélése az üzemeltető által közzétettre jogos javítás. Az ellenőrzési direktíva törlése nem az, és ugyanazok a billentyűleütések egészen más eredménnyel.

Egy kliensfrissítés ugyanazt a tünetet okozhatja az üzemeltető bármilyen változása nélkül. A csendben megtűrt opciókat most elutasítják, vagy egy elavult protokollt eltávolítanak. Ez a szoftvered kompatibilitási korlátja, és érdemes egy második profilt kipróbálni ugyanazzal a klienssel, mielőtt a szervert hibáztatnád.

Csak az üzemeltető tehet közzé érvényes cserét

Amikor egy csomópont eltűnik, a cserének ugyanabból a forrásból kell jönnie, amely az eredetit közzétette. Az a profil, amely közvetlen üzenetben érkezik, mert „ugyanazt a szervernevet használja”, egy ismeretlen fél ellenőrizetlen konfigurációja, és az importálása annak a félnek adja az irányításod feletti ellenőrzést.

Az ellenőrzés olcsó. Szerezd be az aktuális fájlt a közzétett helyről, hasonlítsd össze a végpontot és a protokollt a listával, és erősítsd meg a CA-anyag ujjlenyomatát ahelyett, hogy a fájlnévben bíznál:

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

Ha a két hash csak szóközökben tér el, formázási változásod van. Ha a végpontokban térnek el, az üzemeltető valamit áthelyezett, és a közzétett fájl a mérvadó. Ha a közzétett fájl régebbi, mint a nálad lévő, valószínűleg gyorsítótárat nézel, és az elavult válasz rossz irányba küld.

Vond ki a régi bejegyzést, és jegyezd fel, mi történt

Miután egy működő csere ellenőrizve van, töröld a régi profilt, ahelyett hogy tartalékként megtartanád. Egy elavult bejegyzés, amely félúton csatlakozik, csapda: kiesés idején ki fogják választani, lassan fog meghiúsulni, és a hibakereső az első tíz percet a rossz fájllal tölti.

Vezess rövid feljegyzést a konfiguráción kívül: a dátumot, a régi végpontot, a hiba szakaszát és azt, hogy mi váltotta fel. A nyilvános csomópontok változnak, és hat hét múlva ugyanaz a kérdés érkezik egy másik emberrel. Egy sor egy jegyzetfájlban másodpercek alatt megválaszolja.

Ha az egyik hálózatból minden csomópont ugyanúgy meghiúsul, a másikból pedig egy sem, hagyd abba a profilok szerkesztését, és nézd meg a helyi útvonalat. Egy fogságba ejtő portál, egy szűrt porttartomány vagy egy elfogó proxy azonos hibákat produkál egymástól független szolgáltatóknál, és pont ez a minta az egyetlen jel, hogy a probléma soha nem a fájl volt.