De ce un profil OpenVPN nu se importă în SoftEther

Două fișiere care arată ambele ca o configurație VPN ajung în același dosar, și doar unul dintre ele funcționează. Profilul OpenVPN descrie un tunel TLS cu directive pe care acel client le înțelege, în timp ce o conexiune SoftEther descrie o sesiune împotriva unui hub virtual cu un alt contract de autentificare. A converti unul în celălalt nu este un exercițiu de formatare, pentru că cei doi clienți nu implementează același protocol. Identificarea serviciului pe care operatorul l-a publicat efectiv decide tot ce urmează.

Două fișiere, două contracte

Un profil OpenVPN este o configurație de client: un punct final la distanță, un transport, material TLS și directive pentru rutare și renegociere. O conexiune SoftEther este o sesiune de client nativ împotriva unui hub virtual, cu un adaptor virtual atașat la ea.

Ele pot descrie accesul la aceeași rețea fără a fi interschimbabile. Ascultătorul OpenVPN este o funcție de compatibilitate pe care serverul o poate publica pe un port separat, și vorbește OpenVPN în locul protocolului nativ. Clientul nativ vorbește protocolul nativ și așteaptă propriul profil. Un server, două uși, și fiecare ușă are propria cheie.

Extensia fișierului nu vă spune aproape nimic, de aceea răspunsul operatorului contează mai mult decât numele fișierului.

Citiți serverul înainte de a atinge un bloc de certificat

Întrebați operatorul trei lucruri: ce port și transport, ce metodă de autentificare și ce client se așteaptă să folosiți. Acele răspunsuri elimină cea mai mare parte a presupunerilor.

Apoi confirmați ce ascultă cu adevărat, nu ce afirmă un ghid. Un ascultător de compatibilitate dezactivat nu arată nimic pe portul său, iar unul activ arată un socket chiar și atunci când nimeni nu s-a conectat vreodată. Diferența dintre un port închis și o autentificare refuzată este primul diagnostic util. Tot ce urmează depinde de la ce ușă s-a bătut.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Un port UDP care lipsește din lista ascultătorilor este o funcție dezactivată, nu o problemă de firewall.

De ce are nevoie clientul nativ și ce nu-i poate da un profil

Clientul nativ instalează un adaptor de rețea virtual și leagă o conexiune de el. Fără acel adaptor nu există o interfață prin care să ruteze, de aceea o conexiune nativă se poate autentifica și totuși nu transporta trafic.

Autentificarea nativă rulează împotriva unui hub virtual, cu un obiect de utilizator creat de administratorul hubului. Blocurile de certificat copiate dintr-un profil OpenVPN nu devin utilizatori ai hubului, iar un utilizator al hubului nu devine certificat de client. Cele două sisteme stochează lucruri diferite, iar un profil nu are unde să pună înregistrarea de utilizator a hubului. Aceasta este o diferență structurală, nu o problemă de sintaxă.

Țineți cheia privată departe de orice serviciu de conversie, pentru că o cheie care părăsește mașina trebuie tratată ca divulgată.

Ce acceptă ascultătorul compatibil cu OpenVPN

Ascultătorul de compatibilitate este un server OpenVPN real din perspectiva clientului: așteaptă un client OpenVPN și directivele pe care acel client le acceptă. Blocurile de certificat inline sunt o funcție OpenVPN și aparțin acelei părți a gardului.

Ce nu va face este să accepte un profil SoftEther nativ, pentru că acel profil nu este o configurație OpenVPN. Ascultătorul nu transformă nici clientul nativ într-un client OpenVPN. Dacă operatorul oferă doar serviciul nativ, răspunsul este clientul nativ; dacă oferă ascultătorul de compatibilitate, răspunsul este OpenVPN și propriul său material.

Cereți exportul suportat al operatorului în loc să asamblați unul din fragmente, pentru că exportul poartă detalii pe care un fișier construit manual le omite de obicei.

Dovediți calea înainte de a edita directive

Odată ales clientul, testați tunelul înainte de a atinge rutele. O autentificare reușită și o interfață care transportă trafic sunt două rezultate diferite.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Comparați adresa atribuită cu grupul descris de operator, apoi priviți rutele și resolverul separat. O conexiune nativă la hub se poate autentifica curat și nu poate instala nicio rută, ceea ce din partea clientului arată ca un tunel rupt. Abia când aceste trei se potrivesc merită editată o directivă. Editarea mai devreme ascunde care strat era greșit.