von Michael Köhler (mit tatkräftiger Unterstützung von Markus Reile und der Newsgroup spline.fli4l). Angepasst für die neuen cipe-Versionen (von Georg Kainzbauer) von Markus Reile
Einfachstes Szenario: Die Firma ABC hat zwei Niederlassungen. In Einstein und in Zweistein. Jede Niederlassung hat sein eigenes Netzwerk (Einstein: 10.0.1.x; Zweistein: 10.0.2.x) und auch seinen eigenen Administrator. Nun muß aus Kostengründen der Admin der Niederlassung Zweistein entlassen werden und der Admin aus Einstein soll auch das Netz von Zweistein pflegen. Um nun nicht ständig herumzufahren mietet der Admin jeweils für Einstein und für Zweistein eine DSL-Leitung und baut sich zwei FLI4L-Router.
Und so sieht dann sein Netz aus:
Netz FLI4L FLI4L Netz Einstein Einstein Zweistein Zweistein 10.0.1.x ----- 10.0.1.1 ----- DSL ----- Internet ----- DSL ----- 10.0.2.1 ----- 10.0.2.x
Jetzt können zwar alle Computer aus dem Netz Einstein und Zweistein jeweils ins Internet. Aber der FLI4l maskiert die internen Netze der Niederlassungen (d.h. sie sind von außen unsichtbar). Somit kann der Admin nicht vom Netz Einstein auf das Netz Zweistein zugreifen.
Da er aber genau das will, greift er zum opt_cipe!
Es macht den gegenseitigen Zugriff von zwei maskierten Netzen möglich und um das ganze auch sicher zu machen, wird die Verbindung verschlüsselt.
Das ist recht einfach zu erklären: Es wird eine virtuelle Netzwerkkarte eingerichtet, die die verschlüsselte Verbindung herstellt. Das Ganze läuft dann über einen Port, den man frei definieren kann (in meinem Beispiel ist es Port 4444) ab. Wenn man es kompliziert machen will, kann man für jede Richtung einen eigenen Port verwenden ;-)
Und so sieht das dann als Blockschaltbild aus:
Netz FLI4L FLI4L Netz
Einstein Einstein Zweistein Zweistein
10.0.1.x ----- 10.0.1.1 ----- DSL ----- Internet ----- DSL ----- 10.0.2.1 ----- 10.0.2.x
über Port über Port
4444 4444
wird eine wird eine
weitere weitere
Netzwerkkarte Netzwerkkarte
getunnelt getunnelt
10.0.3.1 ---------------------------------------- 10.0.3.2
das ist die virtuelle Verbindung
Damit sich nicht jeder mit unserem Netz verbinden kann, gibt es mehrere Sicherheitseinstellungen.
Auf beiden FLI4L muß die IP des gegenüber eingetragen werden. Da das in Zeiten von DSL und der dynamischen Vergabe recht schwierig wird, sollte man auf einen dyn. DNS-Service zurückgreifen.
Dazu wird auf das Mini-Howto für DynDNS und FLI4L hingewiesen.
Es wird ein Passwort eingerichtet. Dieses kann man selbst bestimmen, es wird aber empfohlen dies mit mit einem Tool zu erledigen, da so das Herausfinden des Passwortes erschwert wird. Dazu nehmen wir MD5SUM, ein Tool aus der Unix-Welt, welches Checksummen erstellt (und damit ziemlich einmalige Passwörter).
Hier findet sich auch eine Windows-Variante. Dazu kopiert man md5sum.exe in ein beliebiges Verzeichnis. Dann ruft man die MS-DOS Eingabeaufforderung auf und wechselt in das Verzeichnis. Mit einem "dir" und einem anschließenden "md5sum" erzeugt man einen Code, den man sich kopieren sollte. Dieser stellt später unser Passwort dar.
Die Übertragung der Daten selber erfolgt in einer 128Bit-Verschlüsselung.
Für die Experten: in den Binaries ist die Blowfish-Verschlüsselung einkompiliert
Nach dem Entpacken des opt_cipe befindet sich im Verzeichnis config eine Datei cipe.txt. Diese wird nun editiert.
OPT_CIPE='yes' # denn wir wollen das opt ja aktivieren
CIPE_DEBUG='no' # kann zur Fehlersuche auf yes gesetzt werden
CIPE_N='1' # wieviele Verbindungen wollen wir von dem Router aus aufbauen?
CIPE_1_REMOTE_INTERFACE_ADDR='10.0.3.2' # Die Adresse des anderen Routers im Cipe Netzwerk
CIPE_1_REMOTE_ADDR='zweistein.dynaccess.de' # Hier muß die IP oder die Domain des
# zu verbindenden Routers eingetragen werden
# In unserem Beispiel ist es der DynDNS-Account des Partners
CIPE_1_REMOTE_PORT='4444' # Die Portnummer des Partners, die bei diesem im Paketfilter nicht gesperrt sein darf
CIPE_1_LOCAL_DIALUP='yes' # yes - der eigene Anschluss verwendet eine dynamische IP Adresse
CIPE_1_LOCAL_INTERFACE_ADDR='10.0.3.1' # Unsere Adresse im Cipe Netz
CIPE_1_LOCAL_ADDR='0.0.0.0' # Die Adresse des eigenen Routers (muß 0.0.0.0 bleiben, da dynamische IP)
CIPE_1_LOCAL_PORT='4444' # lokaler Port (kann gleich dem Remote Port sein)
CIPE_1_KEY='0123456789ABCDEF0123456789ABCDEF' # hier muss das Passwort rein, welches wir mit MD5SUM erstellt haben
# dieses Passwort MUSS auf beiden Routern gleich sein
CIPE_1_ROUTE='10.0.2.0/255.255.255.0' # Adresse des Netzes auf der anderen Seite, in das geroutet werden soll
Mehrere Routen können im Bedarfsfall durch Leerzeichen getrennt angegeben werden.
WICHTIG: Im Prinzip erkennt man hier nun schon, dass auch mehrere Router zu einem Netz zusammengeschlossen werden können. Dazu muß die Variable CIPE_N angepaßt und jede Variable (z.B. CIPE_x_REMOTE_INTERFACE_ADDR) kopiert werden. Virtuell wird dann sozusagen sternförmig verkabelt!
Diese Einstellungen müssen auf beiden Routern gemacht werden, so das die cipe.txt folgendermaßen aussehen:
#cipe.txt auf Router "Einstein" OPT_CIPE='yes' CIPE_DEBUG='no' CIPE_N='1' CIPE_1_REMOTE_INTERFACE_ADDR='10.0.3.2' CIPE_1_REMOTE_ADDR='zweistein.dynaccess.de' CIPE_1_REMOTE_PORT='4444' CIPE_1_LOCAL_DIALUP='yes' CIPE_1_LOCAL_INTERFACE_ADDR='10.0.3.1' CIPE_1_LOCAL_ADDR='0.0.0.0' CIPE_1_LOCAL_PORT='4444' CIPE_1_KEY='0123456789ABCDEF0123456789ABCDEF' CIPE_1_ROUTE='10.0.2.0/255.255.255.0' #ende #cipe.txt auf Router "Zweistein" OPT_CIPE='yes' CIPE_DEBUG='no' CIPE_N='1' CIPE_1_REMOTE_INTERFACE_ADDR='10.0.3.1' CIPE_1_REMOTE_ADDR='einstein.dynaccess.de' CIPE_1_REMOTE_PORT='4444' CIPE_1_LOCAL_DIALUP='yes' CIPE_1_LOCAL_INTERFACE_ADDR='10.0.3.2' CIPE_1_LOCAL_ADDR='0.0.0.0' CIPE_1_LOCAL_PORT='4444' CIPE_1_KEY='0123456789ABCDEF0123456789ABCDEF' CIPE_1_ROUTE='10.0.1.0/255.255.255.0' #ende
Wichtig ist, das der Port, der in der cipe.txt ausgesucht wurde (in unserem Fall 4444) NICHT im Paketfilter von fli4l geblockt wird.
Damit sind wir am Ende. Nach einem Reboot sollte alles funktionieren.
Dann sollte man folgendes probieren:
auf Router "Einstein" einloggen und folgende Tests durchführen:
lsmod # ist das Kernelmodul geladen
Ausgabe:
------------------------------------------- cipcb 27724 1 -------------------------------------------
Wenn das Modul nicht geladen wurde, so kann cipe nicht funktionieren. Evtl. ist bei der Abarbeitung der
ip-up.cipe was schiefgegangen, was man evtl. durch einen Blick in /var/log/messages herausfinden kann.
Das Modul kann mit dem Kommando
insmod cipcbvon Hand geladen werden
ps -e #Ist Cipe überhaupt gestartet?
In der Liste sollte folgender Eintrag stehen (xxx steht für eine Zahl)
------------------------------------------- xxx root root S /sbin/ciped-cb -o /etc/cipe/options-1 -------------------------------------------
Falls es keinen solchen Prozess in der Prozessliste gibt, so kann der erste cipe-Daemon auch von Hand gestartet werden:
/sbin/ciped-cb -o /etc/cipe/options-1
ifconfig #nachschauen, ob das Cipe-Device da ist
Es sollte folgendes auf der Console stehen:
-------------------------------------------
cipcb0 Link encap:UNSPEC HWaddr 00-00-5E-B2-00-90-00-3B-00-00-00-00-00-00-00-00
inet addr:10.0.3.1 P-t-P:10.0.3.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1418 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1360 (1.3 kb) TX bytes:0 (0.0 b)
-------------------------------------------
ping 10.0.3.1 #das eigene Ende des Cipe-Gateways anpingen
Wenn das nicht funktioniert, ist was mit den Einträgen in der eigenen cipe.txt schiefgelaufen. Oder das Cipe-Device ist nicht da (siehe oben)
ping zweistein.dynaccess.de #die dyndns-Adresse des anderen Routers anpingen
Achtung: Nach der Einwahl benötigen die DynDNS-Provider meist zwischen einigen Sekunden und einigen Minuten, bis die DNS-Auflösung aktiviert ist. Vorteilhaft wäre eine Aktivierung des mini_httpd (opt_httpd='yes' in httpd.txt) und DYNDNS_SAVE_OUTPUT='yes' in der dyndns.txt
ping 10.0.3.2 #das andere Ende des Cipe-Gateways auf dem anderen Router anpingen
Wenn das klappt, ist das schon die Dreiviertelmiete ;-)
Ein Fehler kann hier an vielen Ecken stecken:
ping 10.0.2.1 #den anderen Router anpingen
Wenn das nicht klappt, stimmt der Routing-Eintrag in den cipe-Configs nicht. Das Routing kann folgendermassen von Hand gestartet werden:
/etc/ppp/ip-up-1
Und natürlich auch auf Router "Zweistein" die gleichen Prüfungen durchführen:
lsmod #Ist das Kernelmodul geladen?
ps -e #Ist Cipe überhaupt gestartet?
ifconfig #nachschauen, ob das Cipe-Device da ist
ping 10.0.3.2 #das eigene Ende des Cipe-Gateways anpingen
ping einstein.dynaccess.de #die dyndns-Adresse des anderen Routers anpingen
ping 10.0.3.1 #das andere Ende des Cipe-Gateways auf dem anderen Router anpingen
ping 10.0.1.1 #den anderen Router anpingen
Zu Debugging Zwecken oder für diejeniegen, die es genau wissen wollen, kommt hier eine kurze Anleitung, wie man cipe von Hand startet.
/sbin/insmod cipcb
/sbin/ciped-cb -o /etc/cipe/options-1
/etc/ppp/ip-up-1
Falls cipe immer noch nicht funktionieren sollte, ist ein Blick in die Datei /var/log/messages ganz sinnvoll. In Verbindung mit den Debugging-Methoden und dem Start von Hand sollte man so den Fehler finden.
fli4l kernel: cipcb: CIPE driver vers 1.6.pre-20020224 (c) Olaf Titz 1996-2000, 100 channels, debug=1 fli4l kernel: cipcb: cipe_alloc_dev 0 fli4l ciped-cb[1793]: CIPE daemon vers 1.6.pre-20020224 (c) Olaf Titz 1996-2000 fli4l kernel: cipcb0: alloc fli4l kernel: cipcb0: setpar fli4l kernel: lebf_lock: 1 fli4l kernel: cipcb0: setpar 0.0.0.0:0 1000 60000 0600 64 fli4l kernel: cipcb0: setkey fli4l kernel: cipcb0: attach fli4l kernel: cipcb0: opened fli4l kernel: cipcb0: cipe_sendmsg fli4l kernel: cipcb0: cipe_recvmsgSo oder so ähnlich sieht es aus, wenn cipe ordnungsgemäss startet.
fli4l kernel: kxchg: recv: Connection refusedbedeutet, das auf dem angegebenen Port nix horcht. Lösung: Schau, ob die Ports wirklich in beiden CIPE.TXT gleich sind und ob eventuell der Port in der Firewall gesperrt ist.
fli4l kernel: cipcb0: cipe_recvmsgalles OK. Cipe deutet dadurch alle paar Minuten an, dass der Tunnel noch besteht.
kommt bald...
Da die meisten trockene Erklärungen nicht lesen mögen, folgen an dieser Stelle noch einige ausführliche Beispiele, die spezielle Konfigurationsvarianten des opt_cipe darstellen sollen.
kommt bald...
Normalerweise wird opt_cipe dazu verwendet, um 2 verschiedene Netze über ein drittes Netz zu verbinden. Mit etwas mehr Aufwand beim Routing ist es aber auch möglich, Hosts in zwei gleichnamigen Netzen zu verbinden.
Zum besseren Verständnis eine kleine Darstellung:
Wir haben zwei Netze "Feuerstein" und "Simpsons", beide 192.168.0.0/24. Im Netz "Feuerstein" befinden sich der Fli4l-Router "dino" und die beiden Hosts "fred" und "barny", im Netz "Simpsons" der FLi4l-Router "maggie" und die Hosts "homer" und "bart".
Zunächst benötigen wir eine cipe-Verbindung der beiden Router über entsprechende cipe-Devices. Deswegen legen wir auf den Routern folgende cipe.txt an:
#cipe.txt auf Router dino ("Feuerstein"):
OPT_CIPE='yes'
CIPE_DEBUG='no'
CIPE_N='1'
CIPE_1_REMOTE_INTERFACE_ADDR='192.168.111.2'
CIPE_1_REMOTE_ADDR='simpsons.dtdns.de'
CIPE_1_REMOTE_PORT='4444'
CIPE_1_LOCAL_DIALUP='yes'
CIPE_1_LOCAL_INTERFACE_ADDR='192.168.111.1'
CIPE_1_LOCAL_ADDR='0.0.0.0'
CIPE_1_LOCAL_PORT='4444'
CIPE_1_KEY='0123456789ABCDEF0123456789ABCDEF'
|
#cipe.txt auf Router maggie ("Simpsons"):
OPT_CIPE='yes'
CIPE_DEBUG='no'
CIPE_N='1'
CIPE_1_REMOTE_INTERFACE_ADDR='192.168.111.1'
CIPE_1_REMOTE_ADDR='feuerstein.dtdns.de'
CIPE_1_REMOTE_PORT='4444'
CIPE_1_LOCAL_DIALUP='yes'
CIPE_1_LOCAL_INTERFACE_ADDR='192.168.111.2'
CIPE_1_LOCAL_ADDR='0.0.0.0'
CIPE_1_LOCAL_PORT='4444'
CIPE_1_KEY='0123456789ABCDEF0123456789ABCDEF'
|
Bis hierher ergibt sich also noch keine Änderung im Vergleich zur Konfiguration mit Netz-Routen. Nun aber müssen wir in den cipe.txt die Rechner im Netz "Feuerstein" über einzelne Host-Routen mit den Rechnern im Netz "Simpsons" verbinden. Um eine Host-Route zu setzen, verfährt man analog zu den Netzrouten, verwendet jedoch als Netzmaske die 255.255.255.255.
Um alle 4 Hosts miteinander zu verbinden, werden in den cipe.txt folgende Routing-Einträge gesetzt:
#...Fortsetzung der cipe.txt auf dino: # Route zu homer und bart CIPE_1_ROUTE='192.168.0.44/255.255.255.255 192.168.0.46/255.255.255.255' |
#...Fortsetzung der cipe.txt auf maggie: # Route zu fred und barny: CIPE_1_ROUTE='192.168.0.23/255.255.255.255 192.168.0.26/255.255.255.255' |
Nun müssen wir in den base.txt der beiden Router analog zu den Netz-Routen das Masquerading und das Durchreichen aller Ports für die verwendeten Netze anpassen. (Wie man sieht, sind diese Anpassungen auf beiden Routern identisch):
Wenn wir die Rechner auf der anderen Seite der cipe-Verbindung anstatt mit der IP-Adresse auch mit dem Hostnamen ansprechen wollen, müssen wir auf beiden Routern das DNS starten. Beide Seiten müssen den gleichen Domain-Namen verwenden und es müssen alle Hosts eingetragen werden:
#...Fortsetzung der base.txt auf dino: START_DNS='yes' DOMAIN_NAME='cipe-lan' HOSTS_N='6' # Eigenes LAN: HOST_1='192.168.0.1 dino' HOST_2='192.168.0.23 fred' HOST_3='192.168.0.26 barny' # Anderer Router im "cipe" LAN: HOST_4='192.168.111.2 maggie' # "cipe" LAN: HOST_5='192.168.0.44 homer' HOST_6='192.168.0.46 bart' |
#...Fortsetzung der base.txt auf maggie: START_DNS='yes' DOMAIN_NAME='cipe-lan' HOSTS_N='6' # Eigenes LAN: HOST_1='192.168.0.1 maggie' HOST_2='192.168.0.44 homer' HOST_3='192.168.0.46 bart' # Anderer Router im "cipe" LAN: HOST_4='192.168.111.1 dino' # "cipe" LAN: HOST_5='192.168.0.23 fred' HOST_6='192.168.0.26 barny' |
Somit haben wir alle Änderungen auf beiden Routern durchgeführt. Die Hosts in den beiden Netzen verwenden ihre jeweiligen Router als Gateways ins jeweilige andere Netz. Da aber ein Host bei einem Zugriff ins Netz 192.168.0.0/24 nicht das Gateway benutzt, müssen wir das den Hosts noch explizit beibringen. Dies bedeutet, dass auch auf den Hosts die Host-Routen gesetzt werden müssen. Auf Windows-Rechnern geschieht das durch folgende Eintragungen, die man am besten als Batch-Datei im Autostart-Ordner ausführen lässt:
#Datei: cipe_route.bat #Setzen der Routen auf fred und barny route add 192.168.0.44 mask 255.255.255.255 192.168.0.1 route add 192.168.0.46 mask 255.255.255.255 192.168.0.1 |
#Datei: cipe_route.bat #Setzen der Routen auf homer und bart route add 192.168.0.23 mask 255.255.255.255 192.168.0.1 route add 192.168.0.26 mask 255.255.255.255 192.168.0.1 |
Nun haben wir es geschafft und alle 4 Hosts sollten sich untereinander sehen. Durch das DNS funktionieren auch die Windowsfreigaben. Lediglich Broadcasts werden nicht ins entfernte LAN gesendet, wodurch z.B. das "Computer suchen" im Explorer oder die Server-Suche in Netzwerkspielen nicht funktioniert.
Alle Rechte liegen bei Michael Köhler.
HTML Anpassung, Beispiel zu den Host-Routen und Anpassung an die neue opt-cipe-Version von Markus Reile.
Die aktuelle Version dieses Howto`s finden sie hier.
Klicken Sie hier, um die Seite auszudrucken.