cipe konfigurieren

[Linuxexplorer]

Hallo

Ich befasse mich gerade mit der Konfiguration von Cipe. Ich werde da nicht ganz schlau draus, ich habe es aber mal versucht:ugly:
Hier meine options:

HOST 1:
ptpaddr: 192.168.101.137
ipaddr: 192.168.101.138
me: lnxexp.dyndns.org:6789
peer: lnxexp2.dyndns.org:6543
key : Hier ist mein Problem: Nämlich wie kann ich so einen Key generieren? Habe in der Doku auch was von PKCIPE gelesen.
Also arbeitet PKCIPE mit PublicKeys und das normale Verfahren mit statischen Keys?

HOST2:
ptpaddr: 192.168.100.137
ipaddr: 192.168.100.138
me: lnxexp2.dyndns.org:6543
peer: lnxexp.dyndns.org:6789
key :

Ich möchte gerne mit statischen Keys arbeiten, wie kann ich diesen generieren, um ihn in der options einzutragen?

Vielen Dank.

MFG: Linuxexplorer

[Harry]

Hallo,

Deine Konfigs sind soweit schon korrekt zusammengeschrieben.
Da CIPE einen 128bit-Key haben möchte, kannst Du Dir dieses "shared Secret" am besten über


md5sum /proc/kcore

generieren.

Und ja: CIPE arbeitet mit shared Secrets und PKCIPE über ein Public-Key Verfahren. :)

Harry

[Linuxexplorer]

Hi Harry!

Vielen Dank für deine Diagnose:D
Jetzt nur noch eine Kleinikeit:

Ich habe irgendwo gelesen, dass ich eine Netzroute setzen muss. Stimmt das?
Und wie muss ich Cipe starten? Reicht es, wenn ich das Kernelmodul lade und den cipe-dämon starte?


MFG: Linuxexplorer

[Harry]

Hallo,

zum Starten von cipe reicht es, das Kernelmodul zu laden und dann den Daemon (mit -c <Konfigdatei>) zu starten.
Eine Netzroute mußt Du in Deinem Fall nicht setzen, da sich beide Rechner sowieso im gleichen Subnetz befinden (soweit lnxexp und lnxexp2 Adressen aus dem gleichen Subnetz haben) .

Wenn Du hinter den Cipe-Gateways Netze hosten würdest, dann bräuchtest Du diese Netzwerkrouten. Idealerweise setzt Du die dann in der Datei /etc/cipe/ip-up (oder in dem Verzeichnis, in dem auch die options liegt).

Harry

[Linuxexplorer]

Hallo!

Ich habe meine Konfiguration jetzt ausprobiert, leider hat's nicht funktioniert.

Zuerst habe ich auf beiden PC's das Kernelmodul geladen. Dann habe ich die Rechner online gebracht und die IP's per ddclient aktualisiert. Ping von dem einen DyndnsAlias zum anderen geht.
Dann habe ich den ciped-cb gestartet. Und nichts geschah, ciped-cb startete schon, jedoch war er nicht mit ps eax zu sehen.
Das war auf beiden Rechnern das selbe Verhalten.

Hier meine options: (leicht modifiziert)
HOST1:
ptpaddr 192.168.20.134
ipaddr 192.168.20.133
me lnxexp.dyndns.org:6789
peer lnxexp2.dyndns.org:6543
key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

HOST2:
ptpaddr 192.168.20.133
ipaddr 192.168.20.134
me lnxexp2.dyndns.org:6543
peer lnxexp.dyndns.org:6789
key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Der cipeDaemon startete eigentlich gar nicht richtig. In der Doku. habe ich gelesen, dass sei so wenn CIPE einen Fehlerfindet (Errorhandling)

Was mache ich falsch?

MFG: Linuxexplorer

[Harry]

Hallo,

Original geschrieben von Linuxexplorer
Der cipeDaemon startete eigentlich gar nicht richtig. In der Doku. habe ich gelesen, dass sei so wenn CIPE einen Fehlerfindet (Errorhandling)

Was mache ich falsch?
in der Konfiguration ist kein Fehler zu entdecken. Auf meiner SuSE läuft's genau so.
Hast Du Logmeldungen beim Starten von cipe?

Harry

[Linuxexplorer]

Hi Harry!

Ich habs! Cipe-cb läuft, und jetzt gibt es auf beiden PC's das Interface cipcb0.
Wie kann ich kontrollieren, ob alles funktioniert, denn ich glaube es funktioniert noch nicht:

Auszug aus /var/log/messages:

