OpenVPN startar inte: läs första raden, inte konfigurationen

En VPN som dör under första sekunden är ett annat djur än en som ansluter och sedan misslyckas, och det vanliga misstaget är att behandla dem likadant. Här finns ingen handskakning, inget certifikatutbyte och ingen väg att granska. En rad i journalen avgör vilken av flera orelaterade reparationer som gäller, och att hoppa över den kostar en eftermiddag med att redigera en konfiguration som aldrig lästes. Läs den raden först.

Dit kommer du med tre skrivskyddade kommandon: journalctl -u openvpn@server -b --no-pager först, systemctl status openvpn@server sedan och ss -lunp för UDP-lyssnarna och deras ägare.

Första raden väljer grenen

En portkonflikt och en saknad binärfil dödar båda starten inom en sekund och lämnar olika första rader. Ett meddelande om redan använd adress namnger porten; en saknad körbar fil namnger en sökväg som inte längre finns; ett misslyckat villkor eller en saknad konfigurationsfil namnger filen. Dessa tre leder till olika reparationer och ingen av dem blir bättre av att installera om klienten. Kopiera det första felet till dina anteckningar innan du kör något annat.

Se upp för återförsöksloopen som döljer den ursprungliga raden. En enhet med en omstartsprincip kan begrava det första felet under ett dussin identiska, så journalctl -b filtrerat på enheten och läst från början slår svansen.

Vem mer håller port 1194

Boven är vanligtvis inte en andra server som någon medvetet konfigurerade. Räkna med en handstartad klient som fortfarande lever i en annan terminal, en andra profil som råkade välja samma port, eller ett leverantörspaket vars egen tunnel håller 1194. Socketägaren syns i ss -lunp; mata det PID:t till systemctl status för att ta reda på om en enhet är ansvarig. Ta ner den via sin egen kontrollväg i stället för med en signal.

En signal till en enhetshanterad process utlöser vanligtvis en omstart, och samma fel dyker upp strax igen och ser ut som ett nytt problem. Använd systemctl stop för en enhet, paketets egen servicekommando för en leverantörsinstallation och en signal bara för något du startat för hand i det skalet.

Kvarvarande enheter efter en rensning

En rensning raderar binärfiler; handskrivna enhetsfiler, vanligtvis under /etc/systemd/system, överlever den. Systemd försöker då igen med en enhet som pekar på en sökväg som inte längre finns, och meddelandet gäller den saknade filen snarare än gårdagens borttagning. systemctl status visar enhetens fragmentväg nära toppen, så kontrollera den med dpkg -S innan du raderar något. När det föräldralösa objektet är borta rensar systemctl daemon-reload och systemctl reset-failed tillståndet; annars ärver varje senare statuskontroll det.

När which openvpn svarar med något under /usr/local kom binärfilen i spel från en leverantörsinstallerare och inte från apt. En sådan installerare brukar ta med sin egen lyssnare, sin egen startpost och sin egen konfigurationskatalog, så att ta bort det synliga kommandot lämnar socketen upptagen.

Avinstallera den enligt leverantörens dokumentation, bekräfta att porten är ledig med ss -lunp och lägg bara till distributionens klient om du behöver den.

Städa tillståndet innan du försöker igen

Rensa det misslyckade tillståndet innan du drar slutsatser av det: systemctl reset-failed tar bort räknarna och systemctl status rapporterar sedan enhetens aktuella tillstånd i stället för dess historik. Starta den en gång och läs just den instansens journal i stället för maskinens samlade tillstånd. En enhet som rapporterar aktiv medan tunneln inte bär något är ett separat problem, och ett mycket vanligare. De två blandas ihop i felrapporter eftersom båda slutar med att användaren säger att VPN:en inte fungerar.

Notera vilken gren du tog: portkonflikt, saknad binärfil, saknad konfiguration. Nästa förekomst går snabbare att känna igen.