Kategorien
bla bla bla

Voll Panne, Ne

Ich habe mich heute stundenlang mit VPNs rumgeärgert – eines ist blöder als das andere.

Aber zur Ausgangslage: In unserer Groupware-Applikation ist ein Bug, der angeblich gar nicht da ist – behaupten meine Progger. Da wir keine Lust mehr haben, uns damit rumzuschlagen sollen jetzt die Verursacher dieses Käfers mit ihrem Tomcat direkt auf unsere Test-Datenbank losgehen, wofür ich beauftragt wurde denen einen VPN-Zugang zur Verfügung zu stellen.

Auf der Firewall-Appliane läuft dazu ein pptp-Daemon, der bugbelastete Nachbau eines sicherheitszerfressenen Originals – klingt komisch, ist aber so. Nun hat jedoch der unter Linux nutzbare pptp-Client bei Kernel 2.6.15+ irgendwelche obskuren Probleme – der Tunnel läßt sich öffnen, aber idiotischerweise keine Daten drüber schicken, ein tcpdump auf Clientseite zeigt schön alle abgehenden Pakete, die vom pptp auch eifrig als verschickt gezählt werden, aber auf der anderen Seite kommt nichts an – elektronisches Nirvana vom feinsten.

Der prinzipiell auch laufenden IPSec-Tunnel mit OpenSWAN hat mir die letzten Nerven* geraubt – das ist so eine Netzwerktechnik, welche ich _nie_ begreifen werde.

Der für mich gefunden Workaround besteht jetzt aus einem simplen ssh-Tunnel – an sich brauchen die drüben nur Zugriff auf den MySQL-Port 3306, der kann auch ganz simpel an localhost gebunden werden, was dann in fertig so aussieht:

ssh user@ssh-host -L [localport]:remote-server:[remoteport]

Das ganze ist dann am Ende so, als würde der auf dem Remote-Port angebotene Dienst der im Firmennetzwerk stehenden Box auf 127.0.0.1** laufen – alles in allem sehr praktisch, hoffentlich reicht das erst mal aus, auf weitere VPN-Stunden habe ich _keine_ Lust.

* Ich bin ein Nervivor – ich lebe von meinen Nerven
** Die optimale Adresse um Remote-Exploits zu testen

Von renke

IT-Ratte (oder Systemadministrator), hat nen neues Spielzeug gekriegt und wird die "Genese" des Servers hier bebloggen.

21 ist nur die halbe Wahrheit.