Wizards of FOSS Blog


Multi-Homed Router

Last update on Jan. 10, 2012.

Multi-Homed Router

Ausfallsicherheit Internet am Bürostandort



(c) 2011/2012 Thomas Osterried, Wizards of FOSS UG (haftungsbeschränkt) & Co. Schulungen KG
         http://www.wizards-of-foss.de/
         thomas.osterried@wizards-of-foss.de

Einleitung

Das DSL ist mal wieder ausgefallen. Ein wichtiges Dokument muß noch als E-Mail versendet werden. Die halbe Belegschaft ist nicht arbeitsfähig - wer kennt das nicht?

Der UMTS-Stick aus der Notebooktasche vermag die Zeit des Internetausfalls zu überbrücken - für das Versenden z.B. eines wichtigen Dokuments. Mag das ausreichen?
Sind jedoch große Teile der Büro-Infrastruktur vom Internet abhängig, oder ist man gar auf externe Daten angewiesen (wie z.B. Meßdaten Positionsdaten mobiler Geräte, o.ä..), dann ist es wichtig solide Vorsorge getroffen zu haben.

Lesen Sie welche Möglichkeiten das OpenSource-Betriebssystem Linux Ihnen bietet. Es bringt alles Erforderliche mit – gewußt wie man es konfiguriert.


Vorweg ein Überblick Lösungsmöglichkeiten

I. Zahlreiche ISPs (Internet-Service-Provider) bieten redundante DSL-Leitungen an.


Vorteil

  • Gleiche Einwahldaten für alle Leitungen. Die Leitung die funktioniert wird verwendet.

Nachteile

  • Derartige Lösungen finden sich nur im hochpreisigen Segment. Eine spezielle Router-Hardware ist in der Regel ebenfalls erforderlich.

  • Werden beide Leitungen von einem Anbieter gestellt, kann die Technik trotzdem ausfallen, beispielsweise Ausfall des Autorisierungsdienstes beim ISP oder bei Fehlrouting beim ISP.

II. Mehrere Anbieter; Routing

Wer ein über ein provider-unabhängiges IP-Subnetz (PI) sowie eine AS-Nummer verfügt, der kann seine Netze über seine Upstream-ISPs "announcen". Die Pakete erreichen auf dem kürzesten Weg ihr Ziel. Dann wird automatisch umgerouted, wenn eine Leitung ausfällt. Dies ist eigentlich eine Providerlösung und steht in der Regel für ein kleines mittelständisches Unternehmen nicht zur Verfügung.

Alternativ kann man einen Server in einem Rechenzentrum (RZ) anmieten, welches selbst redundant angebunden ist. Zu diesem Server lassen sich gleichzeitig über die beiden Leitungen VPN-Tunnel (Virtual Private Network) aufbauen und kann so auf den Ausfall automatisiert reagieren.

Nachteile dieser Lösung:

  • Der Server im RZ stellt wieder einen "single Point of failure" dar. Zudem steht er nur selten unter der eigenen physischen Kontrolle. Ferner leiten wir in diesem Szenario unseren gesamten ein- und ausgehenden Internetverkehr über den Server im RZ ins Internet. Das bedeutet: Wenn Server tot dann Totalausfall.

  • Eine weitere Möglichkeit Ausfallsicherheit zu erhöhen ist ein Tunnel zu zwei Servern in Rechenzentren, idealer weise an unterschiedlichen Standorten. Diese Lösung ist aufwendig zu realisieren und teuer.

III. Flexibler mit OpenSource

Zwei DSL-Leitungen terminieren an zwei DSL-Modems; ihre Ethernetkabel werden mit einem kleinen Linux-Router verbunden. Der Router hat einen Ethernet-Port im lokalen Netzwerk (LAN).

Vorteile

  • Die Lösung skaliet. Z.B. durch Hinzufügen eines UMTS-Links oder eines Satelliten-Uplinks.

  • Die Lösung ist flexibel. Z.B. anpaßbar an neue Bedürfnisse.

Nachteil

  • Expertenwissen ist erforderlich

Dieses System ist ein multi-homed Router.

