Check Point VPN op Linux: SNX is nie iets wat jy aflaai en installeer nie

Jy gaan soek na die Check Point Linux-kliënt, en daar is geen aflaai-bladsy met 'n installeerder daarop nie. Daardie afwesigheid is nie 'n leemte in die verpakking nie. Check Point se Linux-kliënt vir afstandtoegang is SSL Network Extender, SNX, en die gateway gee dit vir jou nadat jy in 'n blaaier geverifieer het. Sodra dit duidelik is, maak die res van die verwarring sin, insluitend waarom byna elke inskrywing daaroor jare oud is.

Die mite: daar is 'n kliënt wat jy aflaai en installeer

Die verwagting kom van elke ander verskaffer. OpenVPN, WireGuard en die meeste kommersiële kliënte publiseer 'n pakket of 'n bewaarplek, en om een te installeer is 'n plaaslike besluit wat jy alleen neem. Check Point werk nie so vir Linux nie. Daar is geen selfstandige installeerder in die amptelike aflaaie vir huidige gateway-weergawes nie, so om na een te soek lewer ou forum-drade en derdeparty-spieëls op.

Daardie spieëls is erger as nutteloos, want die bou moet by die gateway pas wat dit bedien.

Wat SNX werklik is, en waar dit vandaan kom

SNX is 'n opdragreël-kliënt wie se binêre lêer snx is, en dit word geïnstalleer oor 'n sessie wat jy in die blaaier teen die gateway begin. Histories het 'n Java-applet dit afgelaai en geïnstalleer nadat jy die opdrag aanvaar het. Die meganisme het oor die jare verander, die bron nie. Die gateway bedien die bou wat by homself pas, en daarom volg kliënt- en gateway-weergawes mekaar, en waarom 'n kliënt wat uit 'n ou pakket gekopieer is net werk terwyl die gateway nog met hom praat.

Dit beteken ook die gateway moet gereed wees voordat enige kliëntwerk saak maak. Mobile Access Software Blade moet gelisensieer en opgestel wees, want daarsonder is daar geen portaal om van te installeer nie. Geen hoeveelheid werk aan die kliëntkant lewer 'n sessie teen 'n gateway wat nie een bied nie.

Rig die kliënt na die gateway met jou gebruiker, en lees wat dit rapporteer:

snx -s vpn.example.com -u your.name

Verspreidingsondersteuning is die beperking, nie die installeerder nie

Die verskaffer se lys van ondersteunde verspreidings vir SNX is kort en oud. In die gepubliseerde artikel stop dit omtrent by Ubuntu 17.04, saam met 'n paar openSUSE-, Fedora- en RHEL-weergawes uit dieselfde era, en dit lys steeds Ubuntu 12.10. Dit sê vir jou hoe die lys verouder, nie wat jou masjien nodig het nie. 'n Hedendaagse verspreiding is eenvoudig nie daarop nie.

Verwag biblioteek-verskille voordat jy 'n werkende tonnel verwag. Die gewone drie is ontbrekende 32-bis biblioteke op 'n 64-bis stelsel, 'n OpenSSL-weergawe waarteen die binêre lêer nooit gekoppel is nie, en 'n kernmodule wat die kliënt probeer bou. Lees die ontbrekende simbole eerder as om na pakkette te raai:

ldd $(command -v snx) | grep "not found"

Kontroleer dan die ondersteuningsartikel vir die gateway-weergawe waaraan jy werklik koppel. 'n Blog se lys is nie 'n versoenbaarheidsverklaring nie, en 'n nuwer verspreiding beteken nie 'n nuwer kliënt nie.

Die X11-besonderheid wat werk sonder skerm moontlik maak

SNX het X11-biblioteke nodig, maar nie 'n lopende X-bediener nie. Daardie onderskeid is die hele verskil tussen 'n kliënt wat oor SSH op 'n masjien sonder skerm werk en een wat lyk of dit hang sonder uitset. Installeer die biblioteekpakket wat jou verspreiding voorsien eerder as 'n bondel wat uit 'n ander weergawe gekopieer is, en hardloop die kliënt uit die sessie wat die tonnel nodig het.

Nadat dit koppel,lees die koppelvlak en die roetes voordat jy enige van die twee vertrou:

ip -brief addr show
ip route show

SNX skep 'n tonnel-koppelvlak en installeer die roetes wat die portaal bepaal. Daardie roetes is die gateway se besluit eerder as joune, so 'n ontbrekende voorvoegsel is 'n profielprobleem aan die gateway-kant en nie 'n fout in die kliënt nie. Kontroleer DNS terselfdertyd, want split-tonnel-profiele stuur dikwels 'n oplosser wat jy nie verwag het nie.

Wanneer SNX heeltemal die verkeerde antwoord is

Check Point-gateways kan ook IPsec- enL2TP-kliënt-tot-terrein-verbindings termineer, en dié werk met strongSwan, Libreswan of NetworkManager se L2TP-inprop. Dit is 'n gateway-opstelling, nie 'n kliënt-truuk nie. As die gateway net die Mobile Access-portaal publiseer,het 'n IPsec-kliënt niks om mee te onderhandel nie, en die log wys 'n tydsverloop in plaas van 'n verifikasiefout. Vra watter afstandtoegang-blaaie geaktiveer is voordat jy enigiets anders installeer.

Elke beperking hier lê aan die gateway-kant: die blad, die lisensie, die kliëntbou en die roeteprofiel. Die CLI werk al jare. Wat breek, is die aanname dat Linux-ondersteuning 'n pakket beteken wat jy besit en beheer.