Wieder mal OpenVPN

derMaWi

Neuer User
Mitglied seit
16 Mrz 2008
Beiträge
21
Punkte für Reaktionen
0
Punkte
0
Hallo!

Ich habe nun schon länger heir im Forum mitgelesen und hab auch enldihc mal angefangen meine FB 7050 (FW 14.04.33) bisschen zu tunen. Soweit läuft auch alles nur bin ich mir beim OpenVPN nicht so ganz sicher ob das alles stimmt was ich gemacht habe. Wär nett, wenn sich das mal jemand anschauen würde! :)
Mein Ziel ist es nicht 2 FB zu verbinden, ich möchte nur auf der oben genanten FB 7050 den VPN Server laufen haben, sodass ich (bzw. wenn möglich auch mehrere Maschinen, aber vorerst reicht erstmal eine) mich von jedem Ort per VPN in das Heim-LAN verbinden kann.
Das ganze wollte ich über TAP devices machen, sodass ich auch wirklich für die Windows-Rechner im Heim-LAN "sichtbar" bin.

Meine server.ovpn:
Code:
dev tap0
dev-node /var/tmp/tun
proto udp
port 1194

ca /var/tmp/vpn/ca.crt
cert /var/tmp/vpn/server1.crt
key /var/tmp/vpn/server1.key
dh /var/tmp/vpn/dh1024.pem

mode server
client-to-client
tls-server
comp-lzo
tun-mtu 1500
tun-mtu-extra 32

float
verb 4

ping-timer-rem
keepalive 20 180

die client.ovpn:
Code:
client
remote blabla.dyndns.org 1194
proto udp
dev tap
dev-node VPN

ca C:\\OpenVPN\\easy-rsa\\keys\\ca.crt
cert C:\\OpenVPN\\easy-rsa\\keys\\client1.crt
key C:\\OpenVPN\\easy-rsa\\keys\\client1.key

verb 4
mute 50
comp-lzo
ns-cert-type server

in der ar7.cfg im router hab ich außerdem noch folgendes eingetragen:
Code:
"udp 0.0.0.0:1194 0.0.0.0:1194",

Auf meinem Laptop (der Client) habe ich die VPN Verbindung und die WLAN Verbindung bereits überbrückt. Leider befindet sich der Client momentan selbst im LAN der FB 7050. Ich kann momentan noch nicht wirklich testen ob auch ein zugriff von außerhalb funktioniert.

Eine Verbindung kommt aber schon mal zustande. Sowohl bei Verwendung des DnyDNS eintrags als auch bei Verwendung von 192.168.0.1 (IP der Box).

Allerdings bin ich mir nicht so ganz sicher: Muss ich nun noch irgendwelche Devices bei der FB überbrücken? Wenn ja welche und wie geht das?
Ich habe momentan in der ar7.cfg lediglich noch das verändert:
Code:
interfaces = "eth0", [COLOR="Red"][B]"tap0"[/B][/COLOR], "usbrndis", "eth1", "tiwlan0", "wdsup0", 
                             "wdsdw0", "wdsdw1", "wdsdw2", "wdsdw3";
Reicht das oder muss ich noch irgendwas machen?

Außerdem noch die Frage: So wie ich das verstanden hab muss ich beim Bridgen nichts routen etc ... Ist das wirklcih so? D.h. mit den Configs von oben müsste ich ohne Probleme ovn außerhalb in das LAN kommen können? oder müssen doch irgendwelche Routen gesetzt werden?