Die Wizards of FOSS UG (haftungsbeschränkt) & Co. Schulungen KG bietet Expertenschulungen für Mitarbeiter aus Unternehmen der IT und IT-Abteilungen von Konzernen an. In diesem Artikel möchten wir einen Einblick in unsere Kursinhalte geben.

Verschiedene Anforderungen, Konzepte und Realisierung

1. Einrichten des Internetzugangs

PPPoE (PPP over Ethernet) ist der in Deutschland übliche Standard zur Anbindung von DSL-Routern an das Internet.

2. Konfiguration von NAT und Firewall

Da man üblicherweise vom Internet-Provider nur eine einzige IP-Adresse erhält wird eine Adreßumschreibung benötigt (NAT (Network Address Translation).

Im lokalen Netzwerk verwendet man speziell reservierte Adressen (RFC1918). Für die Kommunikation zwischen LAN und Internet werden die lokalen Adressen auf die Internet-Adresse des Routers umgeschrieben.

Firewalls kontrollieren den Datenverkehr zwischen innen und außen. Die Kontrolle erfolgt u.A. über die Zuordnung von IP-Adressen, Ports und Protokoll.

Zu 1) und 2)

Für beides gibt es zahlreiche Bücher, Artikel in Fachzeitschriften, HOWTO's und Blogs. Das Basiswissen setzen wir an dieser Stelle voraus.

3. Die "default-Route" ins Internet

Für jede unserer Außenanbindungen wurde vom ISP eine eigene IP-Adresse zugewiesen. ISPs akzeptieren nur Pakete von der aktuell zugeteilten IP-Adresse und filtern "falsche" IP-Adressen. *)
Ein Versuch, einfach zwei "default-Routen" über beide Interfaces zu setzen wird zum Scheitern verurteilt sein, denn Pakete werden dann mal über die eine, mal über die andere Leitung gehen. Pakete mit falscher Quell-Adresse werden verworfen.
Für die ausgehende Verbindung nur eine der Leitungen zu verwenden ist technisch einfach umzusetzen. Mit einem kleinen Shell-Script läßt sich feststellen ob die Leitung funktioniert und im Fehlerfall auf die andere Leitung umstellen.
Alternative: Ein Router kann so konfiguriert werden, daß beide Leitungen bedient werden und die zur Verfügung stehende Bandbreite genutzt wird, indem der Datenverkehr -so weit wie möglich- auf beide Leitungen verteilt wird. Dabei wird auch berücksichtigt, daß Daten die zu einer Verbindung gehören über das passende Interface gerouted werden.

Diesem interessanten Aspekt widmet sich ein künftiger Blog-Eintrag auf wizards-of-foss.de mit dem Titel DSL-Kanalbündelung unter Linux.

    *) Ein ungefilterter Internetzugang ist für Endkunden aus Sicherheitsgründen nicht mehr erhältlich.
       Erinnern wir uns an einen Computer-Virus aus dem Jahr 2002, der eine MSSQL Datenbank mit nur einem einzigen UDP-Paket (376 bytes Daten) infizieren konnte.

4. Ausgehende Pakete des Routers ins Internet

Auf das Interface ppp900 zeigt die default-Route.
Wir möchten die IP-Adresse von server1.example.com über die Leitung hinter dem Interface ppp901 ansprechen.
  -> route add server1.example.com dev ppp901
Jegliche Kommunikation (also ein- und ausgehend) mit server1.example.com wird jetzt nur über das Interface ppp901 erfolgen.
Diese Lösung ist einfach und schnell umzusetzen, jedoch ist sie unflexibel. Wir kommen am Ende des folgenden Kapitels wieder auf diese Frage zurück.

5. Eingehende Pakete aus dem Internet an den Router

Konfiguration
  • Für DSL-Leitung 1 hat der Router die IP-Adresse 192.0.2.1 erhalten; das Interface ist ppp900.

  • Für DSL-Leitung 2 hat der Router die IP-Adresse 198.51.100.1 erhalten; das Interface ist ppp901.

  • Die Default-Route zeigt auf ppp900.

 

                       Router
