Wer wie ich das Vergnügen hat, für eine VPN-Verbindung in’s Büro auf ein proprietäres Werkzeug angewiesen zu sein, der muss sich zuweilen zu helfen wissen, um das entsprechende Programm auch unter modernen Linuxen betreiben zu können. So auch bei “SSL Network Extender” von Checkpoint, das nicht auf ein die Standards (Cisco VPN, OpenVPN) aufsetzt, sondern ein eigenes, nicht offenes VPN-Format verwendet, das unter der Haube machen kann, was es will, denn niemand sieht es. Abgesehen davon, dass es ziemlich schwierig ist, ohne Kundenlogin an das SSLExtender Binary für Linux ranzukommen, ist das Teil auch noch sauschlecht programmiert, aber dazu komme ich später.
Installation
Die Installation ist einfach, das selbstextrahierende Shellskript wird ausgeführt und 3 Sekunden später ist das Programm installiert und bereit:
./Check_Point_SNX_R66_HFA_01_For_Linux_800004013.sh
Erste Zweifel
Beim ersten Ausführen allerdings wird einem schon der erste Stock zwischen die Beine geworfen:
snx
snx: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
Die Software hat also tatsächlich eine Versionsabfrage für die Grundbibliothek libstc++ hart eincodiert! Uns fehlen die Worte und erste Zweifel an der Programmierqualität (oder fehlt einfach die Erfahrung mit Linux?) des Hauses Checkpoint kommen auf… Aber wir wären keine echten Geeks, wenn wir dafür keinen Workaround fänden:
Für Fedora u.ä. steht dazu meist eine compat-Version bereit, die für ebensolche Fälle gemacht ist:
yum install compat-libstdc++-33
Achtung! Auf 64bit-Versionen muss die 32bit-Version explizit angegeben werden (denn natürlich hat Checkpoint keine 64bit-Version auf Lager):
yum install compat-libstdc++-33.i686
Für Ubuntu’s neuere Versionen gibt es diese gar nicht mehr, aber man kann sie einfach aus einem älteren Repository ziehen: http://packages.ubuntu.com/jaunty/i386/libstdc++5/download
Trügerischer Tunnelgräber
Also auf geht’s mit einem neuen Versuch:
snx -u BENUTZER -s SERVERNAME
FATAL: Could not open tun.ko. No such file or directory
SNX: Virtual Network Adapter initialization and configuration failed. Try to reconnect.
Oh je, warum zum Geier benötigt der SSL Network Extender das Tunnel-Kernelmodul? Eine kurze Suche im Internet bringt an’s Tageslicht, dass auch diese Abhängigkeit fest einprogrammiert ist, obwohl SSL Extender einen eigenen, proprietären VPN-Tunnel erstellt. Auf Fedora tritt dieser Fehler nicht auf, weil das Modul “tun” mit dem Standardkernel ausgeliefert wird. Unter Ubuntu jedoch ist dies Fehlanzeige, auch nachträglich lässt sich das Modul nicht installieren. Man müsste den Kernel neu übersetzen mit der entsprechenden Option. Aber wir sind doch nicht bescheuert und machen uns diese Mühe, bloss weil da ein paar Erstsemesterprogrammierer bei Checkpoint sizten! Das Modul muss einfach existieren, es muss überhaupt nix tun, also wird es einfach gefaked, siehe dazu auch: http://wiki.ubuntuusers.de/Check_Point_SSL_Network_Extender
mkdir faketun
cd faketun
echo -e "#include <linux/module.h>\nstatic int start__module(void) {return 0;}\nstatic void end__module(void){return;}\nmodule_init(start__module);\nmodule_exit(end__module);">tun.c
echo -e "obj-m += tun.o\nall:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) modules\nclean:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) clean\nclean-files := Module.symvers">Makefile
make
sudo install tun.ko /lib/modules/`uname -r`/kernel/net/tun.ko
sudo depmod -a
Ab jetzt funktioniert SSLExtender auch auf Ubuntu und man kann in Ruhe von zu Hause aus arbeiten, auch mit diesem proprietären VPN-Tunnel. Dem Arbeiten am Wochenende steht nun nichts mehr im Wege, ausser man hat nebenbei noch ein Privatleben 
[2] http://packages.ubuntu.com/jaunty/i386/libstdc++5/download
[3]http://wiki.ubuntuusers.de/Check_Point_SSL_Network_Extender
Chris on 
