OpenVPN 3 Linux: läs ett D-Bus-fel innan du rullar tillbaka

Fel i OpenVPN 3 Linux kommer in som ett D-Bus-metodfel med ett obekant namn på, och frestelsen är att nedgradera ett paket och hoppas. Klienten är inte ett program: en frontend på kommandoraden talar över bussen med tjänster som äger profiler, sessioner, VPN-motorn och de privilegierade nätverksändringarna. Att avgöra vilken av de fem som äger det felande anropet är det mesta av diagnosen, och det kostar ett kommando i stället för en återställning. Det som följer är det beslutet, i den ordning felen vanligen dyker upp.

Fem ägare bakom ett kommando

Fem processer spelar roll, och var och en har sitt eget busnamn: frontenden som tar emot ditt kommando, konfigurationshanteraren som lagrar profiler och deras åtkomstpolicy, sessionshanteraren som äger sessionens livstid, backenden som kör anslutningen genom OpenVPN 3 Core Engine, och nätverkskonfigurationstjänsten som installerar gränssnittet, rutterna och DNS-inställningarna. Ett fel som namnger ett konfigurationsobjekt är därför inte ett backend-fel, och en backend som inte startar är inte ett autentiseringsfel. Att sortera in meddelandet i en av de raderna måste ske innan något ändras, eftersom varje senare steg beror på vilken rad som är sann. Att gissa på raden är hur en kort rättelse blir en eftermiddag av paketarbete.

Fråga systembussen vilka tjänster som finns innan du frågar något annat, och bekräfta sedan att de installerade delarna är överens om en version. OpenVPN 3 Linux registrerar dessa tjänster som systemenheter, så bussen att fråga är systembussen, versionsfrågan kräver administrativa rättigheter, och en lista gjord med --user läser din inloggningssession, där enheterna aldrig dyker upp. Tjänster aktiveras vid behov och en del avslutar när de är inaktiva, så en tjänst som saknas före din första begäran har helt enkelt inte blivit tillfrågad om något än. De tre kommandona nedan besvarar närvaro, version och enhetsstatus utan att öppna en VPN-session.

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

Vad varje lista faktiskt bevisar

Klientens egna vyer är det billigaste beviset som finns, och var och en av dem bevisar mindre än den ser ut att göra. En profil i konfigurationslistan visar att en profil är importerad och inget om huruvida någon får ansluta med den. En session i sessionslistan visar att ett sessionsobjekt finns och inget om huruvida fjärrautentiseringen blev klar.

openvpn3 configs-list
openvpn3 sessions-list

Objektvägar i de utskrifterna anger hanterade objekt på bussen och inte filer, så de kan inte redigeras, och en väg som antecknats tidigare blir inaktuell i samma ögonblick som den sessionen kopplas från. Att återanvända en från dina anteckningar ger "no such object"-fel som inte har något med VPN att göra. Stadiemtabellen nedan skiljer vad varje steg i en anslutning upprättar från vad det lämnar öppet, och det är just den skillnaden ett återställningsbeslut hänger på. Läs den rad som matchar ditt bevis och läs sedan feltexten igen.

Anslutningsanropet återvänder innan tunneln finns

Anslutningsanropet ger dig en session att följa och återvänder, vilket är varför ett till synes lyckat anrop följt av tystnad är ett normalt mellantillstånd och inte en motsägelse. Frontenden måste fortfarande följa statusändringar och svara på varje begäran om interaktion. En profil som behöver en autentiseringsuppgift och inte får något svar väntar i ett tillstånd som ser exakt ut som en hängd backend. Det väntetillståndet förtjänar att kännas igen, eftersom det skickar folk till fel komponent.

Medan ett försök pågår, håll koll på sessionslistan och frontendens egen logg för den profilen. En session som aldrig lämnar sitt initialtillstånd namnger komponenten som stoppade, och loggen namnger den vanligen inom de första raderna. Ha profilnamnet till hands, eftersom loggkommandot tar en profil och inte en sessionsväg, vilket är en anledning till att läsa listan igen i stället för att återanvända en väg.

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

Att läsa en komponents logg utan att öppna en session

När frontenden inte rapporterar något användbart, gå till komponenten som loggade felet i stället för att starta en ny anslutning. Med en konfigurerad systemd-journald-loggare läser administratörens avgränsade journalvy en komponents händelser utan att röra buspolicyn eller öppna en session, vilket spelar roll eftersom en diagnos som ändrar systemet den mäter bevisar väldigt lite. Filtrera på enhet i stället för på syslog-tagg: de enskilda tjänsteenheterna garanterar ingen gemensam identifierare, så en taggfråga kan ge en tom sida medan enheten själv registrerade felet.

Anteckna fyra fält innan du ber någon om hjälp: hela felnamnet, tjänsten och objektet som är inblandade, tidsstämpeln och de installerade paketversionerna. Det är vad en underhållare behöver, och inget av det kräver att du klistrar in en profil eller en autentiseringsuppgift i ett ärende. Att vidga busåtkomstpolicyn för att tysta felet är ingen diagnos, det raderar den gräns som namngav komponenten åt dig. Privat profil-innehåll hålls utanför delade rapporter av samma skäl som autentiseringsuppgifter.

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

Att rätta gränsen som vägrade

Varje rad i kartan har sin egen rättelse, och raderna ersätter inte varandra. En nekad åtgärd på en profil är en fråga om policy och ägande, medan en backend som inte aktiveras är en fråga om tjänster och paketering. En server som avvisar autentisering är inget av dem, så upprepade lösenordsbyten kan inte reparera ett lokalt aktiveringsproblem. Att välja fel rättelse är hur ett policyproblem blir en ominstallation.

Efter en paketändring, verifiera en sammanhängande, supportad installation i stället för att kopiera en gammal binärfil på plats. En kontrollerad återställning är ett legitimt svar på en bekräftad regression, förutsatt att paketen förblir kompatibla och att det finns en väg tillbaka till supportat underhåll. Upprätta den vägen innan tjänsten slutar starta, inte efteråt.

En annan plattform kan dela samma VPN-kärnbibliotek utan att dela Linux busstjänster, så ett liknande fel på Windows säger inget om detta. D-Bus-översikten dokumenterar de objektvägar som exponeras för konfigurationer och sessioner, och det är den del av arkitekturen som den här diagnosen vilar på. Läs den en gång, och nästa fel anländer med en komponent redan fäst vid sig.