Kerio VPN-kliento en Linux: kvin kontroloj laŭ ordo

Post instalo de la Kerio VPN-kliento en Linux aperas neniu labortabla ikono, kaj la privata reto restas ekster atingopovo. Tio estas la normala formo de tiu ĉi kliento, ne rompita instalo: la instrukcioj de GFI por Linux priskribas agordon per komandlinio kaj servan skripton, tute sen GUI. Trapasu la sekvajn kontrolojn laŭ ordo, ĉar ĉiu forigas alian tavolon. La unua malsukceso diras al vi, kie halti, kaj antaŭensalti kutime signifas rekonstrui pakaĵon, kiu neniam estis la problemo.

Konfirmu, ke la konstruo kongruas kun la maŝino

Komencu per tio, kion dpkg opinias la maŝino esti kaj por kio la pakaĵo estis konstruita. Sur normala 64-bita sistemo, dpkg --print-architecture eligas amd64, kaj la paĝo de la vendinto listigas amd64-pakaĵon apud la ordinara Debian-pakaĵo. Legu la eldonan ĉenon en la dosiernomo, kiun vi efektive instalis, anstataŭ supozi, ke la du kongruas.

Arĥivo el 2013, konstruita por i386, ne iĝas 64-bita nur ĉar vi transdonis --force-architecture ĉe la instalo. Trudi ĝin instalas fremdajn binaraĵojn, kaŝas dependan malsukceson malantaŭ lanĉilo, kiu tamen startas, kaj povas lasi la demonon ŝarĝi la malĝustajn bibliotekojn. Se via eldono nur haveblas kiel 32-bita, rulu ĝin en 32-bita medio aŭ petu de la posedanto de la enirejo aktualan konstruon.

Kontrolu ankaŭ la dependan linion. dpkg -s kerio-control-vpnclient | grep -i depends montras, kion la pakaĵo atendas, kaj neplenumita versia limigo aŭ mankanta rultempa biblioteko aperas ĉi tie, ne en la klienta protokolo.

Agordu ĝin per la paka asistanto

Laŭdezajne la kliento havas neniun eron en la aplikaĵa dosierujo, do mankanta ikono diras nenion pri tio, ĉu la agordo sukcesis. Remalfermu la asistanton per sudo dpkg-reconfigure kerio-control-vpnclient kaj respondu ĝiajn demandojn: VPN-finpunkto, kontaj detaloj kaj la fingrospuro de la servila atestilo.

Traktu la fingrospuran demandon kiel la solan lokon, kie malĝusta servilo povas venki. Komparu la valoron kun la servila informo de la administranto, kiu funkciigas la enirejon, ne kun tio, kion la finpunkto prezentas. Akcepti fingrospuron, kiun vi ne povas kontroli, igas la reston de tiu ĉi listo ornamaĵo, ĉar malamika servilo aspektas identa al la vera, post kiam la fingrospuro estas konservita. Se la valoro ne povas esti konfirmita per alia kanalo, haltu kaj demandu, eĉ kiam la tunelo alie ekfunkcius.

Ree ruli la asistanton ŝanĝas la agordon kaj povas restartigi la klienton, do tenu duan vojon al la maŝino, kiam la sesio, per kiu vi laboras, dependas de tiu VPN. Tajpu la pasvorton ĉe la normala invito anstataŭ enigi ĝin en komandon, kiu finiĝas en la ŝela historio.

Konu la dosieron, kiun la asistanto skribas

La agordo loĝas en /etc/kerio-kvc.conf kaj portas kaj la konton kaj la fiksitan fingrospuron. Traktu ĝin kiel sekretan materialon. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ne devus montri ĝin kiel legeblan por ĉiuj.

Post rajtigita mana redakto, reŝarĝu la demonon, kiu posedas la dosieron, anstataŭ restartigi la retan stakon: sudo /etc/init.d/kerio-kvc reload. Reŝargo relegas la agordon kaj forĵetas la nunan sesion, do ĝi ne estas neniofarado ĉe viva konekto.

Kopiu la antaŭan dosieron antaŭ ol ŝanĝi ion ajn. Se aŭtentigo malsukcesas post redakto, restarigi la lastan funkciantan kopion daŭras sekundojn kaj izolas la redakton de la reto, kio estas la plej malmultekosta maniero ekscii, kiu el la du moviĝis.

Apartigu la vivan sesion de la praŝarga konduto

La serva skripto regas la nunan konekton: sudo /etc/init.d/kerio-kvc stop finas la tunelon nun kaj start reportas ĝin. Neniu el la du komandoj decidas, kio okazos ĉe la sekva praŝargo, kaj tiu diferenco gravas sur maŝino, kiun vi administras distance.

Esploru, kiu posedas la startigon, antaŭ ol forigi ligilojn aŭ kaŝi ion. La pakaĵo povas instali sian propran init-skripton, generi unit aŭ fari ambaŭ, kaj malŝalti la malĝustan nomon lasas la klienton reaperi post restarto. Kontrolu systemctl status kerio-kvc kontraŭ la nomo, kiun la paka dokumentaro uzas, kaj poste malŝaltu la vojon, kiun la praŝarga procedo efektive legas.

Ne anstataŭigu OpenVPN-unit nur ĉar la agordo aspektas simila. Tiu ĉi kliento parolas sian propran protokolon kun la Kerio-enirejo, do alia demono direktita al la sama dosiero ne aŭtentigos, kaj la plia malsukceso igas la pruvojn pli malfacile legeblaj. La Linux-kliento de GFI ankaŭ tenas nur unu VPN-konekton samtempe; tiu limo validas por la kliento, ne por la uzantokapacito de la enirejo.

Legu la protokolojn, poste kontrolu la rimedon

Tri dosieroj sub /var/log/kerio-kvc rakontas la historion de la demono: init.log por vivciklaj eventoj, error.log por kritikaj malsukcesoj kaj debug.log por detaloj. Legu la plej malgrandan eltiraĵon, kiu respondas vian demandon, kaj forigu finpunktojn kaj uzantnomojn antaŭ ol alglui ĝin ie ajn. Manko en init.log ĉirkaŭ la tempo, kiam vi rulis la asistanton, diras al vi, ke la demono neniam restartis.

Valida pakaĵo, funkcianta demono kaj atingebla rimedo estas tri apartaj rezultoj, kaj la listo finiĝas nur kiam ĉiuj tri validas. Post aprobita ŝanĝo, petu gastigan maŝinon, kiu ekzistas nur malantaŭ la enirejo, kaj poste malfermu normalan servon sur ĝi. Se la tunelo funkcias kaj la rimedo ne, la restanta fuŝo sidas en enireja vojo aŭ fajroŝirma regulo, ne en la kliento, kiun vi ĵus reagordis.

Notu la staton, en kiu vi finiĝis: paka eldono, arĥitekturo, ĉu la fingrospuro estis kontrolita per alia kanalo, kaj kiun reŝargon aŭ restarton vi rulis. Tiu noto estas tio, kio igas la unuan kontrolon de la sekva persono malmultekosta.