SNX op Linux: 32-bis biblioteke en ’n oplosser wat terugstel

SNX op Linux misluk by die laaier, die roetetabel of die oplosser, en elkeen van dié foute lyk soos ’n aanmeldprobleem. Werk die vier simptome in volgorde deur.

Check Point se SSL Network Extender misluk op Linux op vier herkenbare maniere, en drie daarvan word verkeerd as ’n aanmeldprobleem gelees. Die program begin nie, of dit begin en laat geen roete nie, of dit verbind en naamoplossing sterf, of die blaaierportaal werk terwyl die opdragreël dit nie doen nie. Werk hulle in daardie volgorde deur, want elkeen is die toegangsvoorwaarde vir die volgende.

Simptoom een: die laaier weier voor die aanmelding

Die installeerder wat van die firewall af kom, los ’n 32-bis, setuid-root program by /usr/bin/snx. Op ’n 64-bis verspreiding loop dit nie voordat die i386-argitektuur geaktiveer is en die biblioteke waarteen dit skakel, bestaan nie.

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"

’n Leë not found-lys is die hek vir alles daarna. Die presiese pakketversameling wissel tussen vrystellings: een werkende verslag het libstdc++5:i386, libx11-6:i386 en libpam0g:i386 nodig gehad, ’n ander het ook libstdc++6:i386 nodig gehad. Lees ldd eerder as om ’n pakketlys uit ’n gids vir ’n ander verspreiding na te skryf.

As snx glad nie gevind word nie, het die installeerder nooit voltooi nie of het dit iewers buite jou PATH geïnstalleer. Dit is ’n ander faling, en dit is die moeite werd om dit te bevestig voordat jy argitekture by die stelsel voeg. Kontroleer met command -v snx en kyk in die gids wat die installeerder gerapporteer het. Om i386-pakkette by ’n masjien te voeg waar die program bloot afwesig is, maak niks reg nie.

Simptoom twee: die aanmelding slaag en niks word gerouteer nie

’n Suksesvolle aanmelding skep tunsnx en wysig self die roetetabel, so kyk wat werklik bestaan voordat jy enigiets anders verander.

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

Gebruik snx -d vir die afbreek. Om die proses te dood laat die koppelvlak en sy roetes agter, en die volgende poging misluk dan om ’n rede wat niks met geloofsbriewe te doen het nie. Die eerste aanmelding teken ook ’n bedienerhandtekening onder /etc/snx/, en daarom het ’n onbewaakte skrip dalk een interaktiewe lopie nodig voordat dit hoegenaamd kan werk. Skrap daardie toestand net wanneer jy van plan is om die bediener weer goed te keur.

Simptoom drie: name los op totdat die tonnel opkom

Dit is die een wat stil-stil breek. snx skryf gestuurde DNS-bediener in /etc/resolv.conf in. Waar daardie pad ’n simskakel na /run/systemd/resolve/ is, kan die wysiging by die volgende oplossergebeurtenis verlore gaan, en ná ’n ontkoppeling kan die gestuurde inskrywings net sowel agterbly.

Twee reëlings werk, en die keuse moet doelbewus wees eerder as wat die eerste soekresultaat voorgestel het:

  • Neem die lêer oor: vervang die simskakel met ’n statiese lêer en installeer libnss-resolve plus sy i386-variant, sodat naamdiens steeds ’n terugval het wanneer die lêer onder hom herskryf word.
  • Hou systemd-resolved as die eienaar en registreer die tonnelskakel: resolvectl dns tunsnx 10.0.0.10, dan resolvectl domain tunsnx corp.example, en bevestig met resolvectl status.

Teken die DNS-bediener voor die VPN aan voordat jy koppel. As jy die lêer met die hand wysig, is die verwydering van die gestuurde inskrywings daarna deel van die prosedure, nie opsionele opruiming nie, want ’n skootrekenaar wat korporatiewe DNS ná ontkoppeling behou, sal niks anders kan oplos nie.

Simptoom vier: die portaal werk en die CLI nie

Onlangse firewall-vrystellings het die middleware uit die blaaier na ’n plaaslike Java-daemon geskuif, so die portaal praat met ’n plaaslike agent op poort 14186. Daardie adres het ’n blaaier-sertifikaatvrystelling en ’n lopende proses nodig.

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

Die opdragreël is ’n aparte pad: snx -s vpn.example.com -u user, met ~/.snxrc wat die bediener, gebruikersnaam en heraanmeldingvoorkeur hou. ’n Werkende portaal-sessie sê niks oor of die CLI korrek geïnstalleer is nie, en die kaal kliënt hanteer nie eenmalige kodes nie.

Die houer-kortpad wat meer kos as wat dit spaar

snx kyk vir die tun-module, laai dit wanneer dit afwesig is, skep ’n tonnelkoppelvlak, herskryf roetes en stuur verkeer daardeur. Om dit binne ’n houer na te boots beteken om /dev en /lib/modules te monteer en wye vermoëns toe te ken, wat die houer die meeste van die gasheer se netwerkadministrasie gee.

Wanneer ’n sandput werklik nodig is, is ’n virtuele masjien die skoner grens: die kliënt kry ’n kern wat hy mag wysig, en die gasheer behou sy roetetabel. Kies dit voordat jy ’n middag spandeer op vermoëns wat jy sal berou dat jy toegestaan het.

Verwante artikels