Eine gängige Herausforderung, Fall 1: Ein mobiles Clientsystem soll mit HIlfe eines VPN-Clients mit einem geschützten Netzwerk verbunden werden. Dabei ist gewünscht, dass während der Tunnel aufgebaut ist der gesamte Netzwerktraffic des Clients über das VPN geht. Nach Abbau des Tunnels soll wieder alles so sein wie vorher.
Fall 2: Ein Dual-Homed Host in einem RZ (z.B. ein Proxy) soll im Wartungsbetrieb seine Defaultroute "nach innen" gesetzt haben, so wie sie auch aus dem Deployment-System herausfällt. Im Wirkbetrieb jedoch soll die Defaultroute "nach außen" gesetzt sein, damit die Kommunikation mit dem Internet möglich wird.
Beide Aufgaben erfordern ein temporäres Umsetzen der Defaultroute. Macht man das auf dem naiven Weg, muss man sich irgendwie merken, wohin die Defaultroute vor dem Umsetzen zeigte, um sie danach wieder herzustellen.
In diesem Artikel stelle ich einen einfachen und eleganten Weg vor, um sich die Zwischenspeicherung der "alten" Defaultroute zu sparen. Ich kenne ihn schon seit ein paar Jahren aus der OpenVPN-Welt und bin immer wieder über die Situation gestolpert, dass er an einer Stelle hilfreich ist und ich ihn den Leutern erklären muss, die ihn noch nicht kennen. Mit diesem Artikel möchte ich mir diese Erklärungen in der Zukunft etwas einfacher machen.
Als Systemadministrator hat man im Idealfall mit IP-Routing nur dann zu tun, wenn man seinen Systemen eine Defaultroute setzt und dann nie wieder. Mit Wissen auf diesem Niveau kann man jahrelang in unserem Handwerk arbeiten.
Bis es mal nicht tut, oder besondere Anforderungen auch besondere Maßnahmen erfordern. Dann sieht man sofort, wo das Grundwissen fehlt. In diesem Artikel möchte ich eine - hoffentlich minimale - Menge dieses Grundwissens vermitteln. Aufgrund meines fachlichen Fokus beschränke ich mich hier auf Linux; die Theorie dahinter ist aber für alle internettauglichen Betriebssysteme identisch, so dass man sich nur an die verwendeten Tools, ihre Parameter und ihre Ausgabeformate anpassen muss.
Es ist schon eine Weile her. Bei einem langjährigen Kunden, der mich immer mal wieder mit haarigen Debuggingaufgaben oder komplexen Planungen inklusive Migration beauftragt hat. Einem so langjährigen Kunden, dass ich dort nahezu alle Leute duzen durfte und ein- und ausgehen durfte wie mir gerade zumute war.
Ich komme also im Office des Kunden an und suche mir einen freien Schreibtisch in einer Ecke des Großraumbüros mit für mein Tagewerk genug freien Netzwerkports. Zwei Tischreihen weiter stehen drei Mitarbeiter des Kunden aus dem Bereich Clientmanagement ratlos um einen PC herum. ich schnappe Unterhaltungsbrocken auf, und bekomme mit, dass das Softwareverteilungssystem für Windows-Clients sich nicht in der Lage sieht, das Redmond-Betriebssystem auf diesem Rechner zu installieren. Ich werde neugierig.
Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.
Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.
In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das "weniger" zu.
Oft stolpert man bei der Vorbereitung einer Migration auf Altlasten, deren Implementierung im neuen System zwar möglich ist, man das aber aus verschiedenen Gründen nicht möchte. Manche Kunden sind dazu bereit, im Rahmen des laufenden Projekts auch an anderen Stellen Anpassungen vorzunehmen, die ihnen in Zukunft das Leben erleichtern. Man sollte sich nicht scheuen, solche Maßnahmen vorzuschlagen - etwas Blick über den Tellerrand hat noch keinem geschadet.
Oft hat man vor dem Einstieg in die heiße Migrationsphase die Gelegenheit, die neuen Systeme vorzubereiten und zumindest teilweise vorzukonfigurieren. Das sollte man natürlich besonders bei Produkten machen, deren Eigenheiten man noch nicht in- und auswendig kennt, denn außerhalb der heißen Phase hat man Zeit und Ruhe und kann auch mal manche Dinge ausprobieren, die einen vielleicht nur akademisch interessieren. So fasst man Vertrauen zum Produkt und solches Wissen kann man sicher auch irgendwann mal wieder gebrauchen.
Ich baue neue Systeme - so vertretbar möglich - immer erstmal in einer Laborumgebung ("einem Lab") auf, das die Infrastruktur des Kunden möglichst 1:1 nachbildet.
Given a simple, switched LAN with Debian Linux (sid, iputils-ping) and Microsoft Windows XP (Service Pack 2, with the Windows Firewall disabled). A user complains about the network being slow (meaning his Windows notebook). I quickly find out that I can ping the box from my Linux notebook if my -s parameter is < 1393 or > 1472. If it's between 1393 and 1472, no replies are received.
I spend the next hour with debugging this not so interesting phenomenon.
15:36 <@clone42> ... Die Schlussfolgerung der Forscher: Obwohl formale Bildung
die geometrischen Fähigkeiten anscheinend verbessert, gibt es
ein universelles, auch ohne Ausbildung vorhandenes Verständnis
für Geometrie.
15:36 <@clone42> Das gilt für IP leider nicht
