Clientul Kerio VPN pe Linux: cinci verificări în ordine

După instalarea clientului Kerio VPN pe Linux nu apare nicio pictogramă pe desktop și rețeaua privată rămâne în afara razei de acțiune. Aceasta este forma normală a acestui client, nu o instalare defectă: instrucțiunile GFI pentru Linux descriu configurarea din linia de comandă și un script de serviciu, fără nicio interfață grafică. Parcurgeți verificările de mai jos în ordine, pentru că fiecare înlătură un alt strat. Prima eșuare vă spune unde să vă opriți, iar sărirea înainte înseamnă de obicei reconstruirea unui pachet care nu a fost niciodată problema.

Confirmați că build-ul se potrivește cu mașina

Începeți cu ceea ce dpkg crede despre mașină și pentru ce a fost construit pachetul. Pe un sistem normal de 64 de biți, dpkg --print-architecture afișează amd64, iar pagina furnizorului listează un pachet amd64 lângă pachetul Debian obișnuit. Citiți șirul versiunii din numele fișierului pe care l-ați instalat efectiv, în loc să presupuneți că cele două coincid.

O arhivă din 2013 construită pentru i386 nu devine de 64 de biți doar pentru că ați transmis --force-architecture la instalare. Forțarea instalează binare străine, ascunde o eroare de dependență în spatele unui lansator care tot pornește și poate lăsa demonul să încarce bibliotecile greșite. Dacă versiunea pe care o aveți există doar pe 32 de biți, rulați-o într-un mediu pe 32 de biți sau cereți proprietarului gateway-ului un build actual.

Verificați și linia dependențelor. dpkg -s kerio-control-vpnclient | grep -i depends arată ce așteaptă pachetul, iar o restricție de versiune neîndeplinită sau o bibliotecă de execuție lipsă apar aici, nu în jurnalul clientului.

Configurați-l cu asistentul pachetului

Prin proiectare, clientul nu are nicio intrare în sertarul de aplicații, așa că o pictogramă lipsă nu spune nimic despre reușita configurării. Redeschideți asistentul cu sudo dpkg-reconfigure kerio-control-vpnclient și răspundeți la întrebările lui: punct final VPN, datele contului și amprenta certificatului serverului.

Tratați întrebarea despre amprentă ca singurul loc în care un server greșit poate câștiga. Comparați valoarea cu informațiile despre server date de administratorul care administrează gateway-ul, nu cu ce prezintă punctul final. Acceptarea unei amprente pe care nu o puteți verifica transformă restul listei în decor, pentru că un server ostil arată identic cu cel real după ce pinul este salvat. Dacă valoarea nu poate fi confirmată pe alt canal, opriți-vă și întrebați, chiar și atunci când tunelul s-ar ridica oricum.

Rerularea asistentului schimbă configurația și poate reporni clientul, așa că păstrați o a doua cale către mașină atunci când sesiunea pe care lucrați depinde de acel VPN. Tastați parola la solicitarea obișnuită în loc să o includeți într-o comandă care ajunge în istoricul shell-ului.

Cunoașteți fișierul pe care îl scrie asistentul

Configurația se află în /etc/kerio-kvc.conf și conține atât contul, cât și amprenta fixată. Tratați-o ca material secret. sudo stat -c '%a %U %G' /etc/kerio-kvc.conf nu ar trebui să o afișeze ca lizibilă pentru toți.

După o editare manuală autorizată, reîncărcați demonul care deține fișierul în loc să reporniți stiva de rețea: sudo /etc/init.d/kerio-kvc reload. O reîncărcare recitește configurația și renunță la sesiunea curentă, deci nu este o non-operațiune pe o conexiune activă.

Copiați fișierul anterior înainte de a schimba ceva. Dacă autentificarea eșuează după o editare, restaurarea ultimei copii bune durează secunde și izolează editarea de rețea, ceea ce este cea mai ieftină cale de a afla care dintre cele două s-a mișcat.

Separați sesiunea activă de comportamentul la pornire

Scriptul de serviciu controlează conexiunea curentă: sudo /etc/init.d/kerio-kvc stop încheie tunelul acum și start îl readuce. Niciuna dintre comenzi nu decide ce se întâmplă la următoarea pornire, iar diferența contează pe o mașină administrată de la distanță.

Verificați cine deține pornirea automată înainte de a elimina legături sau a masca ceva. Pachetul poate instala propriul script init, poate genera o unitate sau ambele, iar dezactivarea numelui greșit face clientul să revină după o repornire. Verificați systemctl status kerio-kvc față de numele folosit de documentația pachetului, apoi dezactivați calea pe care procesul de pornire o citește efectiv.

Nu înlocuiți o unitate OpenVPN doar pentru că configurația arată similar. Acest client vorbește propriul protocol cu gateway-ul Kerio, deci un alt demon îndreptat spre același fișier nu se va autentifica, iar eșecul suplimentar face dovezile mai greu de citit. Clientul GFI pentru Linux ține și o singură conexiune VPN odată; acea limită se aplică clientului, nu capacității de utilizatori a gateway-ului.

Citiți jurnalele, apoi verificați resursa

Trei fișiere în /var/log/kerio-kvc spun povestea demonului: init.log pentru evenimente de ciclu de viață, error.log pentru eșecuri critice și debug.log pentru detalii. Citiți cel mai mic fragment care răspunde la întrebarea dumneavoastră și eliminați punctele finale și numele de utilizator înainte de a-l lipi oriunde. O lacună în init.log în jurul orei la care ați rulat asistentul vă spune că demonul nu a fost niciodată repornit.

Un pachet valid, un demon în execuție și o resursă accesibilă sunt trei rezultate separate, iar lista se încheie doar când toate trei se verifică. După o modificare aprobată, cereți un host care există doar în spatele gateway-ului, apoi deschideți pe el un serviciu normal. Dacă tunelul este ridicat și resursa nu, defecțiunea rămasă este într-o rută a gateway-ului sau într-o regulă de firewall, nu în clientul pe care tocmai l-ați reconfigurat.

Notați starea în care ați terminat: versiunea pachetului, arhitectura, dacă amprenta a fost verificată pe alt canal și ce reîncărcare sau repornire ați executat. Acea notă este ceea ce face prima verificare a următoarei persoane ieftină.