Hvorfor en OpenVPN-profil ikke kan importeres i SoftEther

To filer som begge ser ut som VPN-konfigurasjon havner i samme mappe, og bare én av dem virker. OpenVPN-profilen beskriver en TLS-tunnel med direktiver som den klienten forstår, mens en SoftEther-tilkobling beskriver en sesjon mot en virtuell hub med en annen autentiseringskontrakt. Å gjøre om den ene til den andre er ikke en formateringsøvelse, fordi de to klientene ikke implementerer samme protokoll. Å fastslå hvilken tjeneste operatøren faktisk publiserte avgjør alt som følger.

To filer, to kontrakter

En OpenVPN-profil er en klientkonfigurasjon: et eksternt endepunkt, en transport, TLS-materiale og direktiver for ruting og reforhandling. En SoftEther-tilkobling er en opprinnelig klientsesjon mot en virtuell hub, med en virtuell adapter festet til den.

De kan beskrive tilgang til samme nettverk uten å være utskiftbare. OpenVPN-lytteren er en kompatibilitetsfunksjon som serveren kan publisere på en egen port, og den snakker OpenVPN i stedet for den opprinnelige protokollen. Den opprinnelige klienten snakker den opprinnelige protokollen og forventer sin egen profil. Én server, to dører, og hver dør har sin egen nøkkel.

Filendelsen forteller deg nesten ingenting, derfor er operatørens svar viktigere enn filnavnet.

Les serveren før du rører en sertifikatblokk

Spør operatøren om tre ting: hvilken port og transport, hvilken autentiseringsmetode og hvilken klient de forventer at du bruker. De svarene fjerner det meste av gjettingen.

Bekreft deretter hva som faktisk lytter, i stedet for hva en veiledning påstår. En deaktivert kompatibilitetslytter viser ingenting på porten sin, og en aktivert viser en socket selv når ingen noen gang har koblet til. Forskjellen mellom en lukket port og en avvist innlogging er den første nyttige diagnosen. Alt etterpå avhenger av hvilken dør det ble 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 som mangler på lytterlisten er en deaktivert funksjon og ikke et brannmurproblem.

Hva den opprinnelige klienten trenger og en profil ikke kan gi den

Den opprinnelige klienten installerer en virtuell nettverksadapter og binder en tilkobling til den. Uten den adapteren finnes det ingen grensesnitt å rute gjennom, og derfor kan en opprinnelig tilkobling autentisere og likevel ikke føre trafikk.

Opprinnelig autentisering går mot en virtuell hub, med et brukerobjekt som hubadministratoren opprettet. Sertifikatblokker kopiert fra en OpenVPN-profil blir ikke hub-brukere, og en hub-bruker blir ikke et klient sertifikat. De to systemene lagrer forskjellige ting, og en profil har ingen steder å legge hubens brukerpost. Det er en strukturell forskjell og ikke et syntaksproblem.

Hold den private nøkkelen unna enhver konverteringstjeneste, fordi en nøkkel som forlater maskinen må behandles som avslørt.

Hva den OpenVPN-kompatible lytteren godtar

Kompatibilitetslytteren er en ekte OpenVPN-server fra klientens ståsted: den forventer en OpenVPN-klient og de direktivene den klienten støtter. Innebygde sertifikatblokker er en OpenVPN-funksjon, og de hører til den siden av gjerdet.

Det den ikke gjør, er å godta en opprinnelig SoftEther-profil, fordi den profilen ikke er en OpenVPN-konfigurasjon. Lytteren gjør heller ikke den opprinnelige klienten om til en OpenVPN-klient. Hvis operatøren bare tilbyr den opprinnelige tjenesten, er svaret den opprinnelige klienten; hvis de tilbyr kompatibilitetslytteren, er svaret OpenVPN og dets eget materiale.

Be om operatørens støttede eksport i stedet for å sette sammen en av fragmenter, fordi eksporten bærer detaljer som en håndbygd fil vanligvis overser.

Bevis stien før du redigerer direktiver

Når klienten er valgt, test tunnelen før du rører ruter. En vellykket innlogging og et grensesnitt som fører trafikk er to forskjellige 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 adressen med utvalget operatøren beskrev, og se deretter på ruter og oppløser hver for seg. En opprinnelig hub-tilkobling kan autentisere rent og ikke installere noen ruter i det hele tatt, noe som fra klientsiden ser ut som en ødelagt tunnel. Først når disse tre stemmer, er det verdt å redigere et direktiv. Tidligere redigering skjuler hvilket lag som var feil.