+-----+
---------- ppp900 ---O |
DSL1 192.0.2.1 | |
| O--LAN
---------- ppp901 ---O |
DSL2 198.51.100.1 | |
+-----+
Verhalten


  a) Anfrage aus dem Internet kommt über DSL1 an192.0.2.1 (Interface ppp900) an.
     Router antwortet über die default-Route (zeigt auf ppp900).
     Router antwortet mit der richtigen IP-Adresse über das richtige Interface.
     ISP nimmt die Antwort an.
  b) Anfrage aus dem Internet kommt über DSL2 an 192.51.100.1 (Interface ppp901) an.
     Router antwortet über die default-Route (zeigt auf ppp900).
     Router antwortet zwar mit der korrekten IP-Adresse. Jedoch über das falsche Interface (ppp900 statt ppp901).
     ISP verwirft die Antwort.

Lösung

Regel-basiertes Routing mit iproute2, auf Grundlage der Quell-IP-Adresse.

Damit die Konfiguration übersichtlich bleibt kann in der Datei /etc/iproute2/rt_tables festgelegt werden:

 128 uplink1
129 uplink2


Regeln beim Systemstart setzen:

 ip rule add from 192.0.2.1 lookup uplink1
ip rule add from 198.51.100.1 lookup uplink2


IP-Routen müssen dynamisch gesetzt werden, da PPP-Interfaces nicht persistent sind.

pppd Start-Script: Datei /etc/ppp/ip-up.d/0099x-ip-route-uplink-x

 #!/bin/bash
if [ "$IFNAME" == "ppp900" ] ; then
ip route add default dev ppp900 table uplink1 || true
elif [ "$IFNAME" == "ppp901" ] ; then
ip route add default dev ppp901 table uplink2 || true
fi

Anpassungen in einem pppd „down“-Script sind nicht nötig, da bei Trennen der Verbindung das Interface gelöscht wird, und damit auch die darüber gesetzten Routen.

Übermittelt der ISP nur dynamische IP-Adressen, dann müssen obenstehende Scripte angepaßt werden. Beispiel:

Erweiterung des "up"-Scriptes:

 [..]
elif [ "$IFNAME" == "ppp902" ] ; then
ip rule add from $4 lookup umts-uplink1 || true
ip route add default dev ppp902 table umts-uplink1 || true
fi

Argument #4 ($4) des "up"-Scriptes enthält die IP-Adresse die der pppd vom ISP im Zuge der Protokollaushandlung erhalten hat.

Erstellen eines "down"-Scripts (unter /etc/ppp/ip-down.d/) zum Löschen von alten Einträgen:

 [..]
elif [ "$IFNAME" == "ppp902" ] ; then
ip rule del from $IP lookup umts-uplink1

( for IP in $(ip rule |grep " lookup umts-uplink1 " | awk '{print $3}'); do
ip route del default dev ppp902 table umts-uplink1 || true
done
) || true
fi


Alle „ip rule“ Einträge die mit den Tabellennamen "umts-uplink1" gesetzt wurden werden gelöscht; die zu löschenden IP-Adressen werden automatisch ermittelt.
Cave: die Ausgabe von „ip rule“ enthält am Zeilenende ein Leerzeichen.

Zur Veranschaulichung folgt die Ausgabe des Befehls „ip rule show“:

 $ ip rule show
0: from all lookup local
32765: from 192.0.2.1 lookup uplink1
32766: from all lookup main
32767: from all lookup default
^Leerzeichen


Die Funktionsweise unserer neuen Routing-Regeln:

Wird der Router über eine Leitung auf der zugehörigen IP-Adresse angesprochen, dann wird im Vorgang des Versendens des Antwortpakets geprüft ob es eine entsprechende "rule" gibt und das Paket wird über das zugehörige Interface gesendet.

Wird beispielsweise der Router über das Interface ppp901 angesprochen, sorgt die Regel „ip rule from 198.51.100.1 lookup uplink2“, daß die Routingtabelle nach Einträgen mit Tag „uplink2“ durchsucht wird. Das sind jene, die mit Befehlen wie „ip route add default dev ppp901 table uplink2“ eingetragen wurden.

Soll server1.example.com -ausgehend- stets über die Leitung hinter ppp901 angesprochen werden, aber server1.example.com Daten wahlweise an unsere IP-Adressen 192.0.2.1 und 198.51.100.1 senden können:
Rufen wir die Fragestellung aus 4) in Erinnerung: egal über welches Interface server1.example.com gerouted wird, eingehende Pakete werden jetzt stets korrekt über das das Interface beantwortet über welches die Anfrage ein ging.

