Hokker OpenVPN-eksimplaar brûkt eins dyn PiVPN-profil?

PiVPN skriuwt in serverkonfiguraasje en in klantprofyl, en slút dan ôf; it wurdt nea it proses dat dyn ferkear draacht. In mislearre hânskodding, in klant dy't it ferkearde einpunt kiest, of in tsjinst dy't nei in werynset ferkeard weromkomt, kin dus net út 'e menu's fan 'e ynstallearder ferklearre wurde. Dy symptomen hearre by hokker OpenVPN-daemon dan ek no rint, by de konfiguraasje dy't dy daemon echt laden hat, en by it log dêr't er nei wiisd is. Fjouwer lês-allinnich-opdrachten meitsje dat meastentiids klear, en gjinien fan harren feroaret dyn sertifikaten of kaaien.

De helper en de daemon binne ferskate objekten

De betizing is maklik te ferklearjen: ien map hâldt it bestân dat de helper makke hat, it bestân dat de daemon lêst, en soms in ferâldere kopy fan beide. In helper is in provisioning-skript. It ynstallearret pakketten, skriuwt ienheidsbestannen en printsjet in klantprofyl, en dan einiget syn wurk. Wat oerbliuwt is in ynskriuwing yn 'e tsjinstbehearder en in kommando-rigel.

Begjin op in systemd-host by de aktive ienheid ynstee fan 'e maplys. De namme hinget fan 'e ferpakking ôf: Debian- en Raspberry Pi OS-ôfbylden biede meastentiids in sjabloaneksimplaar lykas openvpn-server@server, wylst âldere ynstallaasjes openvpn@server brûke. Freegje de behearder hokker rint, ynstee fan it út in bestânsnamme te rieden.

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

Lês ExecStart= yn dy útfier. It neamt it útfierbere bestân en de opsjes dy't de behearder echt start, ynklusyf elk --config paad; in konfiguraasjebestân dat derneist leit en dêr't gjin opdracht nei ferwiist, heart net by de rinnende tunnel.

Folgje de konfiguraasjeksetting dy't de daemon oplost hat

OpenVPN skannt gjin map foar ynstellings. It lêst it bestân dat mei --config jûn wurdt, folget elke config rjochtline deryn, en past dan de kommando-rigelopsjes ta. De hânlieding 2.6 beskriuwt dy folchoarder, en dat makket út as twa bestannen it net iens binne oer de port, it apparaat of de sjifertaal.

Smyt earst de effektive oanrop út, en sjoch dan nei de rjochtlinen dy't identiteit en berikberens beslisse. Beide opdrachten binne lês-allinnich en feilich op in libbene server, al printsjet de twadde paden dy'tsto miskien net yn in iepenbier ticket wolst.

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

In .ovpn-bestân yn in thúsmap is in klantartefakt. De serverdaemon lêst it nea, dus dat bestân bewurkje om in hânskoddingflater oan 'e serverkant op te lossen hellet neat út.

Ynsletten binne de oare falstrik. In config-rigel hellet in twadde bestân binnen wêrfan't de opsjes op dat punt ferwurke wurde, dus in lettere ienwearde-rjochtline kin oerskriuwe wat it haadbestân skynber seit. As it sichtbere bestân korrekt liket en de daemon docht noch oars, lês dan it ynsletten bestân foar'tsto wat feroarest.

Keppel it log oan it proses, net oan 'e flater dy'tsto tinkst

Twa logbestimmingen binne gewoan, en mar ien fan beide is it journaal. Mei log-append set skriuwt de daemon nei dat bestân en it journaal hâldt net folle mear as startrigels. Sûnder dat is journalctl de boarne fan barrens.

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

Korrelearje ien ferbiningspoging mei ien tiidfinster. Skriuw it einpunt fan 'e klant op, en lês dan serverbarrens út deselde sekonden. In TLS-hânskodding dat nea by de sertifikaatútwikseling komt, wiist op berikberens of protokolferskil, wylst in autentikaasje-ôfwizing komt neidat de tunnelparameters al ôfsprutsen binne.

In âlde logynskriuwing bewiist neat oer in profyl datsto fiif minuten lyn lêst hawwe. Meitsje it klantbestân op 'e nij, ferbyn ien kear, en lês allinnich de rigels dy't yn dy poging ferskynden.

Skriuw de earste konkrete flater op, net de lêste algemiene. In bind-flater, in ûnbeantwurde bûtenste útwikseling, in sertifikaat-ôfwizing en in akkount-ôfwizing stjoere dy elk nei in oare laach, en in tiidferrin oan 'e ein ferberget faak it nuttige barren derboppe.

De tunnel wer opbouwe is gjin diagnostyske stap

De ferliedlike koarte wei is in twadde, ienfâldiger tunnel opsette: statyske kaai, gjin sertifikaten, gjin ekstra autentikaasje. Hy sil faak ferbine, en hy bewiist allinnich dat twa hosts UDP of TCP tusken har trochjaan kinne. Hy seit neat oer wêrom't de sertifikaat-autentisearre útrôling mislearret, en hy ferfangt stil it feilichheidsmodel datsto hâlde moatten hiest.

Itselde jildt foar it útskeakeljen fan tls-auth of tls-crypt, it fersoepeljen fan verify-x509-name, of it fuortlitten fan in twadde faktor om in griene status te krijen. In tunnel dy't ferbynt om't de ferifikaasje fuorthelle is, is in oar systeem, net in reparearre.

Meitsje ien ôfbeakene feroaring yn 'e laach dy't it log neamde, werynset deselde ienheid, en werhelje de iene ferbiningspoging. Dat hâldt de ferliking earlik, en it lit in feroaring efter dy'tsto weromdraaie kinst.

Watsto oan 'e folgjende persoan jaan moatst

Skriuw fjouwer feiten op salangst dy noch hast: de OpenVPN-ferzje út openvpn --version, de ienheid dy't aktyf is, de konfiguraasjeksetting mei syn ynsletten, en it logfinster dat ien poging beslacht. Dy fjouwer meitsje fan in ûndúdlike klacht in reprodusearbere saak.

Skuonje foar'tsto diele. Privee kaaien, auth-user-pass-bestannen, statysk kaaimateriaal en folsleine klantpakketten hearre net yn in ticket; opsjenammen en de foarm fan 'e keatling binne meastentiids genôch foar in twadde pear eagen.

As de keatling yntakt is en it log wiist noch nei it netwurk, is de folgjende stap it paad tusken klant en server ynstee fan noch in ynstallaasje. Dat is it iene stik fan it ferhaal dat de helper nea besiet.