Und dann fällt mir noch eine Frage ein: Unter welcher IP ist der Client dann im Netzwerk zu erreichen? Wenn cih mich verbinde gibt der Server folgendes aus:
Code:
Sun Mar 16 15:36:09 2008 us=160360 111.111.111.111:61003 [client1] Peer Connection Initiated with 111.111.111.111:61003
Sun Mar 16 15:36:09 2008 us=161968 client1/111.111.111.111.168:61003 MULTI: no dynamic or static remote --ifconfig address is available for client1/111.111.111.111:61003
Sun Mar 16 15:36:10 2008 us=212330 client1/111.111.111.111:61003 PUSH: Receivedcontrol message: 'PUSH_REQUEST'
Sun Mar 16 15:36:10 2008 us=213906 client1/111.111.111.111:61003 SENT CONTROL [client1]: 'PUSH_REPLY,ping 20,ping-restart 180' (status=1)
Sun Mar 16 15:36:11 2008 us=431712 client1/111.111.111.111:61003 MULTI: Learn: 00:ff:8e:5b:5e:8e -> client1/111.111.111.111:61003
Sun Mar 16 15:36:20 2008 us=386671 client1/111.111.111.111:61003 MULTI: Learn: 02:1b:77:c3:ba:3a -> client1/111.111.111.111:61003
111.111.111.111 ist die WAN Adresse des Box. Wieso bekommt der client keien IP aus dem Subnet der FB zugewiesen? Und wieso läuft da was auf port 61003? Sieht für mcih irgendwie bisschen komisch aus :(

Hoffe jemand liest sich den alngen Beitrag durch und hat vielleicht den ein oder anderen Tip parat! Danke schonmal! :)
 
Ich möchte ja nicht nerven oder so :oops: ... Aber wär schön wenn sich wer meldet bevor der Thread in den tiefen des Forum untergeht ;) Ich komm einfach nich weiter.

EDIT: Ach und was mir grad ncoh einfällt: Ich sehe hier oft dass die Leute hier ihren SSH Server (aslo Dropbear) auf der virtuellen ip 192.168.178.263:22 laufen haben und eben demenstprechend routen. Was ist das für eine IP? Und wieso wird das meistens so gemacht? Ich hab das bis jetzt immer mit einem routing von 0.0.0.0:22 direkt auf 192.168.X.1:22 gemacht? Ist das eine schlechtere Lösung?

Danke schonmal im voraus!
 
Zuletzt bearbeitet:
Moin,

ein wenig mehr Geduld darfst du schon haben, speziell am Wochenende ;-).

Du hast in der Severconfig nicht eingetragen, dass der Server IPs vergeben soll, daher macht er das auch nicht. Bei einem Windowsclient könnte das evtl durch den DHCP der Box "ausgeglichen" werden, bei Box2Box geht das so nicht (denn die Box macht keinen echten DHCP-Request auf dem TUN/TAP Interface).

Beim "Bridging" wird das tap-Interface auf der einen Seite "mit dem auf der anderen verbunden". Damit "sehen" sich erstmal nur die beiden taps. Mit dem Eintrag in "brinterfaces" kann man dann das tap wieder mit dem LAN verbinden.

Wenn also eine IP-Verbindung sein soll, musst du das den Boxen sagen. Entweder "verteilt" die Serverbox die IPs (mit ifconfig und ifconfig-pool) oder die Clients bekommen eine fest eingetragen (mit ifconfig).

Das Portforwading so ist nur in sofern "schlechter", dass du es jetzt wohl nicht mehr ändern kannst, weil die Box sich beschwert, wenn ein Forwarding auf eine lokale IP existiert...

Jörg
 
ein wenig mehr Geduld darfst du schon haben, speziell am Wochenende. ;)

Alles klar! ;)

Du hast in der Severconfig nicht eingetragen, dass der Server IPs vergeben soll, daher macht er das auch nicht. Bei einem Windowsclient könnte das evtl durch den DHCP der Box "ausgeglichen" werden, bei Box2Box geht das so nicht (denn die Box macht keinen echten DHCP-Request auf dem TUN/TAP Interface).

Moment: Hab mich vielleict oben wirklich etwas doof ausgedrückt... Ich möchte keine 2 kompletten Netzwerke verbinden. Also kein Box2Box. Bei mir sieht das viel eher so aus:

PC1, PC2, PC3 <--->FB 7050 (VPN Server) <--> Internet (TAP Tunnel) <---> anderer Router <---> Laptop (VPN Client)

Das Laptop soll eben eine IP aus dem Subnet der FB 7050 bekommen. Vorerst reichts mir wenn sich nur ein client mit der Box verbinden kann. Wär aber nicht schlecht wenn die configs so geshrieben werden dass das acuh mit mehreren clients (die hinter verschiedenen routern hängen) geht.

