SNX Linuxissa: 32-bittiset kirjastot ja nollautuva resolveri

Check Pointin SSL Network Extender epäonnistuu Linuxissa neljällä tunnistettavalla tavalla, ja kolme niistä luetaan väärin kirjautumisongelmaksi. Joko binääri ei käynnisty, tai se käynnistyy eikä jätä reittiä, tai se yhdistää ja nimien selvitys kuolee, tai selaimen portaali toimii, kun taas komentorivi ei. Käy ne läpi tässä järjestyksessä, koska jokainen on seuraavan edellytys.

Oire yksi: lataaja kieltäytyy ennen kirjautumista

Palomuurilta haettu asentaja pudottaa 32-bittisen setuid-root-binäärin kohtaan /usr/bin/snx. 64-bittisessä jakelussa se ei toimi, ennen kuin i386-arkkitehtuuri on otettu käyttöön ja kirjastot, joihin se linkittyy, ovat olemassa.

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"

Tyhjä not found-luettelo on portti kaikelle sen jälkeen tulevalle. Tarkka pakettijoukko vaihtuu julkaisujen välillä: yksi toimiva raportti tarvitsi paketit libstdc++5:i386, libx11-6:i386 ja libpam0g:i386, toinen tarvitsi myös paketin libstdc++6:i386. Lue ldd sen sijaan, että kopioisit pakettiluettelon toiselle jakelulle kirjoitetusta oppaasta.

Jos snx ei löydy lainkaan, asentaja ei koskaan valmistunut tai asensi jonnekin PATHisi ulkopuolelle. Se on eri vika, ja se kannattaa vahvistaa ennen kuin lisäät arkkitehtuureja järjestelmään. Tarkista command -v snx-komennolla ja katso hakemistosta, jonka asentaja ilmoitti. i386-pakettien lisääminen koneeseen, josta binääri yksinkertaisesti puuttuu, ei korjaa mitään.

Oire kaksi: kirjautuminen onnistuu eikä mikään reitity

Onnistunut kirjautuminen luo tunsnx-liitännän ja muokkaa reititystaulua itse, joten tarkista, mitä todella on olemassa, ennen kuin muutat mitään muuta.

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

Käytä purkamiseen snx -d-komentoa. Prosessin tappaminen jättää liitännän ja sen reitit jälkeensä, ja seuraava yritys epäonnistuu sitten syystä, jolla ei ole mitään tekemistä tunnistetietojen kanssa. Ensimmäinen kirjautuminen tallentaa myös palvelimen allekirjoituksen kohtaan /etc/snx/, minkä vuoksi valvomaton skripti voi tarvita yhden interaktiivisen ajon ennen kuin se ylipäätään toimii. Poista tuo tila vain, kun aiot hyväksyä palvelimen uudelleen.

Oire kolme: nimet selvitetään, kunnes tunneli nousee

Tämä on se, joka hajoaa hiljaa. snx kirjoittaa työnnetyt DNS-palvelimet suoraan tiedostoon /etc/resolv.conf. Kun polku on symbolinen linkki hakemistoon /run/systemd/resolve/, muokkaus voi kadota seuraavassa resolveritapahtumassa, ja yhteyden katkaisemisen jälkeen työnnetyt merkinnät voivat aivan yhtä hyvin jäädä paikoilleen.

Kaksi järjestelyä toimii, ja valinnan tulisi olla tietoinen eikä se, mitä ensimmäinen hakutulos ehdotti:

• Ota tiedosto haltuusi: korvaa symbolinen linkki staattisella tiedostolla ja asenna libnss-resolve sekä sen i386-variantti, jotta nimipalvelulla on vielä varakeino, kun tiedosto kirjoitetaan uudelleen sen alta.
• Pidä systemd-resolved omistajana ja rekisteröi tunnelin linkki: resolvectl dns tunsnx 10.0.0.10, sitten resolvectl domain tunsnx corp.example, ja vahvista komennolla resolvectl status.

Kirjaa VPN:ää edeltävät nimipalvelimet ennen yhdistämistä. Jos muokkaat tiedostoa käsin, työnnettyjen merkintöjen poistaminen jälkikäteen on osa menettelyä, ei valinnainen siivous, koska kannettava, joka pitää yrityksen DNS:n yhteyden katkaisemisen jälkeen, ei pysty selvittämään mitään muuta.

Oire neljä: portaali toimii eikä CLI toimi

Viimeaikaiset palomuurijulkaisut ovat siirtäneet väliohjelmiston selaimesta paikalliseen Java-daemoniin, joten portaali puhuu paikallisen agentin kanssa portissa 14186. Tämä osoite tarvitsee selaimen varmennepoikkeuksen ja käynnissä olevan prosessin.

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

Komentorivi on erillinen polku: snx -s vpn.example.com -u user, ja ~/.snxrc säilyttää palvelimen, käyttäjänimen ja uudelleentodennuksen asetuksen. Toimiva portaali-istunto ei kerro mitään siitä, onko CLI asennettu oikein, eikä pelkkä asiakasohjelma käsittele kertakäyttökoodeja.

Kontin oikotie, joka maksaa enemmän kuin säästää

snx tarkistaa tun-moduulin, lataa sen puuttuessa, luo tunneliliitännän, kirjoittaa reitit uudelleen ja työntää liikenteen sen läpi. Tämän toistaminen kontin sisällä tarkoittaa /dev ja /lib/modules hakemistojen liittämistä ja laajojen oikeuksien myöntämistä, mikä antaa kontille suurimman osan isännän verkkohallinnasta.

Kun hiekkalaatikko on todella tarpeen, virtuaalikone on puhtaampi raja: asiakas saa ytimen, jota se saa muokata, ja isäntä pitää reititystaulunsa. Valitse se ennen kuin käytät iltapäivän oikeuksiin, joita tulet katumaan.