6. Eingehende Pakete aus dem Internet an den Router bzw. ausgehende Pakete vom LAN ins Internet.


Üblicherweise vermittelt der Router zwischen LAN und Internet und stellt selbst keine eigenen Dienste bereit. In der Regel wird NAT verwendet.

6.1 Grundlagen: Klassisches NAT


Wir betrachten zunächst die Konfiguration mit einer einzigen Außenanbindung über ppp900. Die default-Route zeigt auf ppp900. Ein PC im LAN hat eine lokale RFC1918 IP-Adresse. Bei Aufbau einer Verbindung zu einem Server im Internet wird die LAN-Adresse auf die IP-Adresse des externen Interfaces ppp900 umgeschrieben. Dieses Verfahren nennt man Network-Address-Translation (NAT).
Eigentlich ist NAT eine Krücke. Viele verstehen sie als "Firewall-für-Arme". Bei NAT gibt es eine Unzahl von Problemen, die Sicherheitsrisiken ins sich bergen. Mit der Einführung von IPv6 werden wir diese Ära hinter uns lassen. Das Für und Wider soll jetzt aber nicht Gegenstand unserer Problemlösung werden, denn bei nur einer vom ISP zugewiesenen IPv4-Adresse und mehreren Rechnern im LAN führt (von Proxy-Lösungen abgesehen) an NAT kein Weg vorbei,


6.1.1 Der Router hat eine Außenanbindung und eine default-Route.

                      Router
+-----+
---------- ppp900 ---O | PC1
DSL1 192.0.2.1 | | eth0 / 10.0.0.10/24
| O--LAN---------------+
| | 10.0.0.1/24 \
| | PC2
+-----+ 10.0.0.11/24

 

Konfiguration:
 $ grep net.ipv4.ip /etc/sysctl.conf 
net.ipv4.ip_forward=1


  [Genauer: die "Datei" /proc/sys/net/ipv4/ip_forward enthält den Wert 1. Dadurch wurde Linux Kernel so konfiguriert, daß das Weiterleiten von Datenpaketen erlaubt ist.
Hinweis: Bei Betriebssystem Linux findet das IP-Routing im Kernelspace statt]

 iptables -t nat -o ppp900 -A POSTROUTING -j MASQUERADE
Verhalten:

  a) PC1 sendet ein Paket ins Internet. Seine Quell-IP: 10.0.0.10.
  b) Router schreibt die IP-Adresse auf die IP-Adresse von ppp900 um (192.0.2.1).
     Router speichert 'SRC-IP'+'SRC-Port'+DST-IP+'DST-Port'+Protokoll sowie den neuen SRC-Port des auf seine IP 192.0.2.1 umgeschriebenen Pakets (sog. Connection-Tracking Tabelle (Conntrack-Table)).
  c) Eine Antwort kommt vom angesprochenen Server aus dem Internet.
     Router findet in der Connection-Tracking-Tabelle die Zuordnung daß dieses Paket eine Antwort für eine bestimmte Verbindung von PC1 ist.
     Router schreibt das Paket um (Ziel-Adresse und Ziel-Port) und sendet es über eth0 an 10.0.0.10.

6.1.2 PC1 soll auf TCP-Port 22 von außen erreichbar sein.


Jedes Paket das den Router über ppp0 auf seine IP-Adresse 192.0.2.1 erreicht wird grundsätzlich auf einen lokalen Dienst bezogen. Ausnahmen: NAT (s. oben) oder Port-Weiterleitungen (s.u.).

Problem:

PC1 soll vom Internet aus über ssh (TCP Port 22) erreichbar sein.

Lösung: Zieladresse umschreiben.
 iptables -t nat -A PREROUTING -i ppp900 -p tcp --dport 22 -j DNAT --to-destination 10.0.0.10
