Ein IPSec-Gateway im Eigenbau

Seite 6: Fehlersuche

Fehlersuche

Kommt aus unerfindlichen Gründen keine Verbindung zu Stande, gilt der erste Blick der Log-Datei auf dem VPN-Gateway. Hier protokolliert FreeS/WAN jeden Verbindungsversuch, den Verlauf der Verhandlungen und schließlich die Erfolgsmeldung "IPsec SA established". Am besten beobachtet man den Verbindungsaufbau life mit

tail -f /var/log/auth.log

Meldet FreeS/WAN hier gar nichts, kommen vermutlich keine IPSec-Pakete auf dem VPN-Gateway an. Dies kann man mit

tcpdump -i eth0 not port ssh

überprüfen. Der not-Filter blendet SSH-Verkehr aus, das Interface eth0 muss man auf Systemen mit Dial-up-Zugang durch ppp0 ersetzen. Mögliche Ursachen können falsch eingetragene Adressen oder Paketfilter-Regeln sein, die die Pakete verwerfen.

Klappt die Authentifizierung nicht, stimmt wahrscheinlich irgendetwas mit den verwendeten Zertifikaten beziehungsweise deren Installationspfad nicht. Konkretere Hinweise liefern unter Umständen die Einträge in der Log-Datei oder die Ausgabe von

ipsec auto --listall

das alle FreeS/WAN bekannten Zertifikate anzeigt.

Meldet FreeS/WAN "IPsec SA established", es kommen aber trotzdem keine Ping-Antworten zurück, werden die Pakete irgendwo unterwegs verworfen oder falsch weitergeleitet. Um die Ursache dafür aufzuspüren, muss man sie auf ihrem Weg schrittweise mit tcpdump verfolgen.

Sendet ein Rechner in einem Heimnetz ein Ping-Paket in Richtung Firmennetz, kommt dies zunächst auf dem internen Interface (eth0) des heimischen VPN-Gateways an. Das System leitet es dann an das IPSec-Interface ipsec0 weiter. Dort wird es verschlüsselt, in ESP verpackt und über das externe Interface (ppp0) verschickt. Als ESP-Paket kommt es auf dem externen Interface des Firmen-Gateways an, das es entschlüsselt und dann - wieder als Ping-Paket - über ipsec0 an das interne Interface des Firmen-Gateways weiterreicht, über das es sein Ziel erreichen sollte. Die Antwort nimmt denselben Weg rückwärts. Durch systematisches Sniffen mit tcpdump auf all diesen Interfaces sollte sich der Punkt, an dem die Pakete verloren gehen und damit hoffentlich auch die Ursache dafür, aufspüren lassen.

Mehr Komfort

Wer auf den internen Firmen-Webserver zugreift, möchte dabei nicht mit Adressen wie 10.1.1.100 hantieren. Die URL http://intern.firma.com quittiert der Browser jedoch trotz VPN-Verbindung zunächst mit einer Fehlermeldung, da der DNS-Server im Internet den nur intern bekannten Namen nicht auflösen kann. IPSec stellt lediglich eine gesicherte IP-Verbindung her - um Namensauflösung hat sich der Administrator selbst zu kümmern. Bei der Kopplung ganzer Netze empfiehlt es sich, auf beiden Seiten einen DNS-Server so einzurichten, dass er als "Secondary" den Datenbestand des anderen spiegelt und damit auch DNS-Anfragen nach Rechnern im entfernten Netz beantworten kann.

Für den Road Warrior mit dem Notebook im Hotel ist ein eigener DNS-Server natürlich Overkill. Er kann jedoch beim Einrichten des VPN-Zugangs alle benötigten Rechner und deren IP-Adressen in die Datei c:\windows\system32\etc\hosts eintragen (unter Linux /etc/hosts). Damit klappt die Namensauflösung unabhängig vom DNS.

Das gleiche gilt für die Datei lmhosts im selben Verzeichnis, die die Namen für Windows-Server bereitstellt. Damit lassen sich die Server über die Suchfunktion der Netzwerkumgebung oder über den net-Befehl auf der Kommandozeile ansprechen. Um einen externen Rechner voll in eine Windows Infrastruktur einzubinden, kann man in der Netzwerkumgebung einen Eintrag auf einen WINS-Server des Firmnenetzes eintragen (in der Netzwerkumgebung/Verbindung/Eigenschaften/Internetprotokoll/Erweitert). Dann sollte allerdings eine Firewall SMB-Broadcasts abfangen, damit diese nicht versehentlich nach außen gelangen.

Umsichtige Administratoren erstellen gleich Vorlagen für alle notwendigen Dateien. Diese können sie zusammen mit einer kurzen Anleitung über die zip- beziehungsweise tar-Anweisung in make_cert in das Archiv mit dem Zertifikat einfügen. Damit hat der Anwender gleich alle notwendigen Informationen für die Installation zur Hand.

Ist das VPN-Gateway einmal im Produktionsbetrieb, kann man FreeS/WAN nicht für jede Änderung oder neu eingetragene Verbindung neu starten und damit allen VPN-Nutzern die Verbindung kappen. Hier hilft das Kommandozeilen-Tool ipsec, das meist in /usr/local/sbin/ liegt.

ipsec auto --replace n2n

lädt eine Verbindungsbeschreibung neu. Weitere auto-Kommandos wie start, delete, status helfen bei der Administration.

ipsec barf > ipsec.txt

schreibt alle relevanten Einstellungen in eine Datei. Überhaupt bieten FreeS/WAN und die X.509-Erweiterungen eine ganze Reihe zusätzlicher Optionen und Funktionen, die in dieser Anleitung zu kurz gekommen, aber in der Dokumentation gut beschrieben sind [2, 4].