Dec 6 08:54:12 linuxdesk kernel: cipcb: CIPE driver vers 1.5.4 (c) Olaf Titz 1996-2000, 2 channels, debug=0
Dec 6 08:54:38 linuxdesk ciped-cb[442]: CIPE daemon vers 1.5.4 (c) Olaf Titz 1996-2000
Dec 6 08:54:38 linuxdesk ciped-cb[442]: kxchg: recv: Connection refused
Dec 6 08:54:52 linuxdesk ciped-cb[442]: peer configuration info: proto=3, crypto=b, version=1.5, correct key parser
Dec 6 08:55:15 linuxdesk kernel: cipcb0: changing my address: 2.0.0.0
Dec 6 08:55:15 linuxdesk kernel: cipcb0: cipe_fakenkey: enqueuing failed
Dec 6 08:55:15 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:15 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:15 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xx.xxx.xxx.xx:6543 L=132 S=0x00 I=53023 F=0x4000 T=64
Dec 6 08:55:16 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:16 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:16 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xx.xxx.xxx.xx:6543 L=132 S=0x00 I=53024 F=0x4000 T=64
Dec 6 08:55:17 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:17 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:17 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xx.xxx.xxx.xx:6543 L=132 S=0x00 I=0 F=0x4000 T=64
Dec 6 08:55:18 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:18 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:18 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xx.xxx.xxx.xx:6543 L=132 S=0x00 I=0 F=0x4000 T=64
Dec 6 08:55:19 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:19 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:19 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xxx.xxxx.xxx.xx:6543 L=132 S=0x00 I=0 F=0x4000 T=64
Dec 6 08:55:20 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:20 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Dec 6 08:55:20 linuxdesk kernel: PROTO=17 2.0.0.0:6789 xxx.xxx.xxx.xxx:6543 L=132 S=0x00 I=0 F=0x4000 T=64
Dec 6 08:55:21 linuxdesk kernel: nf_hook: hook 4 already set.
Dec 6 08:55:21 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132

Die beiden Rechner bleiben jetzt bei Herunterfahren hängen:mad: Kann das Kernelmodul auch nicht entladen, oder das Interface mit ifconfig cipcb0 down abschalten.

CIPE von der Source kompiliert worden:
Kernel 2.4.18
CIPE:1.5.4

MFG: Linuxexplorer

(Bemerkung: Das Datum in den Logs ist schon korrekt so:p )

[Harry]

Hallo Linuxexplorer,

die Funktionsfähigkeit des Tunnels kannst Du z.B. über tcpdump überprüfen.
Gib' auf einem der Rechner das Kommando:


tcpdump -n -i <externes Interface>

an und dann solltest Du im wesentlichen zwischen den beiden VPN-Rechnern nur UDP-Datagramme zwischen den Ports 6543 und 6789 sehen. Falls Du das so beobachtest ist alles ok.

Harry

[Linuxexplorer]

Hi Harry!

Wenn alles ok ist, müsste ich von einem Rechner, der hinter dem HOST1 steht, einen anderen Rechner ,der hinter HOST2 steht, anpingen können, oder ?

z.B. Rechner 1 hat die IP 192.168.101.137 und steht hinter HOST 1. Rechner 2 hat die IP 192.168.100.137 und steht hinter HOST2. Jetzt müsste ich von 192.168.100.137 den Rechner 192.168.101.137 anpingen können. Stimmt das?

Wie ich schon oben geschrieben habe, kann ich das cipcb-Modul mit rmmod nicht entladen. Auch mit Ifconfig kann ich nichts machen (z.B. das Interface cipcb0 mit ifconfig cipcb0 down...).

Was kann ich da machen?

MFG: Linuxexplorer

[Linuxexplorer]

Hi Harry !

Du hast gerschrieben ich müsste keine Netzroute setzen, wenn sich lnxexp und lnxexp2 im gleichen Subnetz befinden würden. Leider befinden sie sich nicht im gleichen Subnetz: lnxexpt: 194.230.xxx.xxx lnxexp2:194.230.xxx.xxx, soweit sind die IP's identisch, aber dann unterscheiden sie sich.

Wie muss ich nun die Netzroute setzen?

Wenn alles läuft, müsste ich von einem WIndowsclient einen anderen Windowsclient im anderen Subnetz anpingen können, oder?

BSP: Rechner 1 hat die IP 192.168.100.196 und steht hinter HOST1. Rechner 2 hat die IP 192.168.20.196 und steht hinter HOST2. Jetzt müsste ich von 192.168.100.196 mit ping 192.168.20.196 den Rechner 2 erreichen können, oder?

Hier noch ein Auszug aus /var/log/messages:

cipbcb: read_lock(&tasklist_lock) at ../cipe/device.c:216
.....
.....

Noch was: Was muss ich bei den Clients konfigurieren, so dass das VPN läuft ?

