Paano bumuo ng profile ng kliyente ng OpenVPN mula sa mga inilabas na file

Ibinibigay ng inyong operator ang isang bundle ng CA, sertipiko ng kliyente at ang key nito, at hindi magsisimula ang kliyente hanggang maisaksak ang mga ito sa isang profile. Ang profile ay configuration: itinuturo nito ang mga file na iyon, hindi ito naglalaman ng mga iyon, at hindi ito magiging sertipiko sa pag-edit. Nagsisimula ang gabay sa isang laptop na aprubado na at nagtatapos sa isang profile na maisisimulan mo mula sa kilalang direktoryo. Hindi ito gumagawa ng CA, hindi nagrerehistro ng bagong sertipiko at hindi hinahawakan ang server.

Ang target dito ay isang kliyente sa command line na OpenVPN 2.6 para sa Linux, naka-route sa TUN sa ibabaw ng UDP, may authentication na sertipiko.

Tipunin lamang ang mga file sa panig ng kliyente

Magtrabaho sa isang protektadong direktoryo at tipunin ang aprubadong materyal ng pagtitiwala sa CA, ang inilabas na sertipiko ng kliyente at ang pribadong key na tumutugma rito. Sa halimbawang ito ang mga pangalan ay ca.crt, laptop-a.crt at laptop-a.key. Mga label lamang ang mga pangalan ng file; wala silang sinasabi tungkol sa nilalaman ng bawat file.

Kung ginawa mo ang key noong pagpapatala, hindi ito kailanman umalis sa makina; mula sa naglabas, ang pinirmahang sertipiko at ang pampublikong chain lamang ang dapat bumalik. Suriin kung dala ng sertipiko ang papel ng kliyente na inaasahan ng serbisyo. Suriin din kung ang key ay pag-aari ng sertipikong iyon at hindi ng mas lumang sertipiko mula sa dating pagtatangka. Ang pares na hindi magkatugma ay nagdudulot ng pagpalya ng TLS nang mas huli, na mukhang problema ng server.

Iwanan sa labas ng package na ito ang pribadong signing key ng CA, ang pribadong key ng server at ang mga parameter ng DH.

Ikonekta ang mga file sa isang maliit na profile

Ang profile sa ibaba ay sadyang maikli. Ang bawat linya ay pumipili ng endpoint, naglilimita sa pagkakakilanlang tatanggapin ng kliyente, o itinuturo ang isa sa tatlong file.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

Pinipili ng linyang remote ang endpoint ng network. Iginiit ng remote-cert-tls server na magpakita ang kabilang panig ng sertipikong may papel ng server. Ipinipin ng verify-x509-name ang inaasahang pangalan, dito ang vpn-gateway bilang Common Name ng sertipiko ng server kasama ang default na field ng pangalan ng OpenVPN. Ang halagang iyon ay hindi hinuhulaan mula sa hostname ng DNS, kaya gamitin ang scheme ng pagkakakilanlan na ibinigay ng operator.

Huwag iwaksi ang mga pagsusuring iyon dahil lamang may ibang sertipiko ang isang test endpoint.

Ipinapalagay ng base profile na ito na walang hiwalay na hamon sa account at walang key sa control channel. Kung kailangan ng serbisyo ang auth-user-pass, tls-auth o tls-crypt, itago ang configuration at ang materyal na ibinigay sa iyo, dahil ang lihim ng control channel na ikaw mismo ang gumawa ay hindi tutugma sa nasa server. Itago rin ang patakaran sa cipher ng serbisyo sa halip na mag-import ng mga linya ng compression o cipher mula sa lumang halimbawa.

Gawing tahasan ang working directory

Ang mga relatibong path ay sumusunod sa working directory ng proseso, hindi sa lokasyon ng file na .ovpn.

Nakapagtataka iyon sa mga naglilipat ng profile sa bagong folder at umaasang susunod ang key. Para sa direktoryong pinili ng administrator, lumilipat ang utos sa ibaba sa isang absolutong path bago basahin ang profile at ang mga sanggunian nito.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

Maaaring i-package ng isang wizard sa pag-import sa desktop o ng isang serbisyo ng system ang mga dependency para sa iyo at maglapat ng sarili nitong mga patakaran. Maaari rin itong gumamit ng ibang working directory kaysa sa tinest mo. Tiyakin kung paano nire-resolve ng paraan ng paglunsad mo ang mga path ng key, sertipiko at CA. Ang paglipat lamang ng file na .ovpn ay hindi naglilipat ng hiwalay na pribadong key.

Panatilihing nababasa ang key para lamang sa nilalayong user o pagkakakilanlan ng serbisyo.

I-verify ang paghahatid, hindi ang mga pangalan ng file

Bago ang unang awtorisadong koneksyon, suriin ang endpoint, ang pagkakakilanlan ng sertipiko, ang naglabas at ang panahon ng bisa. Pagkatapos, tiyakin na ang mga sanggunian sa file ay nire-resolve mula sa working directory na talagang gagamitin mo. Pagkatapos kumonekta, subukan ang pag-uugali ng application at DNS na dapat ibigay ng patakaran sa routing. Tatlong nababasang file ay walang pinapatunayan tungkol sa awtorisasyon ng server o sa magagamit na landas ng resource.

Kung may lumabas na hiling ng passphrase, ito ay para sa pribadong key, hindi sa account ng VPN.

Panghuli, i-inventory ang package bilang materyal ng kredensyal. Ang pagbibigay ng parehong sertipiko at key sa ikalawang laptop ay kinokopya ang pagkakakilanlan, at ang pagpapalit ng pangalan ng file ay hindi nagbibigay sa iyo ng ikalawang pagpapatala. Iyon ang pagkakaiba ng pagbuo ng profile at ng paglalabas nito.