SNX pe Linux: biblioteci pe 32 de biți și un resolver care se resetează

SNX pe Linux eșuează la încărcător, la tabela de rutare sau la resolver, iar fiecare dintre aceste defecțiuni arată ca o problemă de autentificare. Parcurgeți cele patru simptome în ordine.

SSL Network Extender de la Check Point eșuează pe Linux în patru moduri recognoscibile, iar trei dintre ele sunt citite greșit ca o problemă de autentificare. Fie binarul nu pornește, fie pornește și nu lasă nicio rută, fie se conectează și rezolvarea numelor moare, fie portalul din browser funcționează în timp ce linia de comandă nu. Parcurgeți-le în această ordine, pentru că fiecare este condiția de intrare pentru următorul.

Simptomul unu: încărcătorul refuză înainte de autentificare

Instalatorul descărcat de pe firewall plasează un binar pe 32 de biți cu setuid-root în /usr/bin/snx. Pe o distribuție pe 64 de biți nu rulează până când arhitectura i386 nu este activată și bibliotecile față de care se leagă nu există.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

O listă not found goală este poarta pentru tot ce urmează. Setul exact de pachete se schimbă între versiuni: un raport funcțional avea nevoie de libstdc++5:i386, libx11-6:i386 și libpam0g:i386, altul avea nevoie și de libstdc++6:i386. Citiți ldd în loc să copiați o listă de pachete dintr-un tutorial scris pentru altă distribuție.

Dacă snx nu este găsit deloc, instalatorul nu s-a finalizat niciodată sau s-a instalat undeva în afara PATH-ului dumneavoastră. Aceasta este o altă defecțiune și merită confirmată înainte de a adăuga arhitecturi sistemului. Verificați cu command -v snx și uitați-vă în directorul raportat de instalator. Adăugarea de pachete i386 pe o mașină unde binarul pur și simplu lipsește nu repară nimic.

Simptomul doi: autentificarea reușește și nimic nu este rutat

O autentificare reușită creează tunsnx și editează singură tabela de rutare, așa că verificați ce există de fapt înainte de a schimba orice altceva.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Folosiți snx -d pentru demontare. Oprirea procesului lasă în urmă interfața și rutele ei, iar următoarea încercare eșuează apoi dintr-un motiv care nu are nimic de-a face cu credențialele. Prima autentificare înregistrează și o semnătură de server sub /etc/snx/, motiv pentru care un script nesupravegheat poate avea nevoie de o execuție interactivă înainte de a funcționa deloc. Ștergeți acea stare doar când intenționați să reaprobați serverul.

Simptomul trei: numele se rezolvă până când tunelul urcă

Acesta este cel care se strică în liniște. snx scrie serverele DNS împinse direct în /etc/resolv.conf. Unde acea cale este o legătură simbolică în /run/systemd/resolve/, modificarea se poate pierde la următorul eveniment al resolverului, iar după o deconectare intrările împinse pot la fel de bine să rămână.

Funcționează două aranjamente, iar alegerea ar trebui să fie deliberată și nu cea sugerată de primul rezultat al căutării:

  • Preluați fișierul: înlocuiți legătura simbolică cu un fișier static și instalați libnss-resolve împreună cu varianta sa i386, astfel încât serviciul de nume să aibă în continuare o rezervă când fișierul este rescris dedesubt.
  • Păstrați systemd-resolved ca proprietar și înregistrați legătura tunelului: resolvectl dns tunsnx 10.0.0.10, apoi resolvectl domain tunsnx corp.example, și confirmați cu resolvectl status.

Notați serverele de nume dinaintea VPN-ului înainte de a vă conecta. Dacă editați fișierul manual, eliminarea ulterioară a intrărilor împinse face parte din procedură, nu este curățare opțională, pentru că un laptop care păstrează DNS-ul corporativ după deconectare nu va putea rezolva nimic altceva.

Simptomul patru: portalul funcționează și CLI-ul nu

Versiunile recente ale firewall-ului au mutat middleware-ul din browser într-un demon Java local, așa că portalul vorbește cu un agent local pe portul 14186. Acea adresă are nevoie de o excepție de certificat în browser și de un proces care rulează.

ps ax | grep cshell
/usr/bin/cshell/launcher

Linia de comandă este o cale separată: snx -s vpn.example.com -u user, cu ~/.snxrc care păstrează serverul, numele de utilizator și preferința de reautentificare. O sesiune de portal funcțională nu spune nimic despre dacă CLI-ul este instalat corect, iar clientul gol nu gestionează coduri de unică folosință.

Scurtătura prin container care costă mai mult decât economisește

snx verifică modulul tun, îl încarcă atunci când lipsește, creează o interfață de tunel, rescrie rutele și împinge traficul prin ea. Reproducerea acestui lucru într-un container înseamnă montarea /dev și /lib/modules și acordarea unor capacități largi, ceea ce predă containerului cea mai mare parte a administrării rețelei gazdei.

Când este cu adevărat nevoie de un sandbox, o mașină virtuală este granița mai curată: clientul primește un kernel pe care îl poate modifica, iar gazda își păstrează tabela de rutare. Alegeți asta înainte de a petrece o după-amiază pe capacități pe care veți regreta că le-ați acordat.

Articole similare