Waarom ’n OpenVPN-profiel nie in SoftEther ingevoer kan word nie

Twee lêers wat albei soos VPN-konfigurasie lyk, beland in dieselfde gids, en net een van hulle werk. Die OpenVPN-profiel beskryf ’n TLS-tonnel met opdragte wat daardie kliënt verstaan, terwyl ’n SoftEther-verbinding ’n sessie teen ’n virtuele hub beskryf met ’n ander stawingskontrak. Om die een in die ander te omskep is nie ’n formaat-oefening nie, want die twee kliënte implementeer nie dieselfde protokol nie. Om te bepaal watter diens die operateur werklik gepubliseer het, bepaal alles wat volg.

Twee lêers, twee kontrakte

’n OpenVPN-profiel is ’n kliëntkonfigurasie: ’n afgeleë eindpunt, ’n transport, TLS-materiaal en opdragte vir roetering en heronderhandeling. ’n SoftEther-verbinding is ’n inheemse kliëntsessie teen ’n virtuele hub, met ’n virtuele adapter daaraan gekoppel.

Hulle kan toegang tot dieselfde netwerk beskryf sonder om uitruilbaar te wees. Die OpenVPN-luisteraar is ’n versoenbaarheidsfunksie wat die bediener op ’n aparte poort kan publiseer, en dit praat OpenVPN eerder as die inheemse protokol. Die inheemse kliënt praat die inheemse protokol en verwag sy eie profiel. Een bediener, twee voordeure, en elke deur het sy eie sleutel.

Die lêeruitbreiding sê jou byna niks, en daarom is die operateur se antwoord belangriker as die lêer se naam.

Lees die bediener voordat jy ’n sertifikaatblok aanraak

Vra die operateur drie dinge: watter poort en transport, watter stawingsmetode, en watter kliënt hulle verwag jy moet gebruik. Daardie antwoorde verwyder die meeste raaiwerk.

Bevestig dan wat werklik luister, eerder as wat ’n gids beweer. ’n Versoenbaarheidsluisteraar wat gedeaktiveer is, wys niks op sy poort nie, en ’n geaktiveerde een wys ’n sok selfs wanneer niemand ooit gekoppel het nie. Die verskil tussen ’n geslote poort en ’n geweierde aanmelding is die eerste nuttige diagnose. Alles daarna hang daarvan af watter deur geklop is.

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

’n UDP-poort wat in die luisteraarlys ontbreek, is ’n gedeaktiveerde funksie eerder as ’n brandmuurprobleem.

Wat die inheemse kliënt nodig het en ’n profiel nie kan gee nie

Die inheemse kliënt installeer ’n virtuele netwerkadapter en bind ’n verbinding daaraan. Sonder daardie adapter is daar geen koppelvlak om deur te roeteer nie, en daarom kan ’n inheemse verbinding staaf en steeds geen verkeer dra nie.

Inheemse stawing loop teen ’n virtuele hub, met ’n gebruikersobjek wat die hub-administrateur geskep het. Sertifikaatblokke wat uit ’n OpenVPN-profiel gekopieer is, word nie hub-gebruikers nie, en ’n hub-gebruiker word nie ’n kliëntsertifikaat nie. Die twee stelsels stoor verskillende dinge, en ’n profiel het nêrens om die hub se gebruikerrekord te plaas nie. Dit is ’n strukturele verskil eerder as ’n sintaksprobleem.

Hou die private sleutel uit enige omskakelingsdiens, want ’n sleutel wat die masjien verlaat, moet as bekendgemaak beskou word.

Wat die OpenVPN-versoenbare luisteraar aanvaar

Die versoenbaarheidsluisteraar is vanuit die kliënt se oogpunt ’n egte OpenVPN-bediener: dit verwag ’n OpenVPN-kliënt en die opdragte wat daardie kliënt ondersteun. Inlyn sertifikaatblokke is ’n OpenVPN-kenmerk, en hulle hoort aan daardie kant van die heining.

Wat dit nie sal doen nie, is om ’n inheemse SoftEther-profiel te aanvaar, want daardie profiel is nie ’n OpenVPN-konfigurasie nie. Die luisteraar verander ook nie die inheemse kliënt in ’n OpenVPN-kliënt nie. As die operateur net die inheemse diens bied, is die antwoord die inheemse kliënt; as hulle die versoenbaarheidsluisteraar bied, is die antwoord OpenVPN en sy eie materiaal.

Vra vir die operateur se ondersteunde uitvoer eerder as om een uit fragmente saam te stel, want die uitvoer dra besonderhede wat ’n handgeboude lêer gewoonlik mis.

Bewys die pad voordat jy opdragte wysig

Sodra die kliënt gekies is, toets die tonnel voordat jy roetes aanraak. ’n Aanmelding wat slaag en ’n koppelvlak wat verkeer dra, is twee verskillende resultate.

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

Vergelyk die toegewysde adres met die poel wat die operateur beskryf het, en kyk dan afsonderlik na roetes en oplosser. ’n Inheemse hub-verbinding kan skoon staaf en glad geen roetes installeer nie, wat van die kliënt se kant soos ’n stukkende tonnel lyk. Eers nadat daardie drie ooreenstem, is dit die moeite werd om ’n opdrag te wysig. Om vroeër te wysig, verberg watter laag verkeerd was.