Ich dachte beim bridging muss ich dem server nciht sagen dass er IPs vergeben soll. :confused: Siehe hier!
Klar, wenn ich die server-bridge Anweisung benutze sehe ich beim client auch dass er eine IP aus dem Subnet zugewiesen bekommen hat.
Aber der VPN Server sagt immer noch das:
Code:
Sun Mar 16 15:36:20 2008 us=386671 client1/111.111.111.111:61003 MULTI: Learn: 02:1b:77:c3:ba:3a -> client1/111.111.111.111:61003

(111.111.111.111 ist wieder die WAN Adresse der FB)
Beim "Bridging" wird das tap-Interface auf der einen Seite "mit dem auf der anderen verbunden". Damit "sehen" sich erstmal nur die beiden taps. Mit dem Eintrag in "brinterfaces" kann man dann das tap wieder mit dem LAN verbinden.

D.h. das wsa ich gemacht hab reicht? Weil viele machen dazu immer irgendwas mit dem brctl tool? :confused:

Wenn also eine IP-Verbindung sein soll, musst du das den Boxen sagen. Entweder "verteilt" die Serverbox die IPs (mit ifconfig und ifconfig-pool) oder die Clients bekommen eine fest eingetragen (mit ifconfig).

Wie gesagt: ich möchte keine 2 Boxen verbinden, sondern eine Box (mit dem ganzen LAN dahinter) mit einem einzelnen PC aus einem anderen Netzwerk. Ich hatte eigentlich gehofft, die Box würde die IP dann acuh per DHCP vergeben. Geht das ndenn nicht?

Das Portforwading so ist nur in sofern "schlechter", dass du es jetzt wohl nicht mehr ändern kannst, weil die Box sich beschwert, wenn ein Forwarding auf eine lokale IP existiert...

OKay verstehe, naja das mit dem beschweren macht sie bei mir auch, aber es geht trotzdem komischerweise :D
 
Mein Ziel ist es nicht 2 FB zu verbinden, ich möchte nur ...
... ja, wer lesen kann ...

Damit wird natürlich ein Teil von oben hinfällig, mit dem Windows-Client z.B. sollte das auch ohne IP-Vergabe durch das openvpn selbst klappen, der "kann" DHCP-Client sein.

Wenn dein "interfaces-Eintrag" (mit dem tap0) unter "brinterfaces {" steht, reicht das.

Die Meldung des VPN-Servers kannst du dann "ignorieren", denn dass er selbst keine IP für den Client vergibt ist ja gewollt, somit lernt er nur die "MAC-Adresse" des Clients. Dein Client sollte ganz normal eine IP von der Box bekommen, eventuell gibt es aber dann "Stress", da die Box per DHCP auch eventuell noch ein weiteres Defaultgateway und weitere DNS-Server verteilt...

Was sagt den ein "ipconfig" und "route print" auf dem Client, wenn du verbunden bist?


Jörg
 
Die Meldung des VPN-Servers kannst du dann "ignorieren", denn dass er selbst keine IP für den Client vergibt ist ja gewollt, somit lernt er nur die "MAC-Adresse" des Clients. Dein Client sollte ganz normal eine IP von der Box bekommen, eventuell gibt es aber dann "Stress", da die Box per DHCP auch eventuell noch ein weiteres Defaultgateway und weitere DNS-Server verteilt...

MMh sorry da hab ich jetzt nicht viel verstanden :oops: ich bin da afu deisem gebiet nicht ganz so fit wie du ;) Aber wie kann man denn das Prolbem lösen? Eigentlich müsste es doch gehen laut OpenVPN HowTo :confused:

ipconfig ergab das:
Code:
Windows-IP-Konfiguration


Ethernet-Adapter Netzwerkbrcke:

   Verbindungsspezifisches DNS-Suffix: 
   Verbindungslokale IPv6-Adresse  . : fe80::dd9c:453a:19fb:908d%23
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.105
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.0.1

Ethernet-Adapter Bluetooth-Netzwerkverbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: 

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:

Route print ergibt folgendes:

