Native na kliyente ng SoftEther o profile ng OpenVPN: piliin ang tamang port

Maaaring sumagot ang isang SoftEther server sa native na SSL port at sa port na katugma ng OpenVPN nang sabay, kaya ang dalawa ay mukhang isang serbisyo na may dalawang pinto. Dalawang serbisyo sila na may magkaibang kliyente, magkaibang pormat ng konfigurasyon at magkaibang kakayahan. Ang paglalagay ng native na profile sa isang OpenVPN client ay nabibigo sa pag-parse, at bihirang sabihin ng error kung bakit.

Piliin muna ang tagapakinig, pagkatapos ang kliyente.

Dalawang tagapakinig, dalawang pormat ng konfigurasyon

Gumagamit ang native na protocol ng SoftEther client at isang depinisyon ng koneksyon na nagpangalan sa server, port, virtual hub at user. Inaasahan ng tagapakinig na katugma ng OpenVPN ang isang OpenVPN profile na may remote directive, TLS material at mga opsyon mula sa mas maliit na sinusuportahang set kaysa sa ibinibigay ng standalone na OpenVPN server. Tinatawag ito ng SoftEther na function ng clone ng OpenVPN, at ang clone ay kapaki-pakinabang na bakas tungkol sa katapatan.

Ang pagiging tugma ay tanong ng bersyon. Suriin kung ano ang tinatanggap ng naka-deploy na build, hindi kung ano ang dokumentado ng kasalukuyang manwal ng OpenVPN.

Hakbang 1: alamin kung aling tagapakinig ang pinagana ng operator

Humingi ng listahan ng tagapakinig sa halip na hulaan mula sa numero ng port. Ang server na sumasagot ng TLS sa 443 ay hindi laging OpenVPN endpoint, dahil maaaring gamitin ng native na protocol ang parehong port. Inilalarawan ng seksyon ng manwal tungkol sa mga katugmang function ng server kung aling mga clone ang umiiral at paano sila pinapagana.

Kung maaari mong maabot ang host, subukan ang port na ibinigay sa iyo, hindi ang port mula sa tutorial: openssl s_client -connect vpn.example.com:443 -brief hindi bababa sa sinasabi nito kung may TLS.

Hakbang 2: gamitin ang tugmang kliyente at profile

Para sa native na access, i-install ang SoftEther client, gumawa ng koneksyon gamit ang mga detalye ng operator at ikonekta ang virtual adapter. Para sa katugmang tagapakinig, i-import ang OpenVPN profile na inilabas ng operator mula sa server, dahil dala nito ang CA at kliyenteng materyal na inaasahan ng tagapakinig na iyon. Huwag magbuo ng profile nang manu-mano mula sa pangkalahatang halimbawa, at huwag i-paste ang native na depinisyon ng koneksyon sa konfigurasyon ng OpenVPN.

Ang error sa pag-parse kapag nag-import ay problema sa pormat, hindi problema sa network, at hindi ka dapat nitong ipadala sa firewall.

Hakbang 3: panatilihing tapat ang paghahambing

Kung ipinapahayag ng operator ang dalawa, ihambing ang mga ito habang ang aparato, network ng access at gawain ay hindi nagbabago. Maaaring magkaiba ang dalawang landas sa authentication, sa mga subnet na kinokonektahan nila at sa ginagawa ng server pagkatapos sa iyong trapiko. Ang pinagsasaluhang host ay hindi pinagsasaluhang patakaran. Panatilihing hindi rin nagbabago ang gawain, dahil ang pagkopya ng file at video call ay nagbibigay ng presyon sa magkaibang bahagi ng parehong landas.

Labanan ang mga pagwawasto na lumilitaw tuwing nabibigo ang pag-import. Ang pag-disable ng mga pagsusuri ng sertipiko o pag-enable ng lumang cipher upang pilitin ang isang profile ay pag-urong, hindi tampok ng pagiging tugma.

Hakbang 4: i-verify ang landas pagkatapos kumonekta

Kapag nakakonekta na, suriin ang address na natanggap mo, ang mga ruta na kasama nito, DNS at isang panloob na mapagkukunan. Sa native na panig, ang virtual adapter ang interface na dapat siyasatin; sa panig ng OpenVPN, ito ang tun o tap na aparatong ginawa ng kliyente. Alinman, ang tanong ay kung ibinibigay ng tagapakinig na pinili mo ang access na kailangan mo, na isang hiwalay na katotohanan sa kung bumangon ang tunnel. Isulat ang address bago at pagkatapos, at ihambing ang mga ito.

Itala kung aling tagapakinig at aling bersyon ng kliyente ang gumawa ng gumaganang resulta. Kung hindi, uulitin ng susunod na tao ang pagtuklas mula sa numero ng port pataas.