Mini-HowTo fli4l als LAN-Router mit manuellem Fallback auf DSL/ISDN

Dieses HowTo bezieht sich auf den Betrieb von fli4l hinter einem anderweitigen Router. Das könnte

sein. Meine Experimente beziehen sich auf die Verwendung eines vorgeschalteten DSL-Routers, dieses HowTo läßt sich aber auch auf andere "externe" Router übertragen.

Die obligatorische Frage, wozu das Ganze im Falle eines externen DSL-Routers überhaupt gut sein soll, wenn man das DSL-Routing auch mit fli4l direkt betreiben könnte, läßt sich wie folgt beantworten:

  1. Handelt es sich dabei um einen VoIP-DSL-Router (in meinem Fall eine Fritz!Box Fon ATA - siehe auch das entsprechende HowTo), hat der die volle Kontrolle über das Telefonie-QoS - d.h. die Bevorzugung von VoIP-Telefonaten vor dem Traffic der Clients.
  2. fli4l ist mit seinen opt's (z.B. opt_time, opt_lpr, opt_...) flexibler konfigurierbar als die meisten Hardware-Router.
  3. Letztereres gilt insbesondere für die DHCP-Server von Hardware-Routern: In einer Umgebung mit gemischt dynamischen und statischen IPs (z.B. Printservern) ist opt_dhcp aufgrund der freieren Definition der DHCP-Ranges weitaus flexibler zu handhaben.

Es kann also durchaus sinnvoll sein, die DSL-Einwahl einem "Spezialgerät" wie einem VoIP-Router zu überlassen, sich aber trotzdem den Luxus eines nachgeschalteten fli4l-Routers zu gönnen.

Vorbereitungen / Vorüberlegungen

In allen Fällen wird es so sein, dass der externe Router eine eigene IP-Adresse hat, die entweder vom Provider gestellt wird (z.B. Kabel-Modem) oder selbst gewählt werden kann (z.B. anderweitiger DSL-Router). In allen Fällen wird der externe Router sowohl als Gateway als auch als DNS-Relay fungieren. Je nach Fall ist in dem vorgeschalteten Router ein DHCP-Server integriert oder nicht.

Netze

Wichtige Information vorab: Der externe Router muss sich in einem anderen logischen Netz befinden als der fli4l und die Clients. Daran gibt's nichts zu rütteln.

Beispiele:

  1. Soll der fli4l im Netz 192.168.42.0/24 stehen und die IP 192.168.42.254 innehaben, kann ein externer Router beispielsweise das Netz 192.168.43.0/24 erhalten und z.B. die IP 192.168.43.253.
  2. Ist der externe Router nicht konfigurierbar und bietet nur das Netz 192.168.178.0/24 und die IP 192.168.178.1 an, müssen fli4l und die Clients zwangsläufig aus dem 178er-Netz heraus - z.B. ins 192.168.42.0/24-Netz.

opt_dsl und opt_isdn

Wirklich komibinierbar ist das konventionelle Routing via DSL oder ISDN nicht mit dem LAN-Routing. Nichtsdestotrotz kann man bei geschickter Konfiguration eines oder beide opt's installiert lassen, um im Falle des Falles eine manuelle Fallback-Möglichkeit zu haben.

In einem derartigen Notfall kann es dann genügen, den externen Router abzuziehen (von der NIC bzw. vom Router - siehe nächster Abschnitt), fli4l wieder zurück ans DSL-Modem zu hängen (das ISDN-Kabel kann ja sowieso stecken bleiben), den Router zu booten - und schon ist wieder der fli4l wieder der Router im Netz.

Auf jeden Fall sollte man in der base.txt

setzen.

kann stehen bleiben und stört nicht weiter. Weiterhin bleibt (falls gewünscht) vor allem

erhalten - was den Vorteil hat, dass man den fli4l noch via Imonc erreichen kann. Das wäre nicht mehr gegeben, wenn man opt_dsl und opt_isdn komplett deaktivieren würde - in dem Fall müßte man den imond komplett deaktivieren.

Der sauberere Fall: LAN-Router mit zwei NICs

Der externe Router wird über eine zweite NIC an den fli4l angeschlossen. In dem Fall kommunizieren die Clients sauber über ihren Switch/Hub mit dem fli4l. Auf diese Weise entstehen beide die beiden logischen Netze (s.o.) auch auf physikalisch getrennten Netzwerk-Kabeln.

Dies ist zugleich der sicherste Fall, da die Clients nur im Umweg über fli4l auf den externen Router zugreifen können.

Wenn der externe Router mit einem DHCP-Server ausgstattet ist, der nicht deaktivierbar ist (z.B. weil der externe Router bei jeder Einwahl eine ggf. unterschiedliche, öffentliche IP des Providers bekommt und den angeschlossenen Client mit einer weiteren aus demselben Netz versorgen muss), ist dies die einzig mögliche Methode, da der DHCP-Server des externen Routers keinesfalls für die Clients hinter dem fli4l erreichbar sein darf. (Schließlich dürfen die ja nur IPs aus dem fli4-Netz erhalten, nicht IPs aus dem ggf. öffentlichen Netz des externen Routers.)

