OpenVPN starta, men skreiv ingenting: sjekk log-append først

Du startar OpenVPN frå eit skal med ei konfigurasjonsfil, og terminalen blir ståande heilt utan utdata. Ingen banner, ingen feil, ingen ledetekst. Instinktet seier at starten mislukkast, så du startar ein ny kopi, deretter ein til, og maskina endar opp med fleire halvkonfigurerte instansar. Før noko av dette, sjekk profilen for eit direktiv som allereie har omdirigert loggen ein annan stad. Stillheit er ein eigenskap ved konsollen, ikkje ved prosessen.

Stillheit har to svært ulike forklaringar

Den fyrste er at prosessen køyrer fint og skriv til ei fil du ikkje følgjer med på. Den andre er at han avslutta med ein gong med ein feil som er registrert i same fila.

Begge lèt att ein tom terminal, og eitt spørsmål skil dei: finst det ein prosess no, og kva står i fila han vart beden om å skrive til. Svar på det før du rører konfigurasjonen igjen. Å starte på nytt for å få utdata er korleis to instansar endar med å kjempe om éi tunneleining og same port, noko som gjev feil som ikkje har noko med det opphavlege problemet å gjere.

Finn direktivet, og finn deretter prosessen.

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

Finn målet den køyrande prosessen brukar

Les profilen prosessen faktisk vart starta med, ikkje den du redigerte. Ein tenestestyrt instans lastar vanlegvis ein annan bane og køyrer i ein annan arbeidskatalog, så eit relativt filnamn blir løyst ut ein stad du ikkje venta.

Eit eksplisitt cd direktiv gjer den skilnaden skarpare, fordi den relative banen flyttar seg med katalogbytet. Viss du arva denne konfigurasjonen, kan fila liggje på ein stad ingen ville leite no.

Samanlikn endringstida til fila med augeblinken du starta. Ein logg frå førre veke er bevis om førre veke. Les deretter dei siste linjene i fila som endra seg, og handsam det som står der som startmeldinga du har mangla.

log kontra log-append: bevis og sletting

log-append legg til det som allereie står i fila. log opnar fila for skriving og kuttar henne, så å bytte mellom dei to kan slette køyringa du var i ferd med å lese.

Viss nokon endra direktivet under feilsøking, er det førre beviset allereie borte, og filstorleiken vil verke mistenkeleg liten. Det er verdt å vite før du samanliknar to køyringar og konkluderer med at noko endra seg. Slett ein logg med vilje, eller behald han, men vit kva du gjorde. Bevis du fjerna med vilje er lettare å resonnere om enn bevis du mista ved eit uhell.

Ingen av alternativa opprettar manglande overordna katalogar, og ingen av dei gjev tilgang gjennom filsystemløyve eller ein tenestesandkasse. Ein bane som ser rett ut i konfigurasjonen kan framleis vere uskrivbar for kontoen daemonen køyrer som, og då kan daemonen mislukkast før han får rapportert noko. Sjekk om katalogen finst og kven som eig han før du går ut frå at filnamnet er problemet.

Når ei tenesteinnpakning fangar utdata

Under systemd går standardutdata og feil til journalen med mindre eit eksplisitt fildirektiv har forrang, og ei leverandørinnpakning kan fange dei heilt andre stader.

Det er derfor same profil oppfører seg annleis frå eit skal og frå ei unit. Miljøet til unita, arbeidskatalogen og standardstraumane er alle ulike frå det interaktive skalet ditt. Ein relativ bane kan løysast i éin samanheng og ende ingen stad i den andre. Les unitdefinisjonen når dei to er usamde, ikkje profilen.

Samanlikn dei to startmåtane i staden for å konkludere med at ein av dei er øydelagd. Les kommandolinja til unita og miljøet hennar, og les deretter journalen for same tidsvindauge. Viss innpakninga omdirigerer utdata til si eiga fil, er den fila loggen din no, og OpenVPN-direktiva er irrelevante for kvar meldingane tok vegen.

Auk detaljnivået først når du kan lese det

Å auke detaljnivået før du finn målet gjev berre meir tekst på ein stad du ikkje ser på.

Når du veit kvar utdataa landar, viser eit moderat nivå at profilen blir tolka og at tilkoplinga blir forsøkt. To eller tre er nok for eit startproblem. Høgare nivå fortener plassen sin når feilen er ein forhandlingsdetalj, og dei gjer også fila snøgt større.

Les så den faktiske feilen. Ein stille terminal beviser ingenting om tunellen kom opp, og feilen som er registrert i fila er den som er verdt å rette.