Kial OpenVPN-profilaĵo ne enportiĝas en SoftEther

Du dosieroj, kiuj ambaŭ aspektas kiel VPN-agordo, alvenas en la saman dosierujon, kaj nur unu el ili funkcias. La OpenVPN-profilaĵo priskribas TLS-tunelon kun direktivoj, kiujn tiu kliento komprenas, dum SoftEther-konekto priskribas sesion kontraŭ virtuala nodo kun malsama aŭtentiga kontrakto. Konverti unu en la alian ne estas formatiga ekzerco, ĉar la du klientoj ne efektivigas la saman protokolon. Identigi, kiun servon la administranto efektive publikigis, decidas ĉion, kio sekvas.

Du dosieroj, du kontraktoj

OpenVPN-profilaĵo estas klienta agordo: fora finpunkto, transporto, TLS-materialo kaj direktivoj por enkursigado kaj renegocado. SoftEther-konekto estas denaska klienta sesio kontraŭ virtuala nodo, kun virtuala adaptilo alkroĉita al ĝi.

Ili povas priskribi aliron al la sama reto sen esti interŝanĝeblaj. La OpenVPN-aŭskultilo estas kongrueca funkcio, kiun la servilo povas publikigi sur aparta pordo, kaj ĝi parolas OpenVPN anstataŭ la denaskan protokolon. La denaska kliento parolas la denaskan protokolon kaj atendas sian propran profilaĵon. Unu servilo, du pordegoj, kaj ĉiu pordego havas sian propran ŝlosilon.

La dosiera finaĵo preskaŭ nenion diras al vi, kaj tial la respondo de la administranto pli gravas ol la nomo de la dosiero.

Legu la servilon antaŭ ol tuŝi atestilan blokon

Demandu la administranton tri aferojn: kiun pordon kaj transporton, kiun aŭtentigan metodon, kaj kiun klienton ili atendas, ke vi uzu. Tiuj respondoj forigas plejparton de la konjektado.

Poste konfirmu, kio efektive aŭskultas, anstataŭ kion asertas gvidilo. Malŝaltita kongrueca aŭskultilo montras nenion sur sia pordo, kaj ŝaltita montras ingon eĉ kiam neniu iam ajn konektiĝis. La diferenco inter fermita pordo kaj rifuzita saluto estas la unua utila diagnozo. Ĉio post tio dependas de tio, kiun pordon oni frapis.

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

UDP-pordo mankanta en la aŭskultila listo estas malŝaltita funkcio, ne fajroŝirma problemo.

Kion la denaska kliento bezonas kaj profilaĵo ne povas doni

La denaska kliento instalas virtualan retadaptilon kaj ligas konekton al ĝi. Sen tiu adaptilo ne ekzistas interfaco por enkursigi, kaj tial denaska konekto povas aŭtentiĝi kaj tamen porti neniun trafikon.

La denaska aŭtentigo funkcias kontraŭ virtuala nodo, kun uzanta objekto kiun kreis la noda administranto. Atestilaj blokoj kopiitaj el OpenVPN-profilaĵo ne fariĝas nodaj uzantoj, kaj noda uzanto ne fariĝas klienta atestilo. La du sistemoj konservas malsamajn aferojn, kaj profilaĵo havas nenie lokon por la uzanta registro de la nodo. Tio estas struktura diferenco, ne sintaksa problemo.

Tenu la privatan ŝlosilon for de ajna konverta servo, ĉar ŝlosilo, kiu forlasas la maŝinon, devas esti traktata kiel malkaŝita.

Kion akceptas la OpenVPN-kongrua aŭskultilo

La kongrueca aŭskultilo estas vera OpenVPN-servilo el la vidpunkto de la kliento: ĝi atendas OpenVPN-klienton kaj la direktivojn, kiujn tiu kliento subtenas. Enliniaj atestilaj blokoj estas OpenVPN-funkcio, kaj ili apartenas al tiu flanko de la barilo.

Kion ĝi ne faros, estas akcepti denaskan SoftEther-profilaĵon, ĉar tiu profilaĵo ne estas OpenVPN-agordo. La aŭskultilo ankaŭ ne ŝanĝas la denaskan klienton en OpenVPN-klienton. Se la administranto proponas nur la denaskan servon, la respondo estas la denaska kliento; se li proponas la kongruecan aŭskultilon, la respondo estas OpenVPN kaj ĝia propra materialo.

Petu la subtenatan eksportaĵon de la administranto anstataŭ kunmeti unu el fragmentoj, ĉar la eksportaĵo portas detalojn, kiujn permane farita dosiero kutime preterlasas.

Pruvu la vojon antaŭ ol redakti direktivojn

Post kiam la kliento elektiĝis, testu la tunelon antaŭ ol tuŝi itinerojn. Sukcesa saluto kaj interfaco, kiu portas trafikon, estas du malsamaj rezultoj.

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

Komparu la atribuitan adreson kun la naĝejo, kiun la administranto priskribis, poste rigardu itinerojn kaj solvilon aparte. Denaska noda konekto povas aŭtentiĝi pure kaj instali neniujn itinerojn, kio el la klienta flanko aspektas kiel rompita tunelo. Nur post kiam tiuj tri kongruas, indas redakti direktivon. Pli frua redaktado kaŝas, kiu tavolo estis malĝusta.