journalctl pre protokoly VPN: ktorá jednotka vlastní pripojenie?

Začnite jednotkou systemd, ktorá VPN pripojenie skutočne vlastní, nie príkazom pre protokol, ktorý si pamätáte. Priama služba OpenVPN, jednotka wg-quick a profil NetworkManager umiestňujú svoje užitočné správy do rôznych jednotiek a dopyt na nesprávnu jednotku vráti prázdny výsledok, ktorý vyzerá ako ticho. Porovnajte tri bežných vlastníkov, zúžte okno a potom čítajte fázy poporiadku.

Porovnajte troch bežných vlastníkov

Klientska služba OpenVPN je zvyčajne inštančná jednotka pomenovaná podľa profilu, napríklad [email protected]. Jej správy zahŕňajú cestu ku konfigurácii, spracovanie volieb, TLS handshake a inštaláciu trás, ktorú klient vykonáva.

Jednotka wg-quick je zámerne tichšia. Konfigurácia rozhrania prebehne pri štarte, handshake spracúva jadro a rutinné obnovy kľúčov sa predvolene nezapisujú, takže wg show je často informatívnejšie ako protokol. Tento rozdiel je dôležitý, keď porovnávate protokol, ktorý zaznamenáva vyjednávanie, s takým, ktorý to nerobí.

NetworkManager vlastní profily, ktoré vytvoril, a jeho správy žijú pod NetworkManager.service aj vtedy, keď je základný plugin pomocník VPN. Pýtajte sa aj správcu, aj pomocnej jednotky, keď sa profil spravuje týmto spôsobom.

Zúžte dopyt na jednu jednotku a jedno okno

Pýtajte sa jednotky, ktorú ste určili, a ohraničte čas pokusom, ktorý skúmate. Jeden deň zvyčajne stačí a kratšie okno je lepšie, keď sa stroj často pripája znova.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Overte nainštalovaný názov, kým dopytu uveríte. Distribučné balíčky jednotky premenúvajú a profil, ktorý existuje ako súbor, nemusel byť nikdy povolený ako služba. Ak jednotka neexistuje, prázdny protokol vám hovorí o nasadení, nie o tuneli.

Prečítajte prvú neúspešnú fázu

Čítajte udalosti v poradí, v akom nastávajú: hľadanie koncového bodu, prenos, identita, overovanie, inštalácia trás a neskoršie zlyhanie aplikácie. Prvé konkrétne zlyhanie je to, ktoré stojí za vyšetrenie, pretože všetko po ňom je následok.

Služba, ktorá úspešne štartuje, nedokazuje, že každý potrebný zdroj je dostupný. Slučka opätovného pripojenia môže vytvoriť niekoľko samostatných vyjednávaní, preto držte názov profilu a čas pokusu pri udalostiach a čítajte jeden pokus namiesto zlúčeného prúdu. Jediný pokus je postupnosť s príčinou, kým zlúčený prúd je stena opakovaných riadkov. Napíšte prvú chybu do tiketu, kým budete čítať ďalej.

Nemiešajte neúspešnú službu s ručným klientom

Ak ste klienta spustili ručne po tom, čo služba zlyhala, jeho výstup ide inam a jeho správanie sa môže líšiť. Zachyťte nový výsledok od toho istého vlastníka a tej istej požiadavky po podporovanej oprave, aby porovnanie ukázalo, čo sa zmenilo, namiesto miešania dvoch rôznych programov.

Nemeňte pôvodné časové značky, aby sa zladili s iným hostiteľom. Poznačte časové pásmo a známy rozdiel hodín oddelene, pretože časová os, ktorú ste upravili, už nie je dôkaz.

Zdieľajte výňatok, nie export

Záznamy protokolu môžu obsahovať používateľské mená, adresy koncových bodov, súkromnú topológiu a informácie o prostredí skriptu. Prezrite si skutočný výňatok a citlivé údaje začiernite, namiesto zverejnenia úplného neobmedzeného exportu. Citujte riadky, ktoré dokazujú zlyhanie, a zvyšok zhrňte. Krátky skontrolovaný výňatok sa dá ľahšie použiť ako súbor, ktorý nikto nečíta.

Pošlite úzke okno, názov jednotky a prvú neúspešnú fázu a povedzte, čo ste už vylúčili. Manuál systemd journalctl dokumentuje selektory a voľby výstupu, ak potrebujete formu, ktorú verzia distribúcie podporuje.