SNX på Linux: 32-bitars bibliotek och en resolver som nollställs

SNX på Linux misslyckas i laddaren, routingtabellen eller resolvern, och varje fel ser ut som ett inloggningsproblem. Arbeta igenom de fyra symptomen i ordning.

Check Points SSL Network Extender misslyckas på Linux på fyra igenkännbara sätt, och tre av dem läses fel som ett inloggningsproblem. Antingen startar inte binären, eller den startar och lämnar ingen rutt, eller den ansluter och namnuppslagningen dör, eller webbläsarportalen fungerar medan kommandoraden inte gör det. Arbeta igenom dem i den ordningen, eftersom var och en är inträdesvillkoret för nästa.

Symptom ett: laddaren vägrar före inloggningen

Installationsprogrammet som hämtas från brandväggen lägger en 32-bitars binär med setuid-root i /usr/bin/snx. På en 64-bitars distribution körs den inte förrän i386-arkitekturen är aktiverad och biblioteken den länkas mot finns.

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"

En tom not found-lista är porten för allt som följer. Den exakta paketuppsättningen ändras mellan utgåvor: en fungerande rapport behövde libstdc++5:i386, libx11-6:i386 och libpam0g:i386, en annan behövde också libstdc++6:i386. Läs ldd i stället för att kopiera en paketlista från en handledning skriven för en annan distribution.

Om snx inte hittas alls slutfördes aldrig installationen eller den installerades någonstans utanför din PATH. Det är ett annat fel, och det är värt att bekräfta innan du lägger till arkitekturer i systemet. Kontrollera med command -v snx och titta i katalogen som installationsprogrammet rapporterade. Att lägga till i386-paket på en maskin där binären helt enkelt saknas lagar ingenting.

Symptom två: inloggningen lyckas och ingenting routas

En lyckad inloggning skapar tunsnx och redigerar routingtabellen själv, så kontrollera vad som faktiskt finns innan du ändrar något annat.

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

Använd snx -d för att riva ned. Att döda processen lämnar gränssnittet och dess rutter efter sig, och nästa försök misslyckas då av en anledning som inte har något med inloggningsuppgifter att göra. Den första inloggningen registrerar också en serversignatur under /etc/snx/, vilket är varför ett oövervakat skript kan behöva en interaktiv körning innan det ens kan fungera. Radera det tillståndet bara när du tänker godkänna servern igen.

Symptom tre: namn löses upp tills tunneln kommer upp

Det här är den som tyst går sönder. snx skriver skjutna DNS-servrar direkt in i /etc/resolv.conf. Där den sökvägen är en symbolisk länk in i /run/systemd/resolve/ kan ändringen gå förlorad vid nästa resolverhändelse, och efter en frånkoppling kan de skjutna posterna lika gärna bli kvar.

Två upplägg fungerar, och valet bör vara medvetet i stället för vad det första sökresultatet föreslog:

  • Ta över filen: ersätt den symboliska länken med en statisk fil och installera libnss-resolve plus dess i386-variant, så att namntjänsten fortfarande har en reserv när filen skrivs om under den.
  • Behåll systemd-resolved som ägare och registrera tunnelänken: resolvectl dns tunsnx 10.0.0.10, sedan resolvectl domain tunsnx corp.example, och bekräfta med resolvectl status.

Anteckna namneservrarna före VPN:en innan du ansluter. Om du redigerar filen för hand är det att ta bort de skjutna posterna efteråt en del av proceduren, inte valfri städning, eftersom en bärbar dator som behåller företagets DNS efter frånkoppling inte kan lösa upp något annat.

Symptom fyra: portalen fungerar och CLI gör det inte

Nya brandväggsutgåvor har flyttat mellanvaran från webbläsaren till en lokal Java-demon, så portalen talar med en lokal agent på port 14186. Den adressen behöver ett webbläsarcertifikatundantag och en körande process.

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

Kommandoraden är en egen väg: snx -s vpn.example.com -u user, där ~/.snxrc håller servern, användarnamnet och inställningen för förnyad autentisering. En fungerande portalsession säger ingenting om huruvida CLI är korrekt installerat, och den bara klienten hanterar inte engångskoder.

Genvägen med container som kostar mer än den sparar

snx kontrollerar tun-modulen, laddar den när den saknas, skapar ett tunnelgränssnitt, skriver om rutter och skjuter trafik genom det. Att återskapa det i en container innebär att montera /dev och /lib/modules och ge breda befogenheter, vilket ger containern det mesta av värdens nätverksadministration.

När en sandlåda verkligen behövs är en virtuell maskin den renare gränsen: klienten får en kärna den får ändra, och värden behåller sin routingtabell. Välj det innan du lägger en eftermiddag på befogenheter du kommer att ångra att du gav.

Relaterade artiklar