Hvorfor en OpenVPN-profil ikke kan importeres i SoftEther

To filer, der begge ser ud som VPN-konfiguration, ender i samme mappe, og kun én af dem virker. OpenVPN-profilen beskriver en TLS-tunnel med direktiver, som den klient forstår, mens en SoftEther-forbindelse beskriver en session mod et virtuelt hub med en anden autentificeringskontrakt. At konvertere den ene til den anden er ikke en formateringsøvelse, fordi de to klienter ikke implementerer samme protokol. Det at fastslå, hvilken tjeneste operatøren faktisk har udgivet, afgør alt, hvad der følger.

To filer, to kontrakter

En OpenVPN-profil er en klientkonfiguration: et fjernt endepunkt, en transport, TLS-materiale og direktiver til routing og genforhandling. En SoftEther-forbindelse er en oprindelig klientsession mod et virtuelt hub med en virtuel adapter knyttet til sig.

De kan beskrive adgang til det samme netværk uden at være udskiftelige. OpenVPN-lytteren er en kompatibilitetsfunktion, som serveren kan udgive på en separat port, og den taler OpenVPN i stedet for den oprindelige protokol. Den oprindelige klient taler den oprindelige protokol og forventer sin egen profil. Én server, to døre, og hver dør har sin egen nøgle.

Filendelsen fortæller dig næsten intet, og derfor er operatørens svar vigtigere end filens navn.

Læs serveren, før du rører en certifikatblok

Spørg operatøren om tre ting: hvilken port og transport, hvilken autentificeringsmetode og hvilken klient de forventer, du bruger. De svar fjerner det meste af gætteriet.

Bekræft derefter, hvad der faktisk lytter, i stedet for hvad en guide påstår. En deaktiveret kompatibilitetslytter viser intet på sin port, og en aktiveret viser en socket, selv når ingen nogensinde har forbundet. Forskellen mellem en lukket port og et afvist login er den første nyttige diagnostik. Alt derefter afhænger af, hvilken dør der blev banket på.

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

En UDP-port, der mangler på lytterlisten, er en deaktiveret funktion og ikke et firewall-problem.

Hvad den oprindelige klient har brug for, og en profil ikke kan give den

Den oprindelige klient installerer en virtuel netværksadapter og binder en forbindelse til den. Uden den adapter er der ingen grænseflade at route igennem, og derfor kan en oprindelig forbindelse autentificere og stadig ikke føre trafik.

Den oprindelige autentificering kører mod et virtuelt hub, med et brugerobjekt som hub-administratoren har oprettet. Certifikatblokke kopieret fra en OpenVPN-profil bliver ikke hub-brugere, og en hub-bruger bliver ikke et klientcertifikat. De to systemer gemmer forskellige ting, og en profil har ingen steder at lægge hubbens brugerpost. Det er en strukturel forskel og ikke et syntaksproblem.

Hold den private nøgle væk fra enhver konverteringstjeneste, fordi en nøgle, der forlader maskinen, skal behandles som afsløret.

Hvad den OpenVPN-kompatible lytter accepterer

Kompatibilitetslytteren er en rigtig OpenVPN-server fra klientens synspunkt: den forventer en OpenVPN-klient og de direktiver, som den klient understøtter. Indlejrede certifikatblokke er en OpenVPN-funktion, og de hører til den side af hegnet.

Det, den ikke gør, er at acceptere en oprindelig SoftEther-profil, fordi den profil ikke er en OpenVPN-konfiguration. Lytteren gør heller ikke den oprindelige klient til en OpenVPN-klient. Hvis operatøren kun tilbyder den oprindelige tjeneste, er svaret den oprindelige klient; hvis de tilbyder kompatibilitetslytteren, er svaret OpenVPN og dets eget materiale.

Bed om operatørens understøttede eksport i stedet for at samle en af fragmenter, da eksporten bærer detaljer, som en håndbygget fil normalt overser.

Bevis stien, før du redigerer direktiver

Når klienten er valgt, test tunnelen, før du rører ruter. Et vellykket login og en grænseflade, der fører trafik, er to forskellige resultater.

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

Sammenlign den tildelte adresse med den pulje, operatøren beskrev, og se derefter på ruter og resolver hver for sig. En oprindelig hub-forbindelse kan autentificere rent og slet ikke installere nogen ruter, hvilket fra klientsiden ser ud som en brudt tunnel. Kun når de tre stemmer overens, er det værd at redigere et direktiv. Tidligere redigering skjuler, hvilket lag der var forkert.