OpenVPN start niet: lees de eerste regel, niet de configuratie

Een VPN die in de eerste seconde sterft is een ander dier dan een die verbindt en daarna faalt, en de gebruikelijke fout is ze als hetzelfde te behandelen. Hier is geen handshake, geen certificaatuitwisseling en geen route om te onderzoeken. Eén regel in het journaal bepaalt welke van verschillende onverwante reparaties van toepassing is, en die overslaan kost een middag het bewerken van een configuratie die nooit is gelezen. Lees die regel eerst.

Drie alleen-lezen-opdrachten brengen je daar: eerst journalctl -u openvpn@server -b --no-pager, dan systemctl status openvpn@server, en ss -lunp voor de UDP-luisteraars en hun eigenaren.

De eerste regel kiest de tak

Een poortconflict en een ontbrekend binair bestand doden beide het starten binnen een seconde, en ze laten verschillende eerste regels achter. Een bericht dat het adres al in gebruik is noemt de poort; een ontbrekend uitvoerbaar bestand noemt een pad dat niet meer bestaat; een mislukte voorwaarde of een ontbrekend configuratiebestand noemt het bestand. Die drie leiden tot verschillende reparaties, en geen ervan wordt beter van het herinstalleren van de client. Kopieer de eerste fout naar je notities voordat je iets anders uitvoert.

Let op de herhalingslus die de oorspronkelijke regel verbergt. Een unit met een herstartbeleid kan de eerste fout onder een dozijn identieke begraven, dus journalctl -b gefilterd op de unit en van bovenaf gelezen verslaat de staart.

Wie houdt poort 1194 nog meer vast

De schuldige is meestal geen tweede server die iemand bewust heeft geconfigureerd. Verwacht een met de hand gestarte client die nog leeft in een andere terminal, een tweede profiel dat toevallig dezelfde poort koos, of een leveranciersbundel waarvan de eigen tunnel 1194 vasthoudt. De eigenaar van de socket verschijnt in ss -lunp; geef die PID aan systemctl status om te weten of een unit verantwoordelijk is. Haal hem neer via zijn eigen controlepad in plaats van met een signaal.

Een signaal aan een door een unit beheerd proces veroorzaakt meestal een herstart, en dezelfde fout verschijnt momenten later weer als een nieuw probleem. Gebruik systemctl stop voor een unit, de eigen serviceopdracht van de bundel voor een leveranciersinstallatie, en een signaal alleen voor iets wat je zelf in die shell hebt gestart.

Achtergebleven units na een verwijdering

Een verwijdering wist binaire bestanden; met de hand geschreven unitbestanden, meestal onder /etc/systemd/system, overleven het. Systemd probeert dan opnieuw een unit die naar een pad wijst dat niet meer bestaat, en het bericht gaat over dat ontbrekende bestand in plaats van over de verwijdering van gisteren. systemctl status toont het fragmentpad van de unit bovenaan, dus controleer het met dpkg -S voordat je iets verwijdert. Zodra de wees weg is, ruimen systemctl daemon-reload en systemctl reset-failed de toestand op; anders erft elke latere statuscontrole die.

Wanneer which openvpn antwoordt met iets onder /usr/local, kwam het binaire bestand in kwestie van een leveranciersinstaller en niet van apt. Zo een installer brengt meestal zijn eigen luisteraar, zijn eigen opstartregel en zijn eigen configuratiemap mee, dus het verwijderen van de zichtbare opdracht laat de socket bezet.

De-installeer het zoals de leverancier documenteert, bevestig dat de poort vrij is met ss -lunp, en voeg de distributieclient alleen toe als je die nodig hebt.

Zet de toestand in orde voordat je het opnieuw probeert

Ruim de mislukte toestand op voordat je er conclusies uit trekt: systemctl reset-failed verwijdert de tellers, en systemctl status rapporteert dan de huidige toestand van de unit in plaats van zijn geschiedenis. Start het één keer en lees het journaal van die uitvoering in plaats van de samengevatte toestand van de machine. Een unit die actief meldt terwijl de tunnel niets vervoert is een apart probleem, en een veel gewoner. De twee worden in bugrapporten samengevoegd omdat beide eindigen met de gebruiker die zegt dat de VPN niet werkt.

Noteer de tak die je nam: poortconflict, ontbrekend binair bestand, ontbrekende configuratie. De volgende keer is het sneller herkenbaar.