iptables -A FORWARD -i ppp900 -p tcp -d 10.0.0.10 --dport 22 -j ACCEPT
Verhalten:

  Mit "iptables -t nat" wird in die für NAT zuständige Tabelle in der PREROUTING-chain das Destination-NAT-Ziel eingetragen, damit ein über ppp900 eingehendes Paket (und egal an welcher seiner IP-Adressen auf ppp900 - es könnte mehrere geben) derart umgeschrieben wird, als wäre es direkt an 10.0.0.10 adressiert (Sprungziel Destination-NAT). Die Connection-Tracking-Tabelle wird für jede neue Verbindung automatisch aktualisiert.
  Durch das DNAT auf eine nicht-lokale IP-Adresse wechselt sich die Zuständigkeit der Chains: es ist nicht mehr die "INPUT"-chain sondern die "FORWARD"-chain zuständig.
  In der "filter"-Tabelle wird über die FORWARD-chain die Kommunikation von links (ppp900) nach rechts (Ziel 10.0.0.10, TCP Port 22) erlaubt.

Die Antwort von 10.0.0.10 kann passend umgeschrieben werden, weil der Eintrag in der Connection-Tracking-Tabelle gefunden wird.

Das ist alles kein Problem; das kann jeder DSL-Router für 30€.


6.2 Mehrere Außenanbindungen, komplexere Konfiguration


Zunächst zur Verdeutlichung die Grafik aus 6.1, erweitert auf zwei Internet-Leitungen.

Die default-Route liegt über ppp900.

                      +-----+
---------- ppp900 ---O | PC1
DSL1 192.0.2.1 | | eth0 / 10.0.0.10/24
| O--LAN---------------+
---------- ppp901 ---O | 10.0.0.1/24 \
DSL2 198.51.100.1 | | PC2
+-----+ 10.0.0.11/24


Leichte Abwandlung der iptables-Regeln aus 6.1.1 für Destination-NAT vom LAN ins Internet und 6.1.2 für das Umschreiben eingehende TCP-Verbindungen auf Port 22:

 iptables -t nat -o ppp90+ -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -i ppp90+ -p tcp --dport 22 -j DNAT --to-destination 10.0.0.10
iptables -A FORWARD -i ppp90+ -p tcp -d 10.0.0.10 --dport 22 -j ACCEPT


['+' ist eine Wildcard. 99+ "matcht" 990, 991, .., 999, 9900, 9991, .. 9999, usw. → Eine Regel referenziert beliebige Zahl von Interfaces mit dem selben Namensprefix → Übersichtlichere Konfiguration. Die Interfaces müssen bei Erstellen der Regeln nicht existieren.]

6.2.1 Ausgehende Verbindung (d.h. Paket aus dem LAN über die default-Route über ppp900), bzw. Eingehende Verbindung über ppp900 (Pakete mit Umschreibung von TCP Port 22 aus dem Beispiel von 6.1.2.)

Das Routing wird durch die neue zweite Außenanbindung nicht beeinträchtigt.
Auch die "ip route rule" Regeln aus 5) haben keinen negativen Einfluß.

6.2.2 Eingehende Verbindungen über ppp901 (an IP 198.51.100.1 gerichtet) TCP Port 22 gerichtet, die an PC1 mit der Adresse 10.0.0.10 TCP Port 22 weitergeleitet werden soll.

Verhalten:

  a) TCP-Paket mit Ziel 198.51.100.1 port 22 erreicht den Router über die Leitung hinter ppp901. Zieladresse wird umgeschrieben an 10.0.0.10 und erreicht PC1.
  b) PC1 bestätigt den Eingang des Paketes.
  c) Router schreibt die Quell-IP-Adresse von PC1 um auf 198.51.100.1. Das Paket verläßt den Router jedoch nicht über ppp901 sondern über ppp900, weil es der default-Route folgt. ISP verwirft das Paket.

Erklärung:

  Unsere "ip rule" Routingregeln aus 5) kommen nicht zum Tragen.
  Diese Regeln gelten nur für vom Router selbst erzeugte Pakete, denn bei lokalen Verbindungen wird innerhalb der Struktur des Sockets die angesprochene IP-Adresse im struct skb gespeichert, welche beim Verlassen des Antwortpakets zur Hilfe genommen wird. Es wird nach dem Interface gesucht das zur IP-Adresse und dem Tabelleneintrag on "ip route rule" aus 5) paßt.
  Wir befinden uns jedoch in einem anderen Vorgang, dem Forwarding im Linux Kernel, so daß kein Bezug zu einer bestehenden Verbindung herstellen kann.
  Die Adreß-Umschreibung NAT geschieht in der table NAT chain POSTROUTING, nachdem die Routingentscheidung bereits getroffen wurde. Hier findet der Kernel einen „match“ auf die Verbindung (Connection Tracking); die ausgehende IP-Adresse ist die zur Verbindung gehörende (198.51.100.1), aber das bereits gewählte Interface ist das falsche. Das Paket verläßt mit der IP Adresse 198.51.100.1 das Interface ppp900 und wird vom ISP verworfen. Die Regel greift zu spät.

