Gestern Abend saß ich mit einem befreundeten Admin zusammen. Er hatte ein Problem mit einem VPN-Gateway eines Kunden und wir wollten uns zusammen auf Fehlersuche machen. Der Server ist ein IPSEC-Gateway auf Linuxbasis und sollte neben einigen reinen IPSEC-Clients noch ein iPhone mittels L2TP anbinden.
Die Einwahl mit dem iPhone funktionierte auch schon, allerdings waren danach die Server im internen Netz des Kunden nicht erreichbar. Die Konstellation bei dieser Konfiguration ist also wie folgt:
iPhone --> Internet --> IPSEC --> L2TP --> PPP Verbindung --> internes Netz
Also jede Menge potenzielle Fehlerquellen. Da die Verbindung an sich aber zu Stande kam, nahmen wir uns die erste Verdächtige vor.
1. Firewall
Nach eingehender Untersuchung konnten wir hier keinen Fehler feststellen. Eine Blick in die Log-Dateien offenbarte auch keine blockierten Pakete. Also weiter.
2. Konfigurationsdateien
In der Konfiguration mit Openswan als IPSEC-Dienst, xl2tpd als L2TP-Dämon und PPP für die Point-to-Point Verbindung gibt es einige Konfigurationsdateien, die es zu testen galt. Wir prüften die Dateien auf Fehler in den Netzwerkkonfigurationen, das sollte sich später noch als nicht ausreichend erweisen. Die Konfiguration der Netzwerkelemente war in Ordnung, die PPP-Verbindung kam mit den richtigen IP-Adressen zu Stande. Der PPP-Dämon baut eine virtuelle Verbindung zwischen zwei IP-Adressen aus dem internen Netz auf und leitet den Verkehr dann an das physische Netzwerkdevice des VPN-Routers weiter. Dadurch ist kein Routing notwendig, um die virtuelle Adresse des iPhones zu erreichen. Das wird später noch wichtig werden.
3. Netzwerkdevices
Eine kurze Untersuchung der Netwerkdevices der virtuellen PPP-Verbindung mit ifconfig ergab, dass das Device zwar Pakete raus schickte, aber keine zurück kamen. Doch die Firewall? Also noch mal zurück zu 1., dann
4. Ratlosigkeit
Es war schon etwas später, wir wollten schon den Einsatz beenden. Dann wollten wir doch noch einen letzten Versuch machen, den Fehler zu finden.
5. Netzpakete untersuchen
Also noch tcpdump angeworfen, um die Pakete zu untersuchen, die beim Aufbau einer Verbindung zum Exchange-Server so übers Netz gehen. Gesagt, getan, das SYN-Paket geht raus, aber keine Antwort des Exchange. Ah, Moment, da ist noch eine ARP-Anfrage, der Exchange möchte wissen, unter welcher MAC-Adresse er die virtuelle IP des iPhones erreichen kann (es ist ja eine interne Adresse). Offensichtlich bekommt er keine Antwort. Ich ahne etwas. In der Options-Datei der PPP-Verbindung für L2TP gibt es den Parameter "proxyarp", der dafür zuständig ist, dass der PPP-Dämon ARP-Anfrage nach der virtuellen IP mit der MAC-Adresse der Netzwerkkarte des Servers beantwortet. Ein Blick in die Konfigurationsdatei zeigt, das der Parameter schlicht fehlt. Bingo. Parameter eingefügt, Verbindung neu gestartet, alles läuft.
Das ganze hat knapp 3 Stunden gedauert und hätte auch etwas schneller gehen können, wenn wir unter 2. bereits die Parameter in der Options-Datei geprüft hätten, und uns nicht nur auf die Netzwerkparameter konzentriert hätten. Das war zwar ärgerlich, aber wir haben für das nächste Mal auch etwas gelernt, ist auch wichtig.
Dann jede Menge Hausarbeit, macht auch nicht so den Spaß. Auf dem Parkplatz vorm Getränkemarkt will ich einen Tweet beantworten. "Batterie ist erschöpft, das Smartphone wird ausgeschaltet." Meehh. Abends wollen wir in unsere Lieblingspizzeria, kein Tisch mehr frei.