Code:
===========================================================================
Schnittstellenliste
 23 ...02 ff 8e 5b 5e 8e ...... MAC Bridge Miniport
 11 ...00 1c 26 f1 a2 53 ...... Bluetooth-Gerät (PAN)
  8 ...00 1c 23 8f 48 d1 ...... Broadcom 440x 10/100 Integrated Controller
  1 ........................... Software Loopback Interface 1
 21 ...00 00 00 00 00 00 00 e0  isatap.{9410049D-2919-435C-B059-DBABFF42E5BF}
 20 ...00 00 00 00 00 00 00 e0  isatap.{54B5FE8A-9FBC-43F3-8BB7-D298E0EC3F4E}
 24 ...00 00 00 00 00 00 00 e0  isatap.{59D914CB-4ED0-4CFF-A4AB-515EC342993B}
 17 ...00 00 00 00 00 00 00 e0  6TO4 Adapter
 18 ...00 00 00 00 00 00 00 e0  6TO4 Adapter
 19 ...00 00 00 00 00 00 00 e0  6TO4 Adapter
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.105     25
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.0.0    255.255.255.0   Auf Verbindung     192.168.0.105    281
    192.168.0.105  255.255.255.255   Auf Verbindung     192.168.0.105    281
    192.168.0.255  255.255.255.255   Auf Verbindung     192.168.0.105    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.0.105    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.0.105    281
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0          5.0.0.1  Standard [COLOR="Red"]<-- Route die wohl Hamachi eingetragen hat. Aber der Hamachi Adapter ist AUS![/COLOR]
          0.0.0.0          0.0.0.0     192.168.0.80  Standard 
          0.0.0.0          0.0.0.0      192.168.0.1  Standard 
===========================================================================

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  1    306 ::1/128                  Auf Verbindung
 23    281 fe80::/64                Auf Verbindung
 23    281 fe80::dd9c:453a:19fb:908d/128
                                    Auf Verbindung
  1    306 ff00::/8                 Auf Verbindung
 23    281 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
  Keine

Mmh wie gesag, ich weis nicht ob du damit so viel anfangen kannst... Ich befinde mich ja momentan mit dem Client im LAN der FB, verbinde mich zwar auf den dyndns alias, aber bin halt nicht wirklich außerhalb... VOn daher ist die oben zugewiesene IP 192.168.0.105 an die Netzwerkbrücke wohl eher die adresse die der Router der WLAN Verbindung (welche gebrückt ist zum TAP Device) per dhcp zuweist.

Außerdem kommen nach dem verbinden mehrere Fehler solcher art:
Code:
Mon Mar 17 17:08:10 2008 us=330100 client1/XXX.XXX.XXX.XXX:61002 Replay-window backtrack occurred [8]
 
O.k., wenn du das "von innen" versuchst, kann man kein "richtiges" Ergebnis verlangen, weil die Netze sich ja dann "überlappen" denn dein reales LAN enspricht dann dem virtuellen "VPN-LAN".

Der Adapter mit der .105 ist das VPN-Device? Dann klappt es mit dem DHCP.

Aber das Problem mit dem Standardgateway wird bleiben, denn eigentlich willst du ja "nur eine IP" bekommen, die Box übergibt dir aber auch ein Standardgateway mit der Folge, dass du nun mindestens zwei hast, was dazu führen wird, dass eine Schleife entsteht:
Um ein Paket zum VPN-Server zu schicken, nimmt dein Client aus der Routingtabelle ein Standardgateway. Ist das die IP der Fritzbox, so will er das Paket "durch das VPN" schicken, also zum VPN-Server und sucht dazu das Standardgateway in der Routingtabelle usw. .....

http://openvpn.net/index.php/documentation/install.html?start=1 schrieb:
Notes -- Setting TAP-Win32 address/subnet automatically via DHCP

Setting the TAP-Win32 address/subnet automatically via DHCP is a convenient method of managing IP addresses in a bridge situation, though there are some caveats that must be handled.

The problem with getting addresses for VPN clients via DHCP is that you only want to get the IP address and subnet mask, not the gateway. Therefore in a bridge situation, a DHCP server must be able to differentiate between local clients and remote VPN clients.