Lösung:

  Der Router muß bei einem eingehenden Paket speichern über welches Interface es ihn erreichte.
  Genauer: beim _ersten_ Paket von Quell-IP und Quell-Port (und Protokoll). Dies, zusammen mit dem Interface, müsste in einer Connection-Tracking-Tabelle gespeichert werden. So lange die TCP-Verbindung besteht, bzw. bei Datentransfer per UDP Daten fließen wird diese Liste zwischengespeichert (bei UDP kontrolliert durch timeout Timer).
  Allerdings: Die Connection-Tracking-Tabelle speichert konzeptuell weder das eingehende noch ausgehende Interface (s.u.).

  Im Fall des Routings können wir zwar die "ip rule" Tabellennamen aus 5) wiederverwenden, nicht aber die "ip route ... lookup ..." Regeln aus 5), welche sich auf die lokalen Interface-IP-Adressen beziehen.
  Wir benötigen zusätzliche Regeln.

  Mit iptables Firewall-Regeln lassen sich Referenzen auf "ip rule" Routinganweisungen setzen. Diese Brücke stellt fwmark des Linux Netfilter-Codes her.
  iptables fwmark arbeitet nur mit numerischen Werten, ohne Namensabstraktion. Wir verwenden der besseren Übersicht wegen die selben Zahlen wie bei der rt_tables Definition aus 5) und ignorieren daß die Zahlen eigentlich in HEX notiert sind.

  Für uplink1:

 ip rule add fwmark 128 table 128

  Für uplink2:

 ip rule add fwmark 129 table 129


  Nachdem man die im Manual von iptables dokumentierten Verfahren zum Markieren und Dereferenzieren der Markierungen (Sprungziel CONNMARK) verstanden hat, fällt einem die Lösung wie Schuppen von den Augen.
  Da die Connection-Tracking-Tabelle keine Interfaces mitprotokolliert, müssen wir für jedes Interface einen eigenen Bezug als Routinghilfe herstellen, damit das spätere Antwortpaket dereferenzierbar wird. Wir erstellen deshalb einzelne Regeln:

    1. Speichern einer Referenz bei Eintreffen eines ersten zu einer somit neuen "Verbindung" gehörenden Pakets in der Conntrak-Table über Connmark; als Referenz-ID verwenden wir der Übersicht halber die Tabellen-Nummer aus "ip rule"; man könnte die Zahl aber frei wählen. Dies geschieht in der PREROUTING Tabelle der "mangle" Tabelle, und für jedes Interface mit einer eindeutigen Nummer:

 iptables -t mangle -A PREROUTING -i ppp900 -m state --state NEW -j CONNMARK --set-mark 128 
iptables -t mangle -A PREROUTING -i ppp901 -m state --state NEW -j CONNMARK --set-mark 129

    2. Der PC aus dem LAN antwortet. Den Router erreicht die Antwort über das Interface eth0. Die Connection-Tracking-Tabelle soll vor der Routingentscheidung durchsucht werden, in der PREROUTING-chain. Vergleiche den Unterschied: Destination-NAT arbeitet in der POSTROUTING-chain, also nach Treffen der Routingentscheidung).
Findet sich eine zugehörige Verbindung in unserer Liste (z.B. match connmark mark 128), so wird die Markierung (Referenznummer des ersten Pakets, in der Liste dank –set-mark 128, die sich eindeutig auf das Interface bezieht) wieder hergestellt (restore-mark); das Paket erhält so einen Bezug zur Verbindung und darüber einen zur ip route table uplink1, welche sich auf das Interface ppp900 bezieht.

 iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 128 -j CONNMARK --restore-mark 
iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 129 -j CONNMARK --restore-mark

CONNMARK ist also das netfilter-Pendant zu „ip rule … lookup ...“ (welches die Einschränkung hatte daß es nur auf dem Router terminierende Verbindungen referenzieren kann).


Zusammenfassung und sinnvolle Ergänzungen:

 echo "1" >/proc/sys/net/ipv4/ip_forward
iptables -t mangle -A POSTROUTING -o ppp90+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A POSTROUTING -o eth1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -o ppp90+ -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -i ppp90+ -p tcp --dport 22 -j DNAT --to-destination 10.0.0.10
iptables -A FORWARD -i ppp90+ -p tcp -d 10.0.0.10 --dport 22 -j ACCEPT
iptables -A FORWARD -i ppp90+ -j REJECT
ip rule add from 192.0.2.1 lookup uplink1
ip rule add from 198.51.100.1 lookup uplink2
ip route add default dev ppp900 table uplink1
ip route add default dev ppp901 table uplink2
iptables -t mangle -A PREROUTING -i ppp900 -m state --state NEW -j CONNMARK --set-mark 128
iptables -t mangle -A PREROUTING -i ppp901 -m state --state NEW -j CONNMARK --set-mark 129
iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 128 -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth0 -m connmark --mark 129 -j CONNMARK --restore-mark
echo "0" > /proc/sys/net/ipv4/conf/ppp900/rp_filter
echo "0" > /proc/sys/net/ipv4/conf/ppp901/rp_filter


  Datei /etc/iproute2/rt_tables:

 128 uplink1
129 uplink2


Den zu Grunde liegenden komplexen Sachverhalt sieht man dieser handvoll Befehlen gar nicht an ;)

 

7. Übungen (Router)


  7.1 Was für ein verändertes Verhalten erreichen wir durch folgenden Befehl?
        iptables -t mangle -I PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -j CONNMARK --set-mark 129

      Tip: Zielportbasierte Routingentscheidung

  7.2 Weshalb führt ein nachträgliches
 iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -m state --state NEW -j CONNMARK --set-mark 129

nicht zum Erfolg?
  7.3. Die Notwendigkeit, rp_filter auszuschalten, wurde nur in der Zusammenfassung kurz erwähnt, aber nicht begründet:
 echo "0" > /proc/sys/net/ipv4/conf/ppp901/rp_filter

       Weshalb ist dies notwendig?

       Tip: rp_filter verwirft "martians". Marsianer sind fehlgeleitete Pakete, z.B. empfangen über ein Interface wofür es keinen "route match" gibt.

       Was ist in unseren Beispielen der route scope von ppp901?

       Weshalb wäre es nicht nötig rp_filter auszuschalten, wenn nach "route add server1.example.com dev ppp901" dessen IP-Adresse (/32) über ppp9001 geroutet wird?

       In welcher Datei bringe ich diese Konfigurationsänderung sinnvoller weise unter?

  7.4. Es wurde behauptet, ip rule / ip route Konfigurationen seien für das Interface auf dem die default-Route liegt nicht nötig.     

        Welcher Vorteil liegt darin, die Konfiguration für ppp900 und ppp901 einheitlich zu führen?

  7.5. Ändern wir
 iptables -t mangle -A PREROUTING -i ppp901 -m state --state NEW -j CONNMARK --set-mark 129

       in

 iptables -t mangle -A PREROUTING -i ppp901 -j CONNMARK --set-mark 129

       beobachten wir, daß das Paket nicht über eth0 weitergeleitet wird. Über welches Interface werden sämtliche über ppp901 eingehenden Pakete geroutet, und wie erklärt sich das Phänomen?

  7.6. Über Interface ppp900 lag die default-Route, jedoch ist es jetzt "down". ppp901 ist "up" und es gibt noch den "ip route add default lookup table uplink2"-Eintrag.

       Erklären Sie, weshalb Nutzer aus dem LAN nicht mehr ins Internet können, aber sämtliche Dienste (auf dem Router selbst sowie die über Port-Weiterleitung ins LAN) noch erreichbar sind.

  7.7. Der Router hat für jeden seiner angenommen 32767 Dienste eine Separate IPv6-Adresse aus dem Netzblock 2001:DB8::/64.

       Muß für jede der IP-Adressen eine eigene ip rule angelegt werden?
       Tip: „RTNETLINK answers: Invalid argument“ -- -6 nicht vergessen.


