client-config-dir word geïgnoreer nadat OpenVPN 'n diens geword het

Jou tonnel kom op en die kliënt verbind, maar die vaste adres en die gepushte roetes wat jy vir daardie een gebruiker gedefinieer het, ontbreek. Niks in die log sê “lêer nie gevind nie”, en dit is juis wat mense laat sertifikate hergenereer. In die meeste van hierdie gevalle loop die daemon uit 'n ander gids as die skulp waarin jy getoets het, en client-config-dir is nooit opgelos soos jy aangeneem het nie. Die oplossing is 'n regstelling van die pad, nie 'n herstel van aanmeldgegewens nie.

Lees die unit voordat jy aan die konfigurasie raak

Begin by die proses wat werklik loop, nie by die lêer wat jy geredigeer het nie. Vra systemd vir die uitvoerbare reël, die werkmap en die rekening waarna dit daal. Daardie drie antwoorde verduidelik die meeste foute in hierdie klas:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

'n Leë WorkingDirectory beteken die unit begin in /, dus word 'n relatiewe client-config-dir ccd by /ccd gesoek. Daardie gids bestaan byna nooit nie, en die daemon beskou die afwesigheid daarvan nie as noodlottig nie.

Vergelyk dit met die interaktiewe bekendstelling wat jy tydens toetsing gebruik het, waar jou skulp se huidige gids waarskynlik die konfigurasiegids was. Dieselfde lêer, dieselfde sleutelwoorde, twee verskillende resultate.

Waarteen 'n relatiewe pad opgelos word

Die sleutelwoord word opgelos teen die proses se werkmap op die oomblik dat die opsie gebruik word. Dit beteken nie “langs die konfigurasielêer wat ek met --config” oorgedra het nie. OpenVPN sal met graagte 'n konfigurasie uit 'n absolute pad lees en relatiewe waardes steeds elders oplos, en dit is juis die lokval hier. Die OpenVPN 2.6-handleiding stel die reël onder --client-config-dir en weer onder --cd.

Die cd-sleutelwoord verander daardie konteks voordat ander lêers gelees word, dus 'n unit wat cd /etc/openvpn/server stel en dan client-config-dir ccd los op na /etc/openvpn/server/ccd. As jy cd byvoeg, kyk na die volgorde van die richtlyne en onthou dat dit elke ander relatiewe verwysing in dieselfde lêer raak.

Loop die pad as die daemon se rekening

'n Pad kan korrek wees en tog onleesbaar. Ná die verlaging van voorregte is die daemon nie meer root nie, dus elke ouergids het soektoestemming vir daardie rekening nodig, en die kliëntlêer self het leestoestemming nodig. Een ontbrekende uitvoerbit op 'n ouergids is genoeg om die lêer weg te steek, en die fout wys net as 'n kliënt wat stilweg die verstekpoel kry.

namei druk die toestemming van elke komponent in volgorde, wat vinniger is as om gidse een vir een na te gaan:

namei -l /etc/openvpn/server/ccd/client1

Toets dan die lees as die diensrekening eerder as as jouself:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

As die unit chroot gebruik, moet die gids binne die tronk bestaan, en die pad in die konfigurasie word ná die chroot geïnterpreteer. 'n Lêer wat op die gasheer buite die tronk teenwoordig is, is van binne onsigbaar.

Bevestig die opsoek in plaas van raai

Verhoog die logvlak vir een herbegin en lees wat die bediener oor kliëntspesifieke opsies sê. By verb 4 rapporteer die daemon die per-kliënt-konfigurasie wat dit ingevoer het, dus 'n afwesige reël is direkte bewys dat geen lêer vir daardie verbinding gelees is nie.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Voer dit op die voorgrond op 'n oorblywende poort uit en verbind een kliënt. Dit verwyder systemd heeltemal uit die prent: as die oorheersings hier verskyn en nie onder die diens nie, is die verskil die unit se konteks, nie die lêer nie.

Besluit wat moet gebeur wanneer geen lêer pas nie. Sonder ccd-exclusive word die kliënt toegelaat met slegs die globale poelinstellings, en dit is die stil fout wat hierbo beskryf is. Daarmee word 'n ontbrekende lêer 'n geweierde verbinding, en daardie weiering is makliker om raak te sien maar moeiliker om fout te soek onder las.

Maak reg, herbegin, verifieer

Maak die gids absoluut in die konfigurasie en hou dit so. Relatiewe paaie is net veilig wanneer die unit die werkmap vaspen, en om dit vas te pen is 'n ekstra bewegende deel wat iemand later sal verwyder.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Herbegin die instansie, verbind een bekende kliënt weer en lees die adres wat dit ontvang het saam met die roetes wat daarheen gepush is. As die adres ooreenstem met die ifconfig-push-reël in daardie kliënt se lêer, het die opsoek gewerk. As die kliënt steeds in die algemene poel beland, gaan terug na die telling van logreëls: nul invoere beteken die pad of die identiteit is verkeerd, een invoer met die verkeerde inhoud beteken jy redigeer 'n ander lêer as wat die daemon lees.

Draai terug deur die vorige unit en konfigurasie saam te herstel en dan te herbegin. Sertifikate hoef nie hiervoor heruitgereik te word nie, en om 'n gidsprobleem as 'n aanmeldgegewenprobleem te behandel, is hoe 'n vyfminuut-regstelling 'n onderhoudsvenster word.