Kerio VPN client sa Linux: limang pagsusuri nang sunud-sunod

Pagkatapos i-install ang Kerio VPN client sa Linux, walang icon na lumalabas sa desktop at nananatiling hindi maabot ang pribadong network. Ito ang normal na anyo ng client na ito, hindi sirang install: inilalarawan ng mga tagubilin ng GFI para sa Linux ang pagkakumpigura sa command line at isang service script, na walang GUI. Sundin ang mga pagsusuri sa ibaba nang sunud-sunod, dahil bawat isa ay nag-aalis ng ibang layer. Ang unang pagkabigo ang nagsasabi kung saan hihinto, at ang paglundag sa unahan ay karaniwang nangangahulugang muling pagbuo ng paketeng hindi kailanman naging problema.

Tiyakin na tumutugma ang build sa makina

Magsimula sa kung ano ang dpkg iniisip tungkol sa makina at para saan ginawa ang pakete. Sa normal na 64-bit na sistema, dpkg --print-architecture ay nagpi-print ng amd64, at ang pahina ng vendor ay naglilista ng amd64 na pakete sa tabi ng karaniwang Debian na pakete. Basahin ang release string sa pangalan ng file na aktuwal mong ini-install sa halip na ipagpalagay na tugma ang dalawa.

Ang archive mula 2013 na ginawa para sa i386 ay hindi nagiging 64-bit dahil lang sa ipinasa mo ang --force-architecture noong pag-install. Ang pagpilit dito ay naglalagay ng dayuhang binary, nagtatago ng pagkabigo ng dependency sa likod ng launcher na tumatakbo pa rin, at maaaring hayaang mag-load ang daemon ng maling library. Kung ang release mo ay 32-bit lamang, patakbuhin ito sa 32-bit na environment o humingi ng bagong build sa may-ari ng gateway.

Suriin din ang linya ng dependency. dpkg -s kerio-control-vpnclient | grep -i depends ay nagpapakita kung ano ang inaasahan ng pakete, at ang hindi natugunang version pin o kulang na runtime library ay lumalabas dito, hindi sa log ng client.

I-configure ito sa pamamagitan ng wizard ng pakete

Sa disenyo, walang entry ang client sa app drawer, kaya ang kulang na icon ay walang sinasabi tungkol sa tagumpay ng pagkakumpigura. Buksan muli ang wizard gamit ang sudo dpkg-reconfigure kerio-control-vpnclient at sagutin ang mga tanong nito: VPN endpoint, detalye ng account at fingerprint ng sertipiko ng server.

Ituring ang tanong sa fingerprint bilang ang tanging lugar kung saan maaaring manalo ang maling server. Ihambing ang halaga sa impormasyon ng server mula sa administrator na nagpapatakbo ng gateway, hindi sa ipinapakita ng endpoint. Ang pagtanggap ng fingerprint na hindi mo maaaring i-verify ay ginagawang dekorasyon ang natitirang bahagi ng listahang ito, dahil ang galit na server ay mukhang kapareho ng tunay kapag na-save na ang pin. Kung hindi makumpirma ang halaga sa ibang channel, huminto at magtanong, kahit na aangat pa rin ang tunnel.

Ang muling pagpapatakbo ng wizard ay nagbabago ng configuration at maaaring i-restart ang client, kaya panatilihin ang pangalawang daan patungo sa makina kapag ang session na ginagamit mo ay umaasa sa VPN na iyon. I-type ang password sa normal na prompt sa halip na isingit ito sa command na mapupunta sa shell history.

Kilalanin ang file na isinusulat ng wizard

Ang configuration ay nasa /etc/kerio-kvc.conf at nagdadala ng account at ng naka-pin na fingerprint. Ituring itong lihim na materyal. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ay hindi dapat ipakita ito bilang nababasa ng lahat.

Pagkatapos ng awtorisadong manu-manong pag-edit, i-reload ang daemon na may-ari ng file sa halip na i-restart ang network stack: sudo /etc/init.d/kerio-kvc reload. Ang reload ay muling nagbabasa ng configuration at inaalis ang kasalukuyang session, kaya hindi ito walang epekto sa buhay na koneksyon.

Kopyahin ang nakaraang file bago ka magbago ng kahit ano. Kung mabigo ang authentication pagkatapos ng edit, ang pagbabalik sa huling gumaganang kopya ay tumatagal ng segundo at inihihiwalay ang edit sa network, na siyang pinakamurang paraan upang malaman kung alin sa dalawa ang gumalaw.

Ihiwalay ang buhay na session sa ugali sa boot

Kinokontrol ng service script ang kasalukuyang koneksyon: sudo /etc/init.d/kerio-kvc stop tinatapos ang tunnel ngayon at start ibinabalik ito. Wala sa dalawang command ang nagpapasya kung ano ang mangyayari sa susunod na boot, at mahalaga ang pagkakaibang iyon sa makinang pinangangasiwaan mo nang malayuan.

Alamin kung sino ang may-ari ng startup bago mag-alis ng link o magtago ng anuman. Maaaring mag-install ang pakete ng sariling init script, bumuo ng unit, o pareho, at ang pag-disable ng maling pangalan ay nagbabalik sa client pagkatapos ng reboot. Suriin ang systemctl status kerio-kvc laban sa pangalan na ginagamit ng dokumentasyon ng pakete, pagkatapos i-disable ang path na aktuwal na binabasa ng boot process.

Huwag palitan ang unit ng OpenVPN dahil lang sa magkatulad ang configuration. Ang client na ito ay nagsasalita ng sariling protocol sa Kerio gateway, kaya ang ibang daemon na nakaturo sa parehong file ay hindi magpapatunay, at ang dagdag na pagkabigo ay nagpapahirap sa pagbasa ng ebidensya. Ang GFI client para sa Linux ay may isang VPN connection lamang sa isang pagkakataon; ang limitasyong iyon ay para sa client, hindi sa kapasidad ng user ng gateway.

Basahin ang mga log, pagkatapos i-verify ang resource

Tatlong file sa ilalim ng /var/log/kerio-kvc ang nagsasalita ng kuwento ng daemon: init.log para sa mga lifecycle event, error.log para sa mga kritikal na pagkabigo at debug.log para sa detalye. Basahin ang pinakamaliit na sipi na sumasagot sa tanong mo, at alisin ang endpoints at username bago ito i-paste kahit saan. Ang puwang sa init.log sa paligid ng oras na pinatakbo mo ang wizard ay nagsasabi na hindi kailanman nag-restart ang daemon.

Ang wastong pakete, tumatakbong daemon at maaabot na resource ay tatlong magkahiwalay na resulta, at ang listahan ay kumpleto lamang kapag hawak ang tatlo. Pagkatapos ng aprubadong pagbabago, humingi ng host na umiiral lamang sa likod ng gateway, pagkatapos buksan ang normal na serbisyo dito. Kung nakataas ang tunnel at wala ang resource, ang natitirang fault ay nasa ruta ng gateway o patakaran ng firewall, hindi sa client na kakumpigura mo lang.

Itala ang kalagayang hinantungan mo: release ng pakete, arkitektura, kung na-verify ang fingerprint sa ibang channel, at aling reload o restart ang ginawa mo. Ang talaang iyon ang nagpapamura sa unang pagsusuri ng susunod na tao.