8. The Mikrotik Way


Die Router der Firma Mikrotik (http://www.mikrotik.com/) heißen "Routerboards".
Routerboards laufen unter RouterOS; RouterOS hat einen Linux Kernel.
Sämtliche Funktionen sind über ein spezielles CommandLine Interface (CLI) konfigurierbar; alternativ über das Programm winbox.exe, welches übrigens problemlos unter Linux in der Windows-Emulation "wine" läuft.


8.1 Konfiguration Routing

Unser Wissen aus den Abschnitten 1-7 vorausgesetzt, läßt sich der Router für unseren Einsatzzweck wie folgt konfigurieren.

/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=ppp900 \
routing-mark=uplink1 scope=30 target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=ppp901 \
routing-mark=uplink2 scope=30 target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=ppp900 \
scope=30 target-scope=10
/ip route rule
add action=lookup disabled=no src-address=192.0.2.1/32 table=uplink1
/ip route rule
add action=lookup disabled=no src-address=198.51.100.1/32 table=uplink2
/ip firewall mangle
add action=mark-connection chain=prerouting comment="" connection-state=new \
disabled=no in-interface=ppp900 new-connection-mark=uplink1 \
passthrough=yes
add action=mark-connection chain=prerouting comment="" connection-state=new \
disabled=no in-interface=ppp901 new-connection-mark=uplink2 \
passthrough=yes
add action=mark-routing chain=prerouting comment="" connection-mark=uplink1 \
disabled=no in-interface=bridge new-routing-mark=uplink1 \
passthrough=yes
add action=mark-connection chain=prerouting comment="" connection-state=new \
disabled=no dst-port=80 in-interface=bridge new-connection-mark=\
uplink2 passthrough=yes protocol=tcp
add action=mark-routing chain=prerouting comment="" connection-mark=\
uplink2 disabled=no in-interface=bridge new-routing-mark=uplink2 \
passthrough=yes

rp_filter Regeln müssen nicht berücksichtigt werden.
rt_table- und fwmark-Nummernzuweisungen nimmt RouterOS automatisch vor. und bleiben dem Nutzer im Detail verborgen. fwmark's connection-mark arbeitet bei RouterOS mit sprechenden Namen.


9. Übungen (Mikrotik RouterOS)

Obige Konfiguration bezieht sich auf das Routing, ohne NAT-Regeln und ohne Berücksichtigung des Falles, daß Dienste auf dem Router über beide Interfaces direkt erreicht werden sollen.


9.1 Erklären Sie die Funktion der Regel

/ip firewall mangle \
add action=mark-connection chain=prerouting comment="" connection-state=new \
disabled=no dst-port=80 in-interface=bridge new-connection-mark=\
uplink2 passthrough=yes protocol=tcp

      und ihre Position in der Mangle-Table.


9.2 Konfigurieren Sie DST-NAT auf TCP-Port 22 für eingehende vom Internet eingehende Verbindungen über ppp900 und ppp901, die auf Zielrechner 10.0.0.10 TCP Port 22 im LAN weitergeleitet werden sollen.

 

Schlußbemerkungen

Haben Sie beim Lesen oder in den Übungen Lücken festgestellt, empfehlen wir Ihnen unser Angebot Networking Basics.


Methoden zum Prüfen der Konfiguration und weitere tiefgreifende Netzwerk-Konzepte sind Teil unseres in Vorbereitung befindlichen Schulungsangebots Networking Advanced.

Die Wizards-of-FOSS bieten Schulungen an, die Ihre Mitarbeiter in die Lage versetzen, Netzwerke zu planen und Konfigurationen wie oben selbst vorzunehmen; die Wizards-of-FOSS bauen aber selbst aber keine Netzwerke auf.
Brennen Ihnen zeitnahe technische Lösung oder Umsetzung unter den Nägeln, wenden Sie sich bitte direkt an den Autor.

Next entry

Previous entry

Related entries

Similar entries

Comments

Comments are closed.

Pingbacks

Pingbacks are closed.