Da deine Fritz-Box das nicht kann, solltest du überlegen, vielleicht doch die IP im Client vorzugeben (halt außerhalb des DHCP-Bereiches der Box) oder doch die IPs vom VPN vergeben lassen...


Das "Replay-window backtrack occurred" kommt, wenn die Pakete nicht in der erwarteten Reihenfolge beim Server ankommen (siehe z.B. hier gut beschrieben). Das könnte mit der beschriebenen Problematik zusammenhängen, dass dein Standardgateway direkt und "durch den Tunnel" erreichbar ist.

Jörg
 
O.k., wenn du das "von innen" versuchst, kann man kein "richtiges" Ergebnis verlangen, weil die Netze sich ja dann "überlappen" denn dein reales LAN enspricht dann dem virtuellen "VPN-LAN".

Der Adapter mit der .105 ist das VPN-Device? Dann klappt es mit dem DHCP.

Okay das dacht ich mir dass das von "innen" wohl Probleme macht... aber egal dann teste ich das mal so schnell wie möglcih von wo anders.

Zur IP: Ich weis nicht ob da bedeutet, dass es klappt. das Device mit der .105 ist die Netzwerkbrücke die man ja bei windows zwischen TAP und eben der LAN/WLAN verbdinung einrichten muss. aber auch ohne verbdinung zum VPN server steht hier als IP .105 weil logischerweise der WLAN Adapter von "innen" sowieso von der FB die IP zugewiesen bekommt

Aber das Problem mit dem Standardgateway wird bleiben, denn eigentlich willst du ja "nur eine IP" bekommen, die Box übergibt dir aber auch ein Standardgateway mit der Folge, dass du nun mindestens zwei hast, was dazu führen wird, dass eine Schleife entsteht:
Um ein Paket zum VPN-Server zu schicken, nimmt dein Client aus der Routingtabelle ein Standardgateway. Ist das die IP der Fritzbox, so will er das Paket "durch das VPN" schicken, also zum VPN-Server und sucht dazu das Standardgateway in der Routingtabelle usw. .....

Okay... das Prolbemkonnte ich jetzt halbwegs nachvollziehen ;) Was kann man dagegen machen? Oder wird das automatisch funktionieren wenn ich es mal von "außen" versuche?

Ach und BTW: Danke schonmal für deine Hilfe bis jetzt!:)

EDIT: Zum Vorschlag, dass ich dem Client einfach eine IP zuweise: Also einfach ein ifconfig in die cfg würds tun oder?
 
Ja, das einfachste ist, du überlegst dir einen eigenen Bereich für die Clients, der in deinem Netz frei ist und nicht von der Box vergeben wird.
Wäre das z.B. 192.168.0.90 bis 192.168.0.99, dann vergibst du die "fest" in der Clientconfig mit einem "ifconfig 192.168.0.90 255.255.255.0" für die erste IP, in einer weiteren dann die 192.168.0.91 usw.

Damit ist dein Client über das VPN im Netz mit den anderen 192.168.0.x-er Geräten, benutzt aber ansonsten "ganz normal" das Standardgateway in seinem "regulären" Netz.

Zum Zuweisen könntest du mal ein "ipconfig /all" machen, da sollte dann (wenn es mit dem DHCP geklappt hat) dem VPN-Adapter (bei mir unter XP: "TAP-Win32 Adapter V9") eine IP zugewiesen sein. Ansonsten sieht man das beim Clientaufbau, wenn man die Config startet mit Rechtsclick auf die .ovpn-Datei und dann "start openvpn on this config file". Dann sieht man im Fenster den Aufbau der Verbindung und darin auch ob und welche IP vergeben wurde.

Jörg
 
okay alles klar... habs eben getestet und es ging anscheind wirklich... zumindest konnte ich die IP der VPN verbindung von jedem anderen rechner hinter der FB anpingen und umgekehrt auch.

Nochmal 2 Fragen:
Muss ich jetzt beim Windows client eigentlich eine netzwerkbrücke zwischen LAN adpater und VPN verbindung mcahen oder nicht? laut openVPN howto muss man da aber es ging eben auch ohne ... :confused:

außerdem: beim verbinden grad eben (mit ifconfig beim client) bekam ich ne fehlermeldung/warnung dass in der cfg vom server ein "ifconfig 192.168.0.0 255.255.255.0" sein muss, wenn der client ein ifconfig benutzt... ganz banale frage: muss das wirklcih rein? wieso? ^^
 
Nein, du brauchst da keine Brücke; der Client soll ja "allein" in das Netz des Servers (die bräuchtest du, wenn der Client auch wieder ein ganzes Netz mit mehreren Rechnern "bedienen" sollte, also wenn du z.B. per Box2Box komplett zwei Netze verbinden wolltest...)

Die Warnung kannst du hier ignorieren, denn der Server "weiß" ja über die IP schon Bescheid. Du könntest theoretisch diese Konstellation auch verwenden, wenn dein LAN z.B. den "Fritzboxstandard" 192.168.178.x nutzen würde. Dann müsstest du dem Server mitteilen, dass das IP-Netz 192.168.0.x "am VPN hängt". Da deine Box das Netz aber "kennt" und das bekannte Netz mit dem VPN gebrückt ist, brauchst du das hier nicht (Ergänzung: normalerweise hat der VPN-Adapter eine IP, das ist gemeint, aber hier benötigt er die nicht zwingend, denn er "erbt" die durch die Brücke vom LAN).

Jörg
 
Zuletzt bearbeitet:
Nein, du brauchst da keine Brücke; der Client soll ja "allein" in das Netz des Servers (die bräuchtest du, wenn der Client auch wieder ein ganzes Netz mit mehreren Rechnern "bedienen" sollte, also wenn du z.B. per Box2Box komplett zwei Netze verbinden wolltest...)

okay alles klaro :)

Die Warnung kannst du hier ignorieren, denn der Server "weiß" ja über die IP schon Bescheid. Du könntest theoretisch diese Konstellation auch verwenden, wenn dein LAN z.B. den "Fritzboxstandard" 192.168.178.x nutzen würde. Dann müsstest du dem Server mitteilen, dass das IP-Netz 192.168.0.x "am VPN hängt". Da deine Box das Netz aber "kennt" und das bekannte Netz mit dem VPN gebrückt ist, brauchst du das hier nicht (Ergänzung: normalerweise hat der VPN-Adapter eine IP, das ist gemeint, aber hier benötigt er die nicht zwingend, denn er "erbt" die durch die Brücke vom LAN).

ok, und wieder alles klar :) dann werd ich das mal demnächst von außen versuchen und hoffen dass es geht. wenn nciht melde ich mich nochmal hier!

danke dir für deine nette hilfe :groesste:
 
meine config sieht jetzt so aus:

Code:
proto tcp-client
dev tun
secret D:\\Programme\\OpenVPN\\sample-config\\key
remote meine.ip.de 1143
nobind
#push redirect-gateway
ifconfig 172.30.1.202 172.30.1.201
route 172.30.1.0 255.255.255.0
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
#comp-lzo
keepalive 10 120
resolv-retry infinite

mit dieser komme ich auch auf die Box, nämlich einmal über die 172.30.1.201 und über die 172.30.1.1 (also der Standdard-IP). Jedoch nahm ich an, über den route-Eintrag auch auf die 172.30.1.222 (selbes Subnetz wie die 172.30.1.1) zugreifen zu können. Was jedoch nicht klappt. Ich bin da zur Zeit in wenig ratlos ...
Was auch nicht geht ist folgende route anzulegen: route 172.30.1.222 255.255.255.0 ; da meckert dann openvpn rum.
 
@xsapling: Benutz doch einfach TAP devices, dann musst du nichts routen! Außerdem funktionieren dann auch Netzwerk Broadcasts und jede Software die über das Tunnel kommunizerien soll kommt damit auch klar.

Falls du bei TUN bleiben willst: Soweit ich weis sollten dich die IPs der virtuellen TUN Adapter nciht im selben Netz liegen wie das des Servers. Dann sollte es auch mit dem routing klappen

