OpenVPN 3 Linux: lees een D-Bus-fout voordat je terugdraait

Fouten in OpenVPN 3 Linux komen binnen als een D-Bus-methodfout met een onbekende naam eraan, en de verleiding is om een pakket terug te zetten en te hopen. De client is niet één programma: een frontend op de opdrachtregel praat via de bus met diensten die profielen, sessies, de VPN-engine en de geprivilegieerde netwerkwijzigingen bezitten. Bepalen welke van die vijf de falende aanroep bezit, is het grootste deel van de diagnose, en het kost één opdracht in plaats van een terugdraaiing. Wat volgt is die beslissing, in de volgorde waarin de fouten meestal verschijnen.

Vijf eigenaren achter één opdracht

Vijf processen doen ertoe, en elk heeft een eigen busnaam: de frontend die je opdracht aanneemt, de configuratiebeheerder die profielen en hun toegangsbeleid opslaat, de sessiebeheerder die de levensduur van sessies bezit, de backend die de verbinding via de OpenVPN 3 Core Engine uitvoert, en de netwerkconfiguratiedienst die de interface, routes en DNS-instellingen aanbrengt. Een fout die een configuratieobject noemt, is dus geen backendfout, en een backend die niet start is geen authenticatiefout. De melding in een van die rijen onderbrengen moet gebeuren voordat er iets wordt gewijzigd, want elke latere stap hangt af van welke rij klopt. Gokken op de rij is hoe een korte oplossing een middag pakketwerk wordt.

Vraag de systeembus welke diensten aanwezig zijn voordat je iets anders vraagt, en bevestig daarna dat de geïnstalleerde onderdelen het over één versie eens zijn. OpenVPN 3 Linux registreert die diensten als systeemunits, dus de bus om te bevragen is de systeembus, de versiequery vereist beheerdersrechten, en een lijst met --user leest je aanmeldingssessie, waar de units nooit verschijnen. Diensten activeren op aanvraag en sommige stoppen bij inactiviteit, dus een dienst die ontbreekt vóór je eerste verzoek is simpelweg nog nergens om gevraagd. De drie opdrachten hieronder beantwoorden aanwezigheid, versie en unitstatus zonder een VPN-sessie te openen.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Wat elke lijst werkelijk bewijst

De eigen weergaven van de client zijn het goedkoopste bewijs dat beschikbaar is, en elk ervan bewijst minder dan het lijkt. Een profiel in de configuratielijst toont dat een profiel is geïmporteerd en niets over de vraag of iemand ermee mag verbinden. Een sessie in de sessielijst toont dat er een sessieobject bestaat en niets over de vraag of de externe authenticatie is afgerond.

openvpn3 configs-list
openvpn3 sessions-list

Objectpaden in die uitvoer benoemen beheerde objecten op de bus en geen bestanden, ze zijn dus niet te bewerken, en een eerder genoteerd pad veroudert op het moment dat die sessie loskoppelt. Een pad uit je notities hergebruiken levert "no such object"-fouten op die niets met de VPN te maken hebben. De stadiumtabel hieronder scheidt wat elke stap van een verbinding tot stand brengt van wat hij openlaat, en precies dat onderscheid bepaalt een terugdraaiingsbeslissing. Lees de rij die bij je bewijs past en lees de fouttekst daarna opnieuw.

De verbindingsaanroep keert terug voordat de tunnel bestaat

De verbindingsaanroep geeft je een sessie om te volgen en keert terug, daarom is een schijnbaar geslaagde aanroep gevolgd door stilte een normale tussenstand en geen tegenspraak. De frontend moet nog steeds statuswijzigingen volgen en elk verzoek om interactie beantwoorden. Een profiel dat een inloggegeven nodig heeft en geen antwoord krijgt, wacht in een toestand die er precies zo uitziet als een vastgelopen backend. Die wachttoestand verdient erkenning, want hij stuurt mensen naar het verkeerde onderdeel.

Terwijl een poging loopt, volg je de sessielijst en het eigen log van de frontend voor dat profiel. Een sessie die haar begintoestand nooit verlaat, noemt het onderdeel dat stopte, en het log noemt het meestal al in de eerste paar regels. Houd de profielnaam bij de hand, want de logopdracht neemt een profiel en geen sessiepad, wat nog een reden is om de lijst opnieuw te lezen in plaats van een pad te hergebruiken.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Het log van één onderdeel lezen zonder een sessie te openen

Wanneer de frontend niets nuttigs meldt, ga naar het onderdeel dat de fout heeft gelogd in plaats van nog een verbinding te starten. Met een geconfigureerde systemd-journald-logger leest de afgebakende journalweergave van de beheerder de gebeurtenissen van één onderdeel zonder busbeleid aan te raken of een sessie te openen, wat ertoe doet omdat een diagnose die het gemeten systeem wijzigt heel weinig bewijst. Filter op unit en niet op syslog-tag: de afzonderlijke dienstunits garanderen geen gedeelde identificatie, dus een tagquery kan een lege pagina opleveren terwijl de unit zelf de fout vastlegde.

Noteer vier velden voordat je iemand om hulp vraagt: de volledige foutnaam, de betrokken dienst en het betrokken object, de tijdstempel en de geïnstalleerde pakketversies. Dat is wat een beheerder nodig heeft, en niets daarvan vereist dat je een profiel of een inloggegeven in een ticket plakt. Het busbeleid verruimen om de fout stil te krijgen is geen diagnose, het wist de grens die het onderdeel voor je benoemde. Privé-inhoud van profielen blijft buiten gedeelde rapporten, om dezelfde reden als inloggegevens.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

De grens corrigeren die weigerde

Elke rij van de kaart heeft haar eigen correctie, en de rijen vervangen elkaar niet. Een geweigerde bewerking op een profiel is een vraag over beleid en eigenaarschap, terwijl een backend die niet activeert een vraag is over diensten en pakkettering. Een server die authenticatie weigert is geen van beide, dus herhaald wachtwoorden wijzigen kan een lokaal activeringsprobleem niet repareren. De verkeerde correctie kiezen is hoe een beleidsprobleem een herinstallatie wordt.

Controleer na een pakketwijziging dat er een samenhangende, ondersteunde installatie staat in plaats van één oud binair bestand op zijn plek te kopiëren. Een gecontroleerde terugdraaiing is een legitiem antwoord op een bevestigde regressie, mits de pakketten compatibel blijven en er een route terug naar ondersteund onderhoud bestaat. Leg die route aan voordat de dienst stopt met starten, niet daarna.

Een ander platform kan dezelfde VPN-kernbibliotheek delen zonder de busdiensten van Linux te delen, dus een vergelijkbaar uitziende fout op Windows zegt niets over deze. Het D-Bus-overzicht documenteert de objectpaden die voor configuraties en sessies worden aangeboden, en dat is het deel van de architectuur waarop deze diagnose steunt. Lees het één keer, en de volgende fout komt binnen met een onderdeel er al aan vast.