DHCP-Server sind in ordentlichen Netzen eine Pest. Klar, lassen sich die Teile auch halbwegs sicher konfigurieren. Nur wenn ich schon den Aufwand treibe, alle MAC-Adressen den IPs und diese den Ports zuzuordnen, dann kann ich auch gleich mit festen IPs arbeiten 😉 Aber als kleines Zugestaendnis an unsere MacBook-Fraktion habe ich mich dann doch ueberreden lassen, den mobilen Edelteil-Traegern einen DHCP ins Intranet zu stellen. Und um ehrlich zu sein: In meinem Testnetz werkelt auch seit ewigen Zeiten soeine IP-Schleuder. Kann ja nix passieren. Ist ja nen abgeschottetes Netz… Gestern bewahrheitete sich dann wieder Murphys Law: Was schief gehen kann, wird schief gehen! Dank einer ungeschickten Kombination aus SSTP-VPN via SoftEther habe ich alle MacBook-Clients aus dem Kunden-Intranet gekegelt. Und das kam so.
Spaetestens seit Snowdens Offenbarungen duerfte jedem auch nur wenig an IT-Sicherheit interessiertem Entscheider klar sein, dass VPNs niemals auf Basis von Closed-Source-Software betrieben werden sollten. Konsequenterweise haben sich meine Kunden schon lange von der direkten IPSec-Implementierung auf der nicht ganz preiswerten Firewall vom „Marktfuehrer“ verabschiedet. Unter anderem auch, weil IPSec einfach eine ziemliche Kruecke ist, die eigentlich auch nie fuer den Einsatz in IPv4-Netzen gedacht war. Ausserdem haben die meisten Nutzer bei uns eh einen Windoof-Client. Was liegt also naeher, als das von Haus aus verfuegbare SSTP-Protokoll einzusetzen? Dessen Spezifikation hat M$ erfreulicherweise offen gelegt, weshalb es inzwischen auch schon gute OpenSource-Implementierungen fuer den serverseitigen Teil gibt. Es muss also auch niemand das Risiko eingehen, die Original-MS-Server dafuer einzusetzen. Es geht auch unter Linux.
Mit SoftEther gibt es gluecklicherweise eine Open-Source-Loesung, welche sogar fuer Windows verfuegbar ist. Und noch besser: Mit SoftEther lassen sich auch sehr einfach Site-to-Site-VPN einrichten. Also ein virtueller Zusammenschluss von zwei oder mehr privaten Netzen. Es muss lediglich in beiden ein SoftEther-Server konfigiriert werden, welcher uebers Internet erreichbar ist. SoftEther kennt diverse Methoden, wie das sogar durch sehr restriktive Firewalls geht. Aber das ist ein anderes Thema. Nur soviel: Die meisten Admins werden gar nicht wissen, dass sich diese Software von innen fast durch jede Firewall bohren kann. Also Vorsicht! Wer sich alle Moeglichkeiten dieses schicken Stueck Softwares erstmal anschaut, ist schnell tagelang damit beschaefftigt, erstmal zum Beispiel seine IDS auf die internen DNS zu erweitern… 😉
Mit SoftEther braucht es fuer ein Site-to-Site-VPN im Grunde nur einen PC mit Internetzugang in jedem der beiden Intranets. Was fuer Anwender mit verschiedenen Niederlassungen natuerlich ein ungeheurer Vorteil ist, wenn sich die einzelnen Arbeitsplatzrechner nicht mehr wie Road Warrior (Aussendienst-Mitarbeiter mit Client-to-Site-VPN) direkt am Gateway anmelden muessen. Allenfalls noch eine zusaetzliche IP-Adresse aus dem Ziel-Netz vergeben und schon uebernimmt der Gateway den Rest. Okay, zugegeben, nicht jeder Sysadmin hat das Glueck, dass in jeder Niederlassung verschiedene private Sub-Netze konfiguriert sind. Bei von mir betreuten Kunden ist das aber aus anderen Gruenden ohnehin schon immer so gewesen. Hurra 🙂
Der ordentliche Admin testet natuerlich seine Implementierung erstmal. Und ist bei SoftEther ueberrascht, wie schnell sich damit sogar Site-to-Site-VPN aufbauen lassen. Also die Verbindung von zwei privaten Netzen. Nennt sich bei SoftEhter „cascade connection“. Laesst sich mit dem Wizard in ein paar Minuten „zusammenklicken“ und das Ergebnis ist beeindruckend sauber implementiert. Im Gegensatz zu IPSec koennen Schicht-3-Loesungungen wie SSTP, die mit einem TCP-Port auskommen, auch das UDP-Protokoll darueber tunneln. Leider fuehrt das bei einigen Netzwerkkarten bzw. deren Treibern mitunter zu Problemen mit dem MTU. Insbesondere die Verbindung Lizenzserver von SPSS (eine Statistik-Software von IBM) schlug bei einem meiner Kunden deshalb oft fehl, weil das Java-Teil bei den Groessen seiner UDP-Pakete sich aufs Betriebssystem bzw. dessen Treiber verlaesst und diese wiederum zu bloed sind, die MTU automagisch zu reduzieren.
SoftEther bietet dafuer eine Funktion, es direkt am Gateway umzufrickeln. Ich finde es aber doof, einem Gateway Arbeit aufzulasten, die eigentlich der Client erledigen sollte. Zumal, wenn es nur einzelne betrifft und es sich dort recht einfach korrigieren laesst. Wie gross die MTU am besten ist, laesst sich errechnen. Oder einfach austesten. Fuer mich hat sich ein Wert von 1260 als optimal ergeben. Das kann bei anderen Karten/Netzen anders sein. Aber es ist nen schoener Ausgangswert fuer eigene Tests.
Unter Linux laesst sich die Konfiguration ganz einfach anpassen. Erstmal mit ifconfig das externe Netzwerkinterface ermitteln. In meinem Beispiel ist das „ens32“. Bei dem von mir bevorzugt verwendeten SuSe loest dann
vi /etc/sysconfig/network/ifcfg-ens32
mit dem Eintrag
MTU='1260'
und einem anschliessenden Neustart des Netzwerkadapters das Problem. Unter Windoof ist es etwas aufwaendiger, aber auch nicht schwierig. Einfach mit Start->Ausfuehren->cmd.exe eine Shell als Administrator oeffnen. Dann
C:\>netsh netsh>interface netsh interface>ipv4 netsh interface ipv4>show interfaces Idx Met MTU State Name --- ---------- ---------- ------------ --------------------------- 1 50 4294967295 connected Loopback Pseudo-Interface 1 11 10 1500 connected LAN-Verbindung
Die 1500 duerfte der Standardwert sein. Den fuer die Verbindung „LAN-Verbindung“ einfach umstellen. Das laesst sich durch Angabe des Namens bewerkstelligen. Wer aber schonmal auf Rechnern administriert hat, deren Zeichensatz nicht ASCII ist, kann da auch schnell mal die falsche erwischen. Daher bevorzuge ich die Angabe mit der Nummer aus der Spalte „Idx“.
set subinterface 11 mtu=1260 store=persistent
Das „store=persistent“ am Ende ist fuers Testen nicht so wichtig / eher unguenstig. Sobald der passende Wert gefunden ist, sollte es aber angegeben werden, damit die Einstellung auch einen Neustart ueberlebt.
So weit, so einfach 😉
Zum Abschluss der Evalierung habe ich mir also das Subnetz der einen Niederlassung in meine Testumgebung konfiguriert. Dafuer ist ein DHCP dann doch eine ganz prima Arbeitserleichterung. Taadaa, Tusch, alles klappt! Jetzt haemmern wir noch eine Woche froehlich mit ein paar Stress-Tools auf den Gateway. Dann wird es beim Kunden implementiert.
Am naechsten Morgen dann die boese Ueberraschung: Keiner der Edelteil-Traeger kam mehr ins Internet. Alle andern schon. Logische Ursache: Der DHCP beim Kunden ist ausgefallen. Also schnell per gutem SSH nen Tunel ins Kundennetz gegraben und den DHCP direkt gecheckt. Hm, seltsam, der laeuft prima. Liefert alle Konfigurationen wie gewuenscht. Seltsam, sehr seltsam. Erfreulicherweise haben die Mitarbeiter dort keine Angst vor etwas Technik. Und gluecklicherweise werkelt im Mac OS ein Beastie.
Beastie – das Teufelchen ist das Maskottchen von FreeBSD
Dem Tux nicht ganz unaehnlich. Also hat der Kollege flott eine Shell geoeffnet und per iptables die Werte seiner Netzwerkkonfiguration fuer mich ausgelesen. Hm, ja, das war eine der gestern ins Testnetz gehieften IPs. Was war denn da passiert?
Das MacBook hatte wie jeden Morgen seinen DHCP request ins Intranet gejagt. Nun habe ich den DHCP-Server zwar so abgesichert, dass er jedem MacBook die genau fuer es bestimmte Netzwerkkonfiguration gibt. Allerdings war durch das VPN ja nun ein zweiter DHCP-Server „im Intranet“. Und meine kleine virtuelle Linux-Kiste jagte die Antworten schneller raus und durch den Tunnel, als die super sichere Hardware-Loesung vor Ort. Systembedingt krallt sich der Client also die erste passende Konfiguration… und schon haengt er im falschen Netz. Aus gutem Grund funktioniert das Site-to-Site-VPN aber nur in eine Richtung. Damit wuerden alle Pakete das MacBooks nicht mehr geroutet -> OFFLINE 🙁
Erfreulicherweise hat SoftEther auch fuer dieses Problem eine Loesung: DHCP-Paket werden einfach nicht durch den Tunnel gelassen. Es muss nur konfiguriuert werden. Eine Beschreibung, wie das im Einzelnen funktioniert und was welcher Parameter bewirkt, wuerde hier nun aber doch den Rahmen sprengen. Ich packe einfach mal nen ScreenShot mit den notwendigen Einstellungen hier ran.
Einstellungen fuer SoftEther, welche das Routen von DHCP ueber den VPN-Tunnel verhindern