Der schmutzigere Fall: LAN-Router mit einer NIC

Es kann wünschenswert sein, die zweite NIC nicht mit dem externen Router zu verstopfen, um notfalls eine DSL-Fallback-Verbindung herstellen zu können, wenn der extrene Router mal spinnen sollte. In dem Fall kann sofort ohne Umkonfiguration die zweite NIC wieder als PPPoE-Interface genutzt werden.

Realisiert werden kann dies, indem man den externen Router mit an den Switch/Hub hängt und die erste NIC des fli4l zwei IPs zugewiesen bekommt (s. unten).

Dies bietet sich allerdings nur an, wenn die IP des externen Routers keine öffentliche IP des Providers ist (siehe letzter Abschnitt), sondern ebenfalls eine private IP (z.B. bei vorgeschaltetem DSL-Router), weil sonst das öffentliche Netz des Providers direkt an die Clients des Intranet herangeführt würde. Ist der DHCP-Server des externen Routers nicht deaktivierbar, ist diese Methode gänzlich unmöglich.

Weiter gilt: In einer Umgebung mit stärkeren Sicherheitsbedenken ist diese Methode zu unsicher, denn der externe Router steht direkt via Switch im Netz zur Verfügung. Jeder Client könnte (entsprechende Admin-Rechte vorausgesetzt) seine Netzwerkkonfiguration also manipulieren, um direkt den externen Router statt des fli4l zu verwenden.

Konfiguration

Wir gehen davon aus, dass zum externen Router die IP-Adresse und die Subnetmask bekannt ist, und dass die bisherige Konfiguration des fli4l und der Clients soweit vollständig ist. D.h.: Die Clients sind entweder als Hosts in der base.txt eingetragen und haben eine entsprechende statische IP-Konfiguration, oder sie erhalten die IP-Konfiguration beim Booten dynamisch vom fli4l.

In allen weiteren Beispielen wird von folgender Konfiguration ausgegangen (andere IP-Konstellationen funktionieren natürlich analog):

Wichtig: Es ist sinnvoll, die IPs der DNS-Server des Providers zu kennen - also beim Provider herausfinden oder ggf. bei konventioneller Einwahl via ifconfig / ipconfig / winipcfg heraussuchen.

Externer Router an der zweiten NIC

Die erste NIC bleibt mit dem Switch/Hub verbunden, an dem auch die Clients hängen. An die zweite NIC wird der externe Router angeschlossen. Wichtig: Je nach externem Router muss ein Crossover-Kabel verwendet werden. Eine NIC mit entsprechender "Connection"-LED ist hier sehr hilfreich bei der Fehlersuche.

Fall 1: Externer Router ohne DHCP-Server

In der base.txt wird folgendes eingetragen:

Merke: fli4l erhält auf der ersten NIC die IP 192.168.42.254 und auf der zweiten NIC die IP 192.168.43.254.

Die Anbindung des externen Routers erfolgt über

Merke: Es ist unnötig bzw. unangebracht, eine zusätzliche Router zu konfigurieren.

Weiterhin muss das DNS-Relaying konfiguriert werden. Theoretisch reicht es, den externen Router als DNS-Forward einzurichten, also

Praktisch funktioniert das auch sehr gut (sofern der Router als DNS-Relay fungieren kann), allerdings gibt es im Fallback-Fall, wenn der fli4l im Notfall also wieder normal via DSL oder ISDN routen soll und der externe Router nicht zur Verfügung steht, Probleme. Demnach trägt man hier lieber vorsorglich die IPs der DNS-Server des Providers ein, also

Logischerweise ersetzt man 1.2.3.4 und 5.6.7.8 durch die entsprechenden IPs.

Fall 2: Externer Router mit DHCP-Server

In diesem Fall muss natürlich opt_dhcp verwendet werden. Wichtig: In der base.txt wird der zweiten NIC keine IP zugeteilt. Also:

Gute Erfahrungen habe ich sowohl unter fli4l 2.07 als auch unter fli4l 2.08 mit DHCPCD gemacht, d.h. in dhcp.txt:

Nicht verwechseln: IP_ETH_1 entspricht Device eth0. Ergo ist der DHCP-Client fuer eth1 zu starten - nicht etwa für eth2.

Allerdings gibt es noch einen wichtigen Unterfall zu bedenken: Soll der fli4l für die Clients selbst als DHCP-Server zur Verfügung stehen oder nicht?

Fall 2a: Externer Router mit DHCP-Server, fli4l ist selbst kein DHCP-Server

Mit

in dhcp.txt ist alles getan.

Fall 2b: Externer Router mit DHCP-Server, fli4l ist selbst ebenfalls DHCP-Server