Vielen Dank.

MFG: Linuxexplorer

[Harry]

Hallo Linuxexplorer,

gerade ist mir doch ein Fehler in Deiner CIPE-Konfiguration aufgefallen.
Zum Hintergrund: Grundsätzlich konfigurierst Du mit CIPE ein VPN, indem Du für das VPN (HOST1-HOST2) einen neuen Netzwerk-Adressbereich nimmst; idealerweise einen Bereich, der weder in Deinen Netzen Verwendung findet noch im Internet. Der VPN-Tunnel wird somit über rein fiktive IP-Adressen aufgebaut und diese Adressen haben nichts mit Deinen realen IP-Adressen im LAN oder zum Internet zu tun.

Wenn Du also auf Host1 konfigurierst:


HOST 1:
ptpaddr 192.168.101.137
ipaddr 192.168.101.138
me lnxexp.dyndns.org:6789
peer lnxexp2.dyndns.org:6543
key ...

dann mußt Du auf dem Host2 lediglich die gesamten Adressdaten tauschen (physikalisch existierende -> me + peer, virtuelle für das VPN -> ipaddr + ptpaddr).


HOST 2:
ipaddr 192.168.101.137
ptpaddr 192.168.101.138
peer lnxexp.dyndns.org:6789
me lnxexp2.dyndns.org:6543
key ...

Nach dem Verbindungsaufbau kannst Du dann direkt zwischen den Gateways über den VPN arbeiten, wenn Du einen der beiden Hosts über die virtuellen VPN-IPs (192.168.101.137 oder ...138) adressierst.

Möchtest Du jetzt jeweils ein Netzwerk hinter jedem Gateway tunneln, dann benötigst Du auf den Gateways die Netzwerkrouten, die das Partnergateway adressieren.
Angenommen, Du hast das Netzwerk 192.168.100.0/24 hinter HOST1 und das Netzwerk 192.168.20.0/24 hinter HOST 2. Dann benötigst Du die folgenden Routen:


HOST 1:
route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.101.138

HOST2:
route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.101.137

Den Clients in den jeweiligen Netzen solltest Du als Default-Gateway oder als Gateway für das eine Partnernetz das im gleichen Netzwerk befindliche VPN-Gateway mitteilen.

Harry

[Linuxexplorer]

Hi Harry !

Vielen Dank für deine Hilfe!:) Jetzt funktioniert alles wunderbar.

MFG: Linuxexplorer

[Harry]

Hallo Linuxexplorer,

na dann viel Spaß mit Deinem VPN und verlier auf keinen Fall den Key zum Entschlüsseln :D

Harry

[Linuxexplorer]

Verdammt, ich glaube ich zuvoreilig!:mad:
Ein Ping geht durch das VPN, der Rest verschwindet irgendwo:eek:
Wenn ich von Host 2 den Host1 anpingen, und auf Host1 tcpdump -n eth0 starte, sehe ich zwar Packte von Host2, jedoch werden diese nicht weitergeleitet.

Ich erhalte auch so merkwürdige Fehlermeldungen:

Oct 16 14:28:05 linuxdesk kernel: nf_hook: hook 4 already set.
Oct 16 14:28:05 linuxdesk kernel: skb: pf=2 (owned) dev=eth0 len=132
Oct 16 14:28:05 linuxdesk kernel: PROTO=17 2.0.0.0:6789 62.xxx.xxx.xxx:6543 L=132 S=0x00 I=14871 F=0x0000 T=255

Hier meine neuen options:

ptpaddr 192.168.101.137
ipaddr 192.168.101.138
me lnxexp.dyndns.org:6789
peer lnxexp2.dyndns.org:6543
key 82c90262ffcd7697541dba84f37202b7

ipaddr 192.168.101.137
ptpaddr 192.168.101.138
me lnxexp2.dyndns.org:6543
peer lnxexp.dyndns.org:6789
key 82c90262ffcd7697541dba84f37202b7

Auf beiden Rechnern ist cipcb0 vorhanden:

cipcb0 Link encap:IPIP Tunnel HWaddr
inet addr:192.168.101.138 P-t-P:192.168.101.137 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100


cipcb0 Link encap:IPIP Tunnel HWaddr
inet addr:192.168.101.137 P-t-P:192.168.101.138 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1
RX packets:39 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100

Ich habe auch noch andere gefunden, die das selbe Problem haben:
http://sites.inka.de/bigred/archive/cipe-l/2001-06/msg00021.html

Vielen Dank.

PS: Mein IPtables: iptables v1.2.6a Kernel: 2.4.18 CIPE: 1.5.4

BMK: Dieser Beitrag wird im Securityforum weitergeführt.

MFG: Linuxexplorer