Ang desk phone na kumokonekta sa VPN ng opisina ay isang pinamamahalaang endpoint na may sariling firmware, sariling pagkakakilanlan at sariling landas ng pagbawi. Ang embedded client ay hindi isang desktop na pag-install ng OpenVPN na may mas maliit na screen, at ang pagtrato dito nang ganoon ang dahilan kung bakit nagtatago ang telepono ng shared key at patakarang walang sinumang nag-apruba. Narito ang tunay na nangyayari sa pagitan ng telepono at ng gateway.

Ano ang nilo-load ng telepono sa boot

Basahin ang System Info sa device bago maghanda ng anuman. Tinutukoy ng administration guide ng GXP21xx ang bersyon ng programa bilang pangunahing firmware release at nagpapakita ng field ng status ng suporta sa OpenVPN, na nagsasabi kung ang build na mayroon ka ay nagsasabing may ganitong feature.

Pagkatapos ay inilalarawan ng guide ang dalawang mode ng configuration. Ang simpleng mode ay nagbibigay ng hiwalay na field: address ng server, port, transport at na-upload na certificate material. Ang expert mode ay tumatanggap ng configuration ZIP. Dalawang magkaibang landas ng pag-load ang mga ito patungo sa parehong client, at kasinghalaga ng nilalaman ang format ng bundle.

Ang paglalagay ng arbitraryong .ovpn file mula sa desktop sa isang ZIP ay hindi nagtatatag ng compatibility. Sinusuri ng telepono ang inaasahan ng firmware nito, at ang file na gumagana sa laptop ay maaaring tahimik na balewalain dito.

Ano ang dapat ipahayag ng client

Kunin muna ang mga kinakailangan ng profile mula sa operator ng gateway: endpoint, transport, peer verification, authentication, mga kailangang algorithm at ang mga pribadong resource na maaaring abutin ng telepono. Pagkatapos ay tingnan kung kayang ipahayag ng embedded implementation ang kontratang iyon.

Mahalaga ang pagkakasunod-sunod na ito dahil ang alternatibo ay baguhin ang shared gateway para sa isang telepono lamang. Bawat pagluwag na gagawin mo para sa telepono ay nalalapat sa bawat ibang client sa endpoint na iyon, at masamang kalakal iyon para sa device na tumatawag.

Kung ang sagot ay hindi kayang tuparin ng build ang patakaran, ang tapat na pagpipilian ay sinusuportahang firmware o device, o isang aprubadong kaayusan ng gateway para sa mga voice endpoint. Ang pagpapahina ng tunnel ay hindi isa sa mga ito.

Compression at mga lumang recipe

Ang mas lumang recipe para sa maliliit na device ay madalas na nagpapagana ng compression para makatipid ng bandwidth. Idinedeklara ng OpenVPN 2.6 na lipas na ang compression at sa pangkalahatan ay hindi ito inirerekomenda, kaya ang configuration na kinopya mula sa gayong recipe ay hindi kasalukuyang aprubasyon sa seguridad, anuman ang taon na isinulat ang post sa forum.

Ganoon din sa mga pagsusuri ng pagkakakilanlan. Kung ang isang profile ay kumokonekta lamang kapag naka-disable ang peer verification, ang profile ang problema, hindi ang verification. Ayusin ang trust material sa halip na turuan ang device na laktawan ang pagsusuri.

Isang device, isang pagkakakilanlan

Tatlong piraso ng materyal ang may tatlong tungkulin. Ang CA trust certificate ay nagpapahintulot sa telepono na i-verify ang issuer. Ang certificate ng telepono ay kumikilala sa device na ito. Ang private key ng telepono ay sensitibong materyal ng device at nananatili sa device.

Ang CA signing key ay hindi kailanman pag-aari ng telepono. Ganoon din ang laptop profile ng isang administrator na kinopya sa buong fleet, na ginagawang kredensyal para sa bawat telepono ang isang nakaw na telepono.

Ipinapakita rin ng guide ang password ng client key at opsyonal na field ng VPN username at password. Ang mga ito ay hindi awtomatikong kredensyal ng SIP extension. Magpasya sa kaayusan ng authentication para sa device na ito, kabilang kung paano ito nakakakuha ng anumang kinakailangang input pagkatapos ng restart na walang nagbabantay.

Ihatid ang materyal sa pamamagitan ng iyong protektadong proseso ng provisioning, at itala ang device, ang inisyung pagkakakilanlan at ang may-ari ng pagtanggal. Kapag pinalitan ang telepono, ang talaang iyon ang pagkakaiba ng limang minutong palitan at ng isang hapong puno ng hula.

Panatilihin ang landas ng administrasyon

Bago paganahin ang tunnel, kumpirmahin na maaabot mo pa rin ang web interface o ang landas ng provisioning ng telepono. Kailangan ng device ang ordinaryong access sa network para maabot ang endpoint ng VPN, at hindi dapat mawala ang landas ng pamamahala nito sa kalagitnaan ng enrollment.

Kung ang pagbabago ng ruta habang nag-e-enroll ay magkulong sa iyo sa labas, ang pagbawi ay karaniwang factory reset at pag-uulit ng buong proseso. Planuhin ang pagkakasunod-sunod para hindi ito mangyari: mag-provision, i-verify ang maabot, pagkatapos ay paganahin ang tunnel.

Tanggapin ang tawag, hindi ang tunnel

Ang SIP account ay nananatiling hiwalay na configuration. Itinuturo ng guide ng GXP21xx ang deployment ng OpenVPN sa setting ng VPN NAT-traversal ng account, kaya tingnan ang gabay na iyon para sa naka-install na firmware at sa iyong disenyo ng PBX sa halip na pagsamahin ang mga pagbabago sa STUN, proxy at VPN nang hindi alam kung sinong may-ari ang nangangailangan ng mga ito.

Pagkatapos ay i-verify ang inilalayong pangalan ng PBX at ang pribadong landas, kumpirmahin ang pagpaparehistro ng SIP, at gumawa ng aprubadong papasok at palabas na tawag na may audio na sinuri sa dalawang direksyon. Subukan ang mga feature ng tawag na talagang kailangan ng deployment, dahil ang indicator ng pagpaparehistro ay hindi gumaganang telepono.

Sa huli, ulitin mula sa kontroladong cold start at pagkatapos ng pagkaantala ng network. Obserbahan kung ibinabalik ng telepono ang tunnel, ang account at ang magagamit na tawag sa inilalayong pagkakasunod-sunod, at kumpirmahin ang ipinahayag na pag-uugali kapag hindi makakonekta ang tunnel. Ang administration guide ng GXP21xx ang sanggunian para sa mga field na inilarawan sa itaas.

Kaugnay na mga artikulo