Melyik OpenVPN-példány használja valójában a PiVPN-profilodat?

A PiVPN szerverkonfigurációt és kliensprofilt ír, majd kilép; soha nem válik a forgalmadat szállító folyamattá. Ezért egy sikertelen kézfogás, a rossz végpontot tárcsázó kliens vagy az újraindítás után hibásan visszatérő szolgáltatás nem magyarázható a telepítő menüiből. Ezek a tünetek az éppen futó OpenVPN-démonhoz, az általa ténylegesen betöltött konfigurációhoz és a naplóhoz tartoznak, amelyre irányították. Négy csak olvasható parancs általában eldönti ezt, és egyik sem változtatja meg a tanúsítványaidat vagy a kulcsaidat.

A segédprogram és a démon különböző objektumok

A zavar könnyen megmagyarázható: egy könyvtár tartalmazza a segédprogram által létrehozott fájlt, a démon által olvasott fájlt, és néha mindkettő elavult másolatát. A segédprogram egy előkészítő szkript. Csomagokat telepít, egységfájlokat ír és kliensprofilt nyomtat, aztán a munkája véget ér. Ami marad, az egy bejegyzés a szolgáltatáskezelőben és egy parancssor.

Systemd-gazdagépen az aktív egységtől indulj a könyvtárlista helyett. A név a csomagolástól függ: a Debian és a Raspberry Pi OS lemezképei általában sablonpéldányt kínálnak, például openvpn-server@server, míg a régebbi telepítések openvpn@server használatával. Kérdezd meg a kezelőt, melyik fut, ahelyett hogy fájlnévből találgatnál.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Olvasd el a ExecStart= sort abban a kimenetben. Megnevezi a futtatható fájlt és azokat az opciókat, amelyeket a kezelő ténylegesen indít, beleértve bármely --config útvonalat; egy mellette lévő konfigurációs fájl, amelyre egyetlen parancs sem hivatkozik, nem része a futó alagútnak.

Kövesd a démon által feloldott konfigurációs láncot

OpenVPN nem szkennel könyvtárat beállítások után. Beolvassa a --config kapcsolóval átadott fájlt, követ minden benne lévő config direktívát, majd alkalmazza a parancssori opciókat. A 2.6-os kézikönyv leírja ezt a sorrendet, és ez számít, amikor két fájl nem ért egyet a port, az eszköz vagy a titkosítás kérdésében.

Először a tényleges hívást írasd ki, aztán nézd meg az identitást és az elérhetőséget eldöntő direktívákat. Mindkét parancs csak olvasható és biztonságos egy élő szerveren, bár a második olyan útvonalakat nyomtat, amelyeket talán nem szeretnél egy nyilvános jegyben.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Egy .ovpn fájl a home könyvtárban kliens-összetevő. A szerver démon soha nem olvassa, ezért annak a fájlnak a szerkesztése egy szerveroldali kézfogáshiba javításához nem vezet semmihez.

A beszúrások a másik csapda. Egy config sor behúz egy második fájlt, amelynek opciói ezen a ponton feldolgozódnak, így egy későbbi egyértékű direktíva felülírhatja azt, amit a fő fájl látszólag mond. Ha a látható fájl helyesnek tűnik, és a démon mégis másképp viselkedik, olvasd el a beszúrt fájlt, mielőtt bármit változtatnál.

A naplót a folyamathoz illeszd, ne az általad emlékezett hibához

Két naplócél gyakori, és csak az egyik a journal. log-append beállításával a démon abba a fájlba ír, és a journal az indítási sorokon túl keveset őriz. Enélkül a journalctl az események forrása.

journalctl -u openvpn-server@server -n 80 --no-pager

Kapcsolj össze egy kapcsolódási kísérletet egy időablakkal. Jegyezd fel a kliens végpontját, majd olvasd el a szervereseményeket ugyanazokból a másodpercekbe. Az a TLS-kézfogás, amely soha nem ér el a tanúsítványcseréig, elérhetőségi vagy protokoleltérési problémára utal, míg a hitelesítés elutasítása akkor érkezik, amikor az alagút paraméterei már megállapodtak.

Egy régi naplóbejegyzés semmit nem bizonyít egy öt perccel ezelőtt letöltött profilról. Generáld újra a kliensfájlt, kapcsolódj egyszer, és csak azokat a sorokat olvasd, amelyek ez alatt a kísérlet alatt jelentek meg.

Az első konkrét hibát jegyezd fel, ne az utolsó általánosat. Egy bind-hiba, egy megválaszolatlan külső csere, egy tanúsítvány-elutasítás és egy fiókelutasítás mind más-más réteghez küld, és a végén egy időtúllépés gyakran elrejti a fölötte lévő hasznos eseményt.

Az alagút újraépítése nem diagnosztikai lépés

A csábító rövidítés egy második, egyszerűbb alagút felállítása: statikus kulcs, nincs tanúsítvány, nincs további hitelesítés. Gyakran csatlakozni fog, és csak azt bizonyítja, hogy két gazdagép tud UDP-t vagy TCP-t átengedni egymás között. Semmit nem mond arról, miért sikertelen a tanúsítványokkal hitelesített telepítés, és csendesen lecseréli a biztonsági modellt, amelyet meg kellett volna tartanod.

Ugyanez vonatkozik a tls-auth vagy a tls-crypt kikapcsolására, a verify-x509-name lazítására, vagy egy második tényező elhagyására a zöld állapotért. Az az alagút, amely azért csatlakozik, mert eltávolították az ellenőrzést, más rendszer, nem javított.

Egyetlen korlátozott változtatást hajts végre azon a rétegen, amelyet a napló megnevezett, indítsd újra ugyanazt az egységet, és ismételd meg az egyetlen kapcsolódási kísérletet. Ez őszintén tartja az összehasonlítást, és olyan változtatást hagy, amelyet visszavonhatsz.

Mit adj át a következő embernek

Írj fel négy tényt, amíg még a birtokodban vannak: az OpenVPN verzióját innen: openvpn --version, az aktív egységet, a konfigurációs láncot a beszúrásaival, és az egy kísérletet lefedő naplóablakot. Ez a négy reprodukálható esetté alakít egy homályos panaszt.

Szerkeszd ki megosztás előtt. A privát kulcsok, a auth-user-pass fájlok, a statikus kulcs anyaga és a teljes klienscsomagok nem valók egy jegybe; az opciónevek és a lánc alakja általában elég egy második szem párnak.

Ha a lánc sértetlen, és a napló még mindig a hálózatra mutat, a következő lépés az ügyfél és a szerver közötti útvonal, nem egy újabb telepítés. Ez az a része a történetnek, amely soha nem a segédprogramé volt.