IPTables, eine DMZ und der Providerwechsel

IST-Zustand:
Es gibt eine auf iptables basierende OpenSuse-Firewall. Diese wird im Normalfall durch den Firewallbuilder administriert. Es gibt eine DMZ mit öffentlichen IP-Adressen. Ob das grundsätzlich so die beste Lösung ist, lasse ich an dieser Stelle außen vor. Eine neue schnellere Internetanbindung bei einem anderen Provider kommt dazu.

SOLL-Zustand:
Da die neue Leitung schneller ist und der Chef meistens ungerne Geld für etwas ungenutztes ausgibt, sollte die Leitung natürlich sofort genutzt werden. Da sich aber bei der Umschaltung der DMZ viele kleine Probleme ergeben können und auch die Domains auf die neuen IPs gewechselt werden müssen, bin ich hier lieber einzeln vorgegangen. Also musste für den anstehenden Providerwechsel die DMZ schrittweise auf ein anderes öffentliches IP-Netz umgestellt werden.

Hier habe ich mal den für dieses Szenario relevanten Teil des Netzes grafisch dargestellt:

Problematik:
Das Intranet auf den neuen Zugang umzustellen kann man relativ unkompliziert machen. Anfragen ins Internet gehen dann über die geänderte Default-Route über den neuen Router und die Antworten kommen über diesen wieder zurück und werden an die Clients im Intranet geliefert:

Im Fall der DMZ, oder auch bei Freigaben per Port Forwarding, die noch über eine der alten öffentlichen IPs realisiert werden (wie z.B. oft für Exchange OWA), hat man nun allerdings aufgrund der geänderten Default-Route ein Problem. Die Anfragen kommen über ISP 1 aus dem Internet an, passieren die Firewall und gehen an den entsprechenden Server. Die Antwort vom Server geht aufgrund der Default Route in der Firewall aber an Router 2 und damit unter einer der neuen öffentlichen IPs über ISP 2 raus ins Internet. Das funktioniert so nicht, da der anfragende Computer diese IP in dem Kontext nun gar nicht kennt und die ankommenden Pakete verwerfen wird:

Das Problem besteht also darin, dass für die alte DMZ die neue „Default Route“ der Firewall, laut der Pakete über den neuen Router raus ins Internet geschickt werden, übergangen werden muss. Eine einfache Regel dafür lässt sich leider im Firewallbuilder nicht erstellen. Somit muss man leider drum herum manuell am Routing basteln.

Info:
Ebenfalls hilfreich ist die Lösung dieses Artikels wenn man dauerhaft 2 Internetleitungen nutzen möchte, z. B. eine Leitung fürs Surfen und eine weitere für VPNs oder eine DMZ.

Lösungsansätze:
Eine Möglichkeit wäre es die entsprechenden Pakete, die von einer bestimmten Source kommen, in diesem Fall aus der alten DMZ, und an ein der Firewall nicht bekanntes Ziel geschickt werden zu markieren und entsprechend dieser Markierung abzufangen und dann an ein anderes als das Default-Ziel umzuleiten. Das war mir aber zu viel des guten.

Die einfache Lösung für dieses Problem nennt sich „Policy Based Routing“ oder in diesem speziellen Fall „Source Based Routing“. Hierbei wird für das Routing nicht nur die Ziel-Adresse berücksichtigt, sondern auch die Quell-Adresse. Wie es sich für einen Nerd gehört kam ich nachts um 3 Uhr auf diese Lösung, als ich übelst krank gewesen bin und habe direkt nachts die Testumgebung dafür hochgezogen 😉

Meine Testumgebung besteht aus 5 virtuellen Maschinen auf denen OpenSuse läuft:

Auf die Einrichtung der iptables-Firewall soll dieser Artikel nicht eingehen. In der Test-Firewall steht nicht viel drin. Für den Live-Betrieb ist diese natürlich nicht verwendbar, da ich einfach alles zulasse.

Unter /etc/firewall habe ich das iptables-Skript firewall.fw abgelegt und in der
/etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.

Für das Routing habe ich zwei Regeln erstellt, um die Default Route entweder über Router 1 oder Router 2 zu realisieren. Durch das Aktivieren der jeweils anderen Regel kann man hier leicht hin- und herwechseln.

In der Datei /etc/iproute2/rt_tables werden die Routing-Tabellen, die beim Systemstart aufgebaut werden, festgelegt. Entweder kann man einen neuen Eintrag für eine weitere Routing-Tabelle direkt in die Datei schreiben oder mit folgendem Befehl hinzufügen:

echo 200 dmz >> /etc/iproute2/rt_tables

1	echo 200 dmz >> /etc/iproute2/rt_tables

Diese Routing-Tabelle muss nun nur noch mit Regeln gefüllt werden. Da diese nach einem System-Neustart wieder flöten gehen, legt man dafür am besten ein eigenes Skript an. Ich habe dafür unter /etc/firewall das Skript dmz.sh erstellt und ausführbar gemacht. Auch dieses Skript wird in der /etc/init.d/boot.local für den automatischen Start beim Systemstart eingetragen.

Die erste Regel die benötigt wird gibt an wann die Routing-Tabelle genutzt werden soll. In diesem Beispiel bei Traffic aus dem Netz 192.168.3.0/24:

ip rule add from 192.168.3.0/24 dev enp0s3 table dmz

1	ip rule add from 192.168.3.0/24 dev enp0s3 table dmz

In diese Tabelle kommt nun noch die Default Route über den alten Router:

ip route add default via 192.168.1.1 dev enp0s8 table dmz

1	ip route add default via 192.168.1.1 dev enp0s8 table dmz

Das reicht aber noch nicht. Es fehlen noch die Routen für die anderen Netze, ansonsten sind diese von dieser Routing-Tabelle aus nicht mehr erreichbar:

ip route add 192.168.1.0/24 dev enp0s8 src 192.168.1.2 table dmz
ip route add 192.168.2.0/24 dev enp0s9 src 192.168.2.2 table dmz
ip route add 192.168.3.0/24 dev enp0s3 src 192.168.3.1 table dmz
ip route add 192.168.4.0/24 dev enp0s10 src 192.168.4.1 table dmz