Watter OpenVPN-instansie gebruik werklik jou PiVPN-profiel?

PiVPN skryf ’n bedienerkonfigurasie en ’n kliëntprofiel, en stop dan; dit word nooit die proses wat jou verkeer dra nie. ’n Mislukte handdruk, ’n kliënt wat die verkeerde eindpunt skakel, of ’n diens wat ná ’n herbegin verkeerd terugkom, kan dus nie uit die installateur se keuses verklaar word nie. Daardie simptome hoort by watter OpenVPN-agtergrondproses nou ook al loop, by die konfigurasie wat daardie proses werklik gelaai het, en by die log waarna dit gewys is. Vier leesalleen-opdragte besleg dit gewoonlik, en nie een van hulle verander jou sertifikate of sleutels nie.

Die hulpprogram en die agtergrondproses is verskillende dinge

Die verwarring is maklik om te verduidelik: een gids hou die lêer wat die hulpprogram geskep het, die lêer wat die agtergrondproses lees, en soms ’n verouderde kopie van albei. ’n Hulpprogram is ’n voorsieningsskrip. Dit installeer pakkette, skryf eenheidslêers en druk ’n kliëntprofiel, en dan eindig sy werk. Wat oorbly, is ’n inskrywing in die diensbestuurder en ’n opdragreël.

Begin op ’n systemd-gasheer by die aktiewe eenheid eerder as by die gidslys. Die naam hang van die verpakking af: Debian- en Raspberry Pi OS-beelde bied gewoonlik ’n sjablooninstansie soos openvpn-server@server, terwyl ouer installasies openvpn@server gebruik. Vra die bestuurder watter een loop eerder as om dit uit ’n lêernaam te raai.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lees ExecStart= in daardie uitset. Dit noem die uitvoerbare lêer en die opsies wat die bestuurder werklik begin, insluitend enige --config pad; ’n konfigurasielêer wat daar naby lê en waarna geen opdrag verwys nie, is nie deel van die lopende tonnel nie.

Volg die konfigurasieketting wat die agtergrondproses opgelos het

OpenVPN skandeer nie ’n gids vir instellings nie. Dit lees die lêer wat met --config, volg enige config richtlyne daarin, en pas dan die opdragreël-opsies toe. Die 2.6-handleiding beskryf daardie volgorde, en dit maak saak wanneer twee lêers verskil oor die poort, die toestel of die syfer.

Stort eers die werklike aanroep uit, en kyk dan na die richtlyne wat identiteit en bereikbaarheid bepaal. Albei opdragte is leesalleen en veilig op ’n lewendige bediener, hoewel die tweede paaie druk wat jy dalk nie in ’n openbare kaartjie wil hê nie.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

’n .ovpn-lêer in ’n tuisgids is ’n kliëntartefak. Die bediener-agtergrondproses lees dit nooit, so om daardie lêer te wysig om ’n mislukking aan die bedienerkant reg te maak, bereik niks.

Insluitings is die ander lokval. ’n config-reël trek ’n tweede lêer in waarvan die opsies op daardie punt verwerk word, so ’n latere enkelwaarde-richtlyn kan oorheers wat die hoofllêer blyk te sê. As die sigbare lêer korrek lyk en die agtergrondproses gedra hom steeds anders, lees die ingeslote lêer voordat jy enigiets verander.

Pas die log by die proses, nie by die fout wat jy onthou nie

Twee logbestemmings is algemeen, en net een daarvan is die joernaal. Met log-append gestel, skryf die agtergrondproses na daardie lêer en die joernaal hou min buiten aanvanglyne. Daarsonder is journalctl die bron van gebeure.

journalctl -u openvpn-server@server -n 80 --no-pager

Korreleer een verbindingspoging met een tydvenster. Let op die kliënt se eindpunt, en lees dan bedienergebeure uit dieselfde sekondes. ’n TLS-handdruk wat nooit die sertifikaatuitruiling bereik nie, dui op bereikbaarheid of protokolverskil, terwyl ’n verwerping van verifikasie eers kom nadat die tonnelparameters reeds ooreengekom is.

’n Ou loginskrywing bewys niks oor ’n profiel wat jy vyf minute gelede afgelaai het nie. Genereer die kliëntlêer opnuut, verbind een keer, en lees net die reëls wat tydens daardie poging verskyn het.

Teken die eerste spesifieke fout op, nie die laaste algemene een nie. ’n Bind-fout, ’n onbeantwoorde buitenste uitruiling, ’n sertifikaatverwerping en ’n rekeningverwerping stuur jou elkeen na ’n ander laag, en ’n nasleep-tydsperking verberg dikwels die nuttige gebeurtenis daarbo.

Om die tonnel te herbou is nie ’n diagnostiese stap nie

Die aanloklike kortpad is om ’n tweede, eenvoudiger tonnel op te rig: statiese sleutel, geen sertifikate, geen bykomende verifikasie. Dit sal dikwels verbind, en dit bewys net dat twee gashere UDP of TCP tussen hulle kan deurlaat. Dit sê niks oor waarom die sertifikaat-verifieerde ontplooiing misluk nie, en dit vervang stilweg die sekuriteitsmodel wat jy gevra is om te hou.

Dieselfde geld vir die uitskakel van tls-auth of tls-crypt, die verslapping van verify-x509-name, of die laat vaar van ’n tweede faktor om ’n groen status te kry. ’n Tonnel wat verbind omdat verifikasie verwyder is, is ’n ander stelsel, nie ’n herstelde een nie.

Maak een afgebakende verandering op die laag wat die log genoem het, herbegin dieselfde eenheid, en herhaal die enkele verbindingspoging. Dit hou die vergelyking eerlik, en dit laat ’n verandering wat jy kan terugrol.

Wat om aan die volgende persoon te gee

Skryf vier feite neer terwyl jy hulle nog het: die OpenVPN-weergawe uit openvpn --version, die eenheid wat aktief is, die konfigurasieketting met sy insluitings, en die logvenster wat een poging dek. Daardie vier maak ’n vae klag ’n herproduseerbare geval.

Verwyder sensitiewe data voordat jy deel. Privaat sleutels, auth-user-pass-lêers, statiese sleutelmateriaal en volledige kliëntbundels hoort nie in ’n kaartjie nie; opsiename en die vorm van die ketting is gewoonlik genoeg vir ’n tweede paar oë.

As die ketting ongeskonde is en die log steeds na die netwerk wys, is die volgende stap die pad tussen kliënt en bediener eerder as nog ’n installasie. Dit is die een deel van die verhaal wat die hulpprogram nooit besit het nie.