Hier kommt das Problem, dass man nicht für beide NICs eth0/eth1 einzeln definieren kann, ob auf ihnen der DHCP-Server verfügbar sein soll oder nicht. Ein fli4l-seitiger DHCP-Server an eth1 macht natürlich überhaupt keinen Sinn, wenn die IP von eth1 gerade von einem anderen DHCP-Server bezogen hat - in diesem Falle vom DHCP-Server des externen Routers. Korrekt lautet die DHCP-Konfiguration in dhcp.txt also auszugsweise (die DHCP_RANGE_1 kann natürlich je nach Wunsch konfiguriert werden):

Nur so ist gewährleistet, dass sich auf der zweiten NIC ie. eth1 nicht die beiden DHCP-Server des fli4l und des externen Routers ins Gehege kommen.

Externer Router ohne DHCP am Switch/Hub

Die Konfiguration verläuft in weiten Teilen völlig identisch. Der entscheidende Trick ist, eth0 zwei IPs zuzuweisen: Eine im 192.168.42.0/24-Netz der Clients und eine im 192.168.43.0/24-Netz des externen Routers.

Das gelingt in der base.txt wie folgt:

Auf diese Weise erhält NIC1 zwei unterschiedliche IPs für eth0, nämlich 192.168.42.254 und 192.168.43.254.

Zur Erinnerung: Ein externer Router mit eigenem (nicht deaktivierbarem) DHCP-Server ist auf diese Weise nicht verwendbar! Denn dann würde der externe Router DHCP-Clients IPs aus dem 43er-Netz zuweisen - was keinesfalls sinnvoll ist, wenn fli4l als LAN-Router fungieren soll. - Auch ist es wenig sinnvoll, einen externen Router mit öffentlichen IPs des Providers direkt mit allen anderen Clients in dasselbe Netzwerksegment zu hängen.

Alles weitere läuft wie gehabt, also

und

mit den IP-Adressen der DNS-Sever des Providers.

Somit ist auch klar, dass die zweite NIC nicht via DHCP nach einer IP fragen soll, somit gilt in dhcp.txt wie gehabt:

Sonderfall: Externer Router ohne DHCP am Switch und fli4l als DHCP-Server

Dieser Sonderfall erfordert noch etwas Aufmerksamkeit: Soll fli4l für die Clients als DHCP-Server fungieren, kommt wieder die Problematik zum Tragen, dass beide Netzwerk-Devices ETH_1 entsrechend eth0 und ETH_2 entsprechend dem Alias-Device eth0:0 mit zweiter IP als DHCP-Server fungieren können. Dummerweise hängen beide am selben Switch/Hub und lauschen somit beide auf denselben Broadcast 255.255.255.255. Es ist also wiederum erforderlich, den DHCP-Server von fli4l daran zu hindern, IPs aus dem 43er-Netz herauszugeben. Also gilt für die dhcp.txt wie oben im Fall 2b (die DHCP_RANGE_1 kann natürlich wiederum je nach Wunsch konfiguriert werden):

Nur so ist gewährleistet, dass auf der ersten NIC ie. eth0 nicht IPs beider Netze 192.168.42.0/24 und 192.168.43.0/24 gemischt vergeben werden.

Inbetriebnahme

Wenn alles richtig konfiguriert ist, sollten fli4l und externer Router sich nun gut verstehen - d.h. ggf. holt sich fli4l per DHCP vom externen Router eine IP und steht auch für die Clients als DHCP-Server zur Verfügung. Anderenfalls ist der externe Router von den Clients aus per Ping unter seiner definierten IP 192.168.43.253 zu erreichen.

Es bietet sich an, Pings auf bekannte IPs im Internet zu versuchen (z.B. 192.67.198.33 - Stand 11/2004 die IP von www.strato.de) und danach auch Pings auf namtlich bekannte Hosts im Internet auszuprobieren. Aber Obacht, nicht dass der externe Router irgendwelche Ferkeleien mit dem ICMP macht und dass deswegen Pakete stecken bleiben. :)

Manuelles Fallback

Hängt der externe Router am Switch/Hub, genügt es beim Ausfall des externen Routers, das DSL-Modem wieder an den fli4l zu hängen, den externen Router vom Switch abzuziehen, fli4l zu booten - und schon sollte fli4l wieder als ganz normaler Router funktionieren.

Fällt lediglich das DSL aus, sollte der ISDN-Fallback ohne jegliches Umstöpseln / Abziehen des externen Routers und Reboot des fli4l zu bewerkstelligen sein: Es genügt, den auf manuelle Einwahl konfigurierten imond via Imonc auf den entsprechenden ISDN-Circuit umzustellen und online zu gehen: Das Routing sollte dann nicht mehr über den externen Router laufen, sondern über die PPP-Verbindung.

Soweit ich es bisher gesehen habe, bringt aber ein derartiges manuelles Routing via ISDN den eigentlich als LAN-Router konfigurierten fli4l hinsichtlich seiner Routing-Tabelle mitunter aus dem Tritt. Eine Rückkehr zum LAN-Routing erfordert dann doch wieder einen Reboot des fli4l, wenn das DSL wieder zur Verfügung steht.

Gero Zahn, 11/2004

Klicken Sie hier, um die Seite auszudrucken.