|
Seite 1 von 2 Fernwartung eines Netzes über das Internet (mit Hilfe von opt_cipe) Wolfgang erklärt den Aufbau eines VPN (virtual private network) zur Fernwartung eines entfernten LAN von zu Hause aus.
Beide Netze - das entfernte wie das Heimnetz - sind über DSL-Flatrate mit dem Internet verbunden und haben feste Domainnamen mit Hilfe von DynDNS.
Als Router wird jeweils fli4l benutzt.
das opt_cip macht den gegenseitigen zugriff von zwei maskierten netzen möglich und um das ganze auch sicher zu machen, wird die verbindung verschlüsselt. voraussetznung ist natürlich eine funktionierende fl4l installation. bei mir läuft das alles mit dsl ob's mit isdn geht habe ich nicht getestet, aber warum eigentlich nicht?! 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 dein.netz deinrouter anderer.router anderes.netz
192.168.0.0 - 192.168.0.10 ---- dsl ---- internet ---- dsl ---- 192.168.1.1 - 192.168.1.0
über port über port
4444 4444
wird eine wird eine
weitere weitere
n????-etzwerkkarte netzwerkkarte
getunnelt getunnelt
192.168.2.10 ------------------------------------- 192.168.2.1
das ist die virtuelle verbindung
nach oben 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 ich hier dynamischen ip's nutze, greife ich auf das paket opt_dyndns zu. und ich bemühe einen dyn. dns-service. 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). 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 oben nach dem entpacken des opt_cipe befindet sich im verzeichnis config eine datei cipe.txt. diese wurde nun editiert. diese einstellungen müssen auf beiden routern gemacht werden, so das die cipe.txt folgendermaßen aussehen: # der router im anderen netz
#cipe.txt auf router "anderer.router"
opt_cipe='yes'
cipe_debug='no'
cipe_n='1'
cipe_1_remote_interface_addr='192.168.0.10'
cipe_1_remote_addr='anderer.router.dyndns.dk'
cipe_1_remote_port='4444'
cipe_1_lo????-cal_dialup='yes'
cipe_1_local_interface_addr='192.168.1.1'
cipe_1_local_addr='0.0.0.0'
cipe_1_local_port='4444'
cipe_1_key='0123456789abcdef0123456789abcdef' # das verrate ich nicht
cipe_1_route='192.168.2.0/255.255.255.0'
#ende
# von hier läuft die fernwartung
#cipe.txt auf router "dein.router"
opt_cipe='yes'
cipe_debug='no'
cipe_n='1'
cipe_1_remote_interface_addr='192.168.1.1'
cipe_1_remote_addr='dein.router.dyndns.dk'
cipe_1_remote_port='4444'
cipe_1_local_dialup='yes'
cipe_1_local_interface_addr='192.168.0.10'
cipe_1_local_addr='0.0.0.0'
cipe_1_local_port='4444'
cipe_1_key='0123456789abcdef0123456789abcdef' # dito
cipe_1_route='192.168.2.0/255.255.255.0'
#ende
wichtig ist, das der port, der in der cipe.txt ausgesucht wurde (in diesem fall 4444) nicht im paketfilter von fli4l geblockt wird. nach oben von meinem router "dein.router" habe ich folgende tests durchgeführt:
-
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.
das nodul kann mit dem kommando insmod cipcb
von 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 nask:255.255.255.255
up pointopoint running noarp ntu:1418 netric:1
rc packets:13 errors:0 dropped:0 overruns:0 frame:0
tc packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
rc bytes:1360 (1.3 kb) tc bytes:0 (0.0 b)
-------------------------------------------
-
ping 192.168.2.10 #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 anderer.router.dyndns.dk #die dyndns-adresse des anderen routers anpingen
achtung: nach der einwahl benötigen die dyndns-provider meist zwischen einigen sekunden und einigen ninuten, 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. oder erst mal eine xbeliebige internet verbindung aufbauen, z.b www.ahrlug.de und wieder schließen -
ping 192.168.2.1 #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: - erstes problem: der fehler kann auch auf der gegenseite liegen!
- das portforwarding ist bei der einwahl des routers ins netz nicht ordnungsgemäss abgelaufen
- nachschauen, ????-ob der port von der firewall nicht geblockt wird
- fehler in der cipe-config - alles nochmal genau mit der des gegenüberliegenden routers vergleichen
-
ping 192.168.1.1 #den anderen router anpingen
wenn das nicht klappt, stimmt der routing-eintrag in den cipe-configs nicht.
und natürlich auch auf router "anderer.router" 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 192.168.2.1 #das eigene ende des cipe-gateways anpingen -
ping dein.router.dynaccess.de #die dyndns-adresse des anderen routers anpingen -
ping 192.168.2.10 #das andere ende des cipe-gateways auf dem anderen router anpingen -
ping 192.168.0.10 #den anderen router anpingen nach oben zu debugging zwecken oder für diejeniegen, die es genau wissen wollen, kommt hier eine kurze anleitung, wie man cipe von hand startet. - kernelmodul laden:
/sbin/insmod cipcb - cipe-device starten: (bei mehreren devices die 1 entsprechend hochzählen)
/sbin/ciped-cb -o /etc/cipe/options-1 - route setzen:
/etc/ppp/ip-up-1 nach oben fli4l Kernel: kxchg: recv: connection refused bedeutet, das auf dem angeg????-ebenen port nix horcht. lösung: schau, ob die ports wirklich in beiden cipe.tct gleich sind und ob eventuell der port in der firewall gesperrt ist. fli4l kernel: cipcb0: cipe_recvmsg alles ok. cipe deutet dadurch alle paar ninuten an, dass der tunnel noch besteht.
diese neldungen können mit cipe_debug='no' abgeschalten werden. nach oben |
<< Anfang < Vorherige 1 2 Nächste > Ende >>
|
Tips & Tricks 
