OpenVPN startede, men udskrev intet: tjek log-append først

Du starter OpenVPN fra en shell med en konfigurationsfil, og terminalen står helt uden output. Ingen banner, ingen fejl, ingen prompt. Instinktet siger, at starten mislykkedes, så du starter endnu en kopi, derefter endnu en, og maskinen ender med flere halvkonfigurerede instanser. Før alt det bør du tjekke profilen for en direktiv, der allerede har omdirigeret loggen et andet sted hen. Stilhed er en egenskab ved konsollen, ikke ved processen.

Stilhed har to meget forskellige forklaringer

Den første er, at processen kører fint og skriver til en fil, du ikke overvåger. Den anden er, at den straks afsluttedes med en fejl registreret i samme fil.

Begge efterlader en tom terminal, og ét spørgsmål skiller dem: findes der en proces nu, og hvad står der i den fil, den blev bedt om at skrive til. Svar på det, før du rører konfigurationen igen. At genstarte for at få output er måden, hvorpå to instanser ender med at slås om én tunnel-enhed og samme port, hvilket giver fejl, der intet har med det oprindelige problem at gøre.

Find direktivet, find derefter processen.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Find det mål, den kørende proces bruger

Læs den profil, processen faktisk blev startet med, ikke den du redigerede. En tjenestestyret instans indlæser normalt en anden sti og kører med en anden arbejdsmappe, så et relativt filnavn opløses et sted, du ikke forventede.

Et eksplicit cd-direktiv gør den forskel skarpere, fordi den relative sti flytter med mappeskiftet. Hvis du har overtaget denne konfiguration, kan filen ligge et sted, ingen ville lede efter den nu.

Sammenlign filens ændringstid med det øjeblik, du startede. En log fra sidste uge er bevis om sidste uge. Læs derefter de sidste linjer i den fil, der ændrede sig, og behandl det, der står, som den opstartsbesked, du har manglet.

log versus log-append: bevis og sletning

log-append føjer til det, der allerede er i filen. log åbner filen til skrivning og afkorter den, så at skifte mellem de to kan slette den kørsel, du var ved at læse.

Hvis nogen har ændret direktivet under fejlfinding, er det tidligere bevismateriale allerede væk, og filens størrelse vil se mistænkeligt lille ud. Det er værd at vide, før du sammenligner to kørsler og konkluderer, at noget ændrede sig. Slet en log med vilje, eller behold den, men vid, hvad du gjorde. Bevis, du har fjernet med vilje, er lettere at forholde sig til end bevis, du mistede ved et uheld.

Ingen af mulighederne opretter manglende overordnede mapper, og ingen af dem giver adgang gennem filsystemtilladelser eller en tjenestesandbox. En sti, der ser korrekt ud i konfigurationen, kan stadig være uskrivbar for den konto, daemonen kører som, og så kan daemonen fejle, før den kan rapportere noget. Tjek, om mappen findes, og hvem der ejer den, før du antager, at filnavnet er problemet.

Når en tjenesteindpakning fanger outputtet

Under systemd går standardoutput og -fejl til journalen, medmindre et eksplicit fildirektiv har forrang, og en leverandørindpakning kan fange dem helt andre steder.

Derfor opfører den samme profil sig forskelligt fra en shell og fra en unit. Unitens miljø, dens arbejdsmappe og dens standardstrømme adskiller sig alle fra din interaktive shell. En relativ sti kan opløses i én kontekst og ende ingen steder i den anden. Læs unit-definitionen, når de to er uenige, ikke profilen.

Sammenlign de to startopstillinger i stedet for at konkludere, at en af dem er i stykker. Læs unitens kommandolinje og dens miljø, og læs derefter journalen for samme tidsvindue. Hvis indpakningen omdirigerer output til sin egen fil, er den fil nu din log, og OpenVPN-direktiverne er irrelevante for, hvor beskederne endte.

Skru først op for detaljeringen, når du kan læse den

At øge detaljeringen, før du finder målet, producerer bare mere tekst et sted, du ikke kigger.

Når du ved, hvor outputtet ender, viser et moderat niveau, at profilen parses, og at forbindelsen forsøges. To eller tre er nok til et opstartsproblem. Højere niveauer gør sig fortjent, når fejlen er en forhandlingsdetalje, og de får også filen til at vokse hurtigt.

Læs derefter den faktiske fejl. En tavs terminal beviser intet om, hvorvidt tunnelen kom op, og den fejl, der er registreret i filen, er den, der er værd at rette.