Dalawang file na parehong mukhang VPN configuration ang napupunta sa parehong folder, at isa lang sa kanila ang gumagana. Inilalarawan ng OpenVPN profile ang isang TLS tunnel na may mga direktiba na nauunawaan ng client na iyon, samantalang inilalarawan ng koneksyon ng SoftEther ang isang session laban sa isang virtual hub na may ibang kontrata ng pagpapatunay. Ang pag-convert ng isa sa isa ay hindi pagsasanay sa pag-format, dahil hindi ipinapatupad ng dalawang client ang parehong protocol. Ang pagtukoy kung aling serbisyo ang aktwal na inilathala ng operator ang nagtatakda ng lahat ng sumusunod.

Dalawang File, Dalawang Kontrata

Ang OpenVPN profile ay isang configuration ng client: isang malayong endpoint, isang transport, TLS material, at mga direktiba para sa routing at muling negosasyon. Ang koneksyon ng SoftEther ay isang native na session ng client laban sa isang virtual hub, na may virtual adapter na nakakabit dito.

Maaari nilang ilarawan ang pag-access sa parehong network nang hindi mapagpapalit. Ang OpenVPN listener ay isang feature ng compatibility na maaaring ilathala ng server sa hiwalay na port, at nagsasalita ito ng OpenVPN sa halip na ang native protocol. Ang native client ay nagsasalita ng native protocol at inaasahan ang sarili nitong profile. Isang server, dalawang pinto, at bawat pinto ay may sariling key.

Halos walang sinasabi sa iyo ang extension ng file, kaya mas mahalaga ang sagot ng operator kaysa sa pangalan ng file.

Basahin ang Server Bago Hipuin ang Block ng Sertipiko

Tanungin ang operator ng tatlong bagay: aling port at transport, aling paraan ng pagpapatunay, at aling client ang inaasahan nilang gamitin mo. Ang mga sagot na iyon ay nag-aalis ng karamihan sa hula.

Pagkatapos ay kumpirmahin kung ano talaga ang nakikinig, hindi kung ano ang sinasabi ng isang gabay. Ang naka-disable na compatibility listener ay walang ipinapakita sa port nito, at ang naka-enable ay nagpapakita ng socket kahit wala pang kailanman kumonekta. Ang pagkakaiba ng saradong port at tinanggihang login ang unang kapaki-pakinabang na diagnosis. Ang lahat pagkatapos ay depende sa kung aling pinto ang kinatok.

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

Ang UDP port na kulang sa listahan ng listener ay isang naka-disable na feature, hindi problema sa firewall.

Ano ang Kailangan ng Native Client na Hindi Maibibigay ng Profile

Nag-i-install ang native client ng virtual network adapter at itinatali ang koneksyon dito. Kung wala ang adapter na iyon ay walang interface na madadaanan ng routing, kaya ang native na koneksyon ay maaaring makapasa sa pagpapatunay at gayunpaman ay walang dalang trapiko.

Ang native na pagpapatunay ay nangyayari laban sa isang virtual hub, gamit ang object ng user na ginawa ng administrator ng hub. Ang mga block ng sertipiko na kinopya mula sa OpenVPN profile ay hindi nagiging user ng hub, at ang user ng hub ay hindi nagiging sertipiko ng client. Magkaiba ang itinatago ng dalawang sistema, at ang profile ay walang lugar na paglalagyan ng talaan ng user ng hub. Iyon ay pagkakaiba sa istruktura at hindi problema sa sintaks.

Ilayo ang pribadong key sa anumang serbisyo ng conversion, dahil ang key na umaalis sa makina ay dapat ituring na nabunyag.

Ano ang Tinatanggap ng Listener na Compatible sa OpenVPN

Ang compatibility listener ay isang tunay na OpenVPN server mula sa pananaw ng client: inaasahan nito ang isang OpenVPN client at ang mga direktibang sinusuportahan ng client na iyon. Ang mga inline na block ng sertipiko ay feature ng OpenVPN, at kabilang sila sa ganoong bahagi ng bakod.

Ang hindi nito gagawin ay ang tumanggap ng native na SoftEther profile, dahil ang profile na iyon ay hindi configuration ng OpenVPN. Hindi rin ginagawang OpenVPN client ng listener ang native client. Kung ang operator ay nag-aalok lamang ng native na serbisyo, ang sagot ay ang native client; kung nag-aalok ito ng compatibility listener, ang sagot ay OpenVPN at ang sarili nitong materyal.

Humingi ng sinusuportahang export ng operator sa halip na magtipon ng isa mula sa mga piraso, dahil ang export ay may dalang mga detalye na karaniwang nilalaktawan ng ginawang kamay na file.

Patunayan ang Landas Bago I-edit ang mga Direktiba

Kapag napili na ang client, subukan ang tunnel bago hipuin ang mga ruta. Ang matagumpay na login at interface na nagdadala ng trapiko ay dalawang magkaibang resulta.

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

Ihambing ang itinalagang address sa pool na inilarawan ng operator, pagkatapos ay tingnan nang hiwalay ang mga ruta at ang resolver. Ang native na koneksyon sa hub ay maaaring malinis na makapasa sa pagpapatunay at walang mai-install na ruta, na mula sa panig ng client ay mukhang sirang tunnel. Pagkatapos lamang magtugma ang tatlong iyon ay sulit nang i-edit ang isang direktiba. Ang pag-edit nang mas maaga ay nagtatago kung aling layer ang mali.

Kaugnay na mga artikulo