@MaxMuster: So ich hab das ganze eben mal von außerhalb ausprobiert (mit nem Handy als Modem) und es hat perfekt geklappt! Pings in alle Richtungen funktionieren. Die Netzwerkumgebung macht keine mucken... Perfekt :) Danke nochmal!
 
Falls du bei TUN bleiben willst: Soweit ich weis sollten dich die IPs der virtuellen TUN Adapter nciht im selben Netz liegen wie das des Servers. Dann sollte es auch mit dem routing klappen

ich glaube, dass dies auch nicht der Fall ist, oder?.

Server:

Code:
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.30.1.201  P-t-P:172.30.1.202  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1932 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2104 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:220604 (215.4 KiB)  TX bytes:1036740 (1012.4 KiB)

Client:

Code:
        Verbindungsspezifisches DNS-Suffix:
        IP-Adresse. . . . . . . . . . . . : 172.30.1.202
        Subnetzmaske. . . . . . . . . . . : 255.255.255.252
        Standardgateway . . . . . . . . . :
 
Ah okay sorry :oops:

Naja es gibt diese client-to-client directive die man in der server config eifnügen kann. Dadurch können sich clients die am VPN server hängen untereinander sehen.
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.

Probiers mal aus... soweit ich weis muss dann noch "mode server" in die config rein oder sowas. OpenVPN wird aber schon meckern falls was nicht stimmen sollte.
 
...
mit dieser komme ich auch auf die Box, nämlich einmal über die 172.30.1.201 und über die 172.30.1.1 (also der Standdard-IP). Jedoch nahm ich an, über den route-Eintrag auch auf die 172.30.1.222 (selbes Subnetz wie die 172.30.1.1) zugreifen zu können....
Also daraus läse ich auch, dass das Tunnelnetz mit dem "normalen" Netz überlappend ist (es ist schwer ein Netz zu haben, in dem sowohl 172.30.1.1 als auch 172.30.1.222 sind, aber nicht 172.30.1.201 und 172.30.1.202 ;-) [es sei denn ein Point-to-Point Netz, in dem nur 172.30.1.1 und 172.30.1.222 sind] )

Wenn der Tunnel IP-Bereich mit dem normalen IPs überlappt, so ist das schlecht, du müsstest dann wirklich besser TAP nutzen (das Problem ist bei dir, dass der "Hinweg" mit deiner Route klappt, der Client also Pakete zu 172.30.1.222 schicken kann, für den Rückweg wird der PC 172.30.1.222 aber davon ausgehen, dass 172.30.1.202 im gleichen Netz, also im LAN, ist und deshalb nicht über die Fritzbox gehen [du kannst das mal testen, indem du auf 172.30.1.222 eine Hostroute zu 172.30.1.202 über 172.30.1.201 einrichtest; unter Windows "route add 172.30.1.202 172.30.1.1"]).

Poste doch mal ein "ifconfig" und "route" von der Box und ein "ipconfig" und "route print" vom Client und dem "anderen PC"...


Jörg
 
Zuletzt bearbeitet:
Also daraus läse ich auch, dass das Tunnelnetz mit dem "normalen" Netz überlappend ist (es ist schwer ein Netz zu haben, in dem sowohl 172.30.1.1 als auch 172.30.1.222 sind, aber nicht 172.30.1.201 und 172.30.1.202 ;-) [es sei denn ein Point-to-Point Netz, in dem nur 172.30.1.1 und 172.30.1.222 sind] )

Diese Feststellung könnte richtig sein, wenn für die Bejahung der Frage, ob ein überlappendes Netz vorliegt, es auf die letzte Stelle der Subnetzmaske nicht ankäme.
Darüberhinaus wäre die 172.30.1.201 der "Endpunkt" des Tunnelnetztes.


Wenn der Tunnel IP-Bereich mit dem normalen IPs überlappt, so ist das schlecht, du müsstest dann wirklich besser TAP nutzen (das Problem ist bei dir, dass der "Hinweg" mit deiner Route klappt, der Client also Pakete zu 172.30.1.222 schicken kann, für den Rückweg wird der PC 172.30.1.222 aber davon ausgehen, dass 172.30.1.202 im gleichen Netz, also im LAN, ist und deshalb nicht über die Fritzbox gehen [du kannst das mal testen, indem du auf 172.30.1.222 eine Hostroute zu 172.30.1.202 über 172.30.1.201 einrichtest; unter Windows "route add 172.30.1.202 172.30.1.1"]).

ein solches add hat bei mir auf dem ersten Anschein nichts erbracht.

Insofern habe ich Deinem Tipp folgend, das openvpn auf "TAP" umgestellt und nun kann ich mit der Verbindung das machen was ich von Anfang an vor hatte. So kann ich insbesondere mit den hinter der "Zielbox"/"Serverbox" liegenden Geräte so umgehen, als wäre ich direkt im Netzwerk.

Aber ich beobachte derzeit noch, ob ich ein Problem mit "Wins" haben könnte, hinsichtlich der fehlen Auflösung eines/einiger Namen im Netztwerk.
 
Diese Feststellung könnte richtig sein, wenn für die Bejahung der Frage, ob ein überlappendes Netz vorliegt, es auf die letzte Stelle der Subnetzmaske nicht ankäme.
Wie waren die denn bei dir?
Damit .1 und .222 in einem Netz sind, musst du mindestens eine Class C Maske (255.255.255.0) haben, was auch .201 und .202 umfasst (oder eben Point-to-Point).
Das "tut dem Client nicht weh", denn der kennt in der Tat nur das kleine Netz mit 201 und 202 mit der Maske 255.255.255.252. Aber der PC im Netz der Fritzbox käme damit nicht klar, der würde die IP lokal erwarten...

Jörg
 
Hallo,

Und dann fällt mir noch eine Frage ein: Unter welcher IP ist der Client dann im Netzwerk zu erreichen? Wenn cih mich verbinde gibt der Server folgendes aus:
Code:
Sun Mar 16 15:36:09 2008 us=160360 111.111.111.111:61003 [client1] Peer Connection Initiated with 111.111.111.111:61003
Sun Mar 16 15:36:09 2008 us=161968 client1/111.111.111.111.168:61003 MULTI: no dynamic or static remote --ifconfig address is available for client1/111.111.111.111:61003
Sun Mar 16 15:36:10 2008 us=212330 client1/111.111.111.111:61003 PUSH: Receivedcontrol message: 'PUSH_REQUEST'
Sun Mar 16 15:36:10 2008 us=213906 client1/111.111.111.111:61003 SENT CONTROL [client1]: 'PUSH_REPLY,ping 20,ping-restart 180' (status=1)
Sun Mar 16 15:36:11 2008 us=431712 client1/111.111.111.111:61003 MULTI: Learn: 00:ff:8e:5b:5e:8e -> client1/111.111.111.111:61003
Sun Mar 16 15:36:20 2008 us=386671 client1/111.111.111.111:61003 MULTI: Learn: 02:1b:77:c3:ba:3a -> client1/111.111.111.111:61003
111.111.111.111 ist die WAN Adresse des Box. Wieso bekommt der client keien IP aus dem Subnet der FB zugewiesen? Und wieso läuft da was auf port 61003? Sieht für mcih irgendwie bisschen komisch aus :(

Wenn mehrere Clients mit einem IP-Server kommunizieren sollen, geht das natürlich nicht für alle über den gleichen serverseitigen Port. Deshalb wird nach erfolgreicher Verbindungsaufnahme über den bekannten Port (1194 in Deinem Fall) erstmal die Kommunikation auf andere, nicht reservierte Portnummern verlegt. Zuerst teilt der Server dem Client mit, auf welcher Portnummer es seinerseits weitergeht und dann sofort auch der Client dem Server (Port 61003 in Deinem Fall). Den serverseitigen Port siehst Du im OpenVPN-Log des Clients nach. So wird der Port 1194 schnell für den nächsten Client zur Kontaktaufnahme frei.

Das erledigt übrigens das Betriebssystem bzw. dessen IP-Protokollstack, die Anwendung braucht sich darum nicht zu kümmern.

Mit freundlichen Grüßen
LPW
 
Kostenlos!

Statistik des Forums

Themen
248,923
Beiträge
2,305,224
Mitglieder
378,647
Neuestes Mitglied
nightdeck