ConnMan VPN: meniul lipsă este un daemon, nu un protocol

Convingerea este că un sistem ConnMan fără intrare VPN pe desktop nu are niciun suport VPN instalat. De obicei are suport pentru Wi-Fi și niciunul pentru daemonul VPN, configurația furnizorului sau agentul de autentificare, iar acestea sunt trei absențe separate. Meniul este o vedere asupra acelor componente, nu funcția în sine. Verificarea versiunii și a ambalării vă spune într-o singură comandă mai mult decât orice număr de rapoarte de eroare de pe desktop.

Mitul: meniul este funcția VPN

Începeți cu versiunea instalată de ConnMan și pachetele care au venit cu ea. Un raport de eroare dintr-o versiune mai veche descrie un alt set de funcții, iar citarea lui se termină de obicei cu cineva care reinstalează un manager de rețea care nu trebuia înlocuit.

Notați ce aveți de fapt înainte de a schimba ceva: fișierul binar al daemonului, directorul furnizorilor și dacă există un agent.

Ce daemon deține tunelul

În documentația ConnMan 1.41 pentru Debian bookworm, connman-vpnd este daemonul care administrează conexiunile VPN alături de connmand. Acesta enumeră integrări pentru asistenți VPN cu nume, inclusiv OpenVPN și OpenConnect. Acea listă este o afirmație despre asistenți, nu o promisiune că fiecare protocol sau flux de autentificare va funcționa. Citiți-o ca pe un meniu al lucrurilor de verificat, nu ca pe o garanție de compatibilitate.

Apoi potriviți integrarea cu protocolul aprobat al gateway-ului. Cuvântul Cisco nu vă spune dacă aveți nevoie de o conexiune în stil vpnc vechi sau de un flux compatibil cu AnyConnect, iar alegerea greșită produce o eroare de autentificare care pare o problemă de credențiale.

Dacă atât un asistent independent, cât și ConnMan pot ridica tunelul, decideți care dintre ele deține rutele, DNS-ul și ciclul de viață înainte ca vreunul să pornească.

Setările daemonului nu sunt setările furnizorului

Configurația generală a daemonului și configurația unui furnizor individual sunt fișiere diferite cu formate diferite. În aranjamentul documentat pentru bookworm, daemonul citește /etc/connman/connman-vpn.conf, în timp ce fișierele de provizionare ale furnizorilor se află sub /var/lib/connman-vpn/ cu un sufix .config. Plasarea unui profil OpenVPN în acel director nu îl transformă într-un fișier de provizionare ConnMan. Iar manualul furnizorului pentru această versiune descrie secțiunile furnizorului și câmpurile specifice tipului de care acele fișiere au nevoie cu adevărat.

Traduceți doar prin maparea acceptată a integrării instalate. Încrederea în certificat, referințele la cheia privată, identitatea gateway-ului, rutele și intrările de autentificare își păstrează fiecare rolul, iar un exemplu pentru un alt tip de furnizor nu este interschimbabil doar pentru că ambele au nevoie de o adresă de server.

Când un furnizor nu se încarcă, comparați câmpurile lui cu manualul pentru versiunea instalată, nu cu un exemplu de pe un blog.

Agentul de autentificare este o dependență separată

O definiție de furnizor poate avea în continuare nevoie de un agent pentru a obține credențiale sau a finaliza un schimb de autentificare. Pentru integrarea sa cu OpenConnect, același manual explică faptul că valorile lipsă legate de autentificare pot fi cerute prin VPN Agent API și că un cookie de scurtă durată nu este în general potrivit ca secret permanent de configurație. Acel mecanism nu garantează suport pentru fiecare autentificare în browser, cerere MFA sau verificare a stării gateway-ului. Confirmați întregul flux cu persoana care deține implementarea.

Nu compensați un agent absent scriind o parolă sau un token de sesiune într-un fișier ușor de citit. Asta transformă o integrare lipsă într-o expunere de credențiale, iar a doua problemă supraviețuiește primeia.

Dacă gateway-ul necesită o autentificare interactivă, agentul face parte din proiect, nu este un supliment opțional.

Verificați patru rezultate, nu unul

După o provizionare autorizată, verificați patru lucruri separat: furnizorul este selectat, conexiunea este autentificată, rutele efective sunt cele pe care le-ați intenționat și resolverul se comportă conform așteptărilor. Un daemon care rulează, un furnizor listat și o aplicație care își atinge resursa sunt trei rezultate diferite, iar doar ultimul este scopul real al utilizatorului. Înregistrarea lor separat vă spune ce etapă trebuie reparată.

Includeți în acea verificare comportamentul de reconectare și politica necesară pentru starea de indisponibilitate, pentru că un tunel care se ridică o dată și nu se recuperează niciodată nu este implementat. Păstrați recuperabilă configurația de rețea de bază care funcționează în timp ce schimbați integrarea VPN.

Înlocuirea managerului Wi-Fi pentru a obține un buton este o schimbare mult mai mare decât operația lipsă care era necesară, și de obicei mitul câștigă.