OpenVPN im TAP Modus

thuebner

Neuer User
Mitglied seit
7 Jan 2005
Beiträge
167
Punkte für Reaktionen
0
Punkte
0
Hallo,

Ich habe ein Problem mit OpenVPN im TAP Modus auf der 7050. Ein ganzes WE habe ich gebraucht um OpenVPN auf meiner 7050 zum laufen zu bringen, aber noch nicht ganz richtig:

Ich verwende das WebUI vom ds-mod und die Binaries lade ich mit dem Downloader nach. OpenVPN startet einwandfrei und läuft auch im TUN Modus, aber ich möchte OpenVPN mit TAP laufen lassen, da meine Client eine IP aus dem lokalen Adressbereich (192.168.178.0) bekommen soll (damit ich auf Windows-Freigaben zugreifen kann).

Wenn ich im WebUI ein zusätzliches Subnetz angeben, kann ich beide den anderen Endpunkt des Tunnels anpingen, aber ich bin nicht im gleichen Netz.
Code:
/var/mod/etc $ cat openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
ifconfig-pool [color=red]192.168.200.200 192.168.200.251[/color]
ifconfig [color=red]192.168.200.99[/color] 255.255.255.0
push "route-gateway 192.168.200.99"
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
comp-lzo
keepalive 10 120

Wenn ich der Box eine zusätzliche IP aus dem LAN-Netz gebe, kann ich das andere Ende des Tunnels nicht einmal anpingen:
Code:
/var/mod/etc $ cat openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
ifconfig-pool [color=red]192.168.178.200 192.168.178.251[/color]
ifconfig [color=red]192.168.178.99[/color] 255.255.255.0
push "route-gateway 192.168.178.99"
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
comp-lzo
keepalive 10 120

Hat das ganze was mit den Routing zu tun? Leider kenne ich mich da nicht so gut aus und habe auch kein Beitrag gefunden, der als Lösung dienen könnte.

Andere Frage dazu (habe ich auch in einen Beitrag hier gelesen, das es gehen soll): Kann man den Endpunkt auf der FB nicht die eigene IP verpassen (also 192.168.178.1)? Bzw. kann man nicht den eigenen DHCP Server zur IP-Vergabe der Clients verwenden?
 
Dein Problem dürfte sein, dass die Box so nicht weiß, "wohin" sie denn nun mit den Paketen soll, denn nun gibt es zwei Interfaces mit dem gleichen Netz.
Du solltest für den TAP-Modus, so wie du ihn nutzen willst, das TAP mit dem "normalen" Netz "brücken". Meine Empfehlung: In der ar7.cfg das interface "tap0" zu den schon vorhandenen brinterfaces hinzufügen
Code:
...
brinterfaces {
...

Andere Frage dazu (habe ich auch in einen Beitrag hier gelesen, das es gehen soll): Kann man den Endpunkt auf der FB nicht die eigene IP verpassen (also 192.168.178.1)? Bzw. kann man nicht den eigenen DHCP Server zur IP-Vergabe der Clients verwenden?

Wenn du wie oben angegeben den TAP-Adapter mit dem LAN brückst: Ja, sowohl das erste sollte gehen (die 192.168.178.1) und bei einem Windows-Client würde wohl auch das DHCP funktionieren, wenn auf dem virtuellen Interface "IP automatisch beziehen" eingetragen ist. Dann könntest du dir den Pool sparen.

Jörg
 
Hallo Jörg,

Das mit der ar7.cfg habe ich auch schon gelesen, aber mit ifconfig auf der Box wird das Interface "LAN" nicht angezeigt, deshalb habe ich angenommen, das funktioniert nicht. Und wass muss ich dan in der server.conf eintragen?
Code:
ifconfig 192.168.178.1 255.255.255.0
Und die Zeile "ifconfig-pool" weglassen bzw. nichts im WebUI beim Pool eintragen?
 
Das mit der ar7.cfg habe ich auch schon gelesen, aber mit ifconfig auf der Box wird das Interface "LAN" nicht angezeigt,
Hast du eventuell "WLAN" und "LAN" in unterschiedlichen Netzen? Dann müsstest du eventuell mit dem Tool "brctl" (z.B. von hier) arbeiten und (sofern es kein Interface lan gibt bei "ifconfig -a") das wie folgt anlegen und die Interfaces hinzufügen

Code:
brctl addbr lan
brctl addif lan eth0
brctl addif lan tap0

Der Pool könnte dann leer sein und in die server.conf sollte wie geschrieben (obwohl ich persönlich meinem TAP immer eine eigene IP gönne)
Code:
ifconfig 192.168.178.1 255.255.255.0

Jörg
 
Bei den Anschlüssen auf der FritzNox (LAN A, LAN B, WLAN, USB) habe ich zur Zeit getrennte Netzte, damit ich OpenVPN ausprobieren kann. Wenn alles klappt, werde ich es wieder zusammemschließen.

Leider klappt es immer noch nicht. Ich habe die Brücke erstellt:
Code:
/var/mod/bin $ brctl show
bridge name     bridge id               STP enabled     interfaces
wlan            8000.00040e62163b       no              tiwlan0
                                                        wdsup0
                                                        wdsdw0
                                                        wdsdw1
                                                        wdsdw2
                                                        wdsdw3
lan             8000.beee131c3c9d       no              eth0
                                                        tap0



Meine Server Config seht jetzt so aus:
Code:
/var/mod/bin $ cat /mod/etc/openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
ifconfig-pool 192.168.178.200 192.168.178.251
ifconfig 192.168.178.99 255.255.255.0
push "route-gateway 192.168.178.99"
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
comp-lzo
keepalive 10 120
Ein "route" auf der Box ergibt:
Code:
/var/mod/bin $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
192.168.178.0   *               255.255.255.0   U     0      0        0 tap0
192.168.182.0   *               255.255.255.0   U     0      0        0 wlan
192.168.181.0   *               255.255.255.0   U     0      0        0 eth1
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         *               0.0.0.0         U     2      0        0 dsl

Die Verbindung vom Client klappt zwar, aber ein Ping an das jeweilige Ende des Tunnels geht immer noch nicht, "route" auf dem Client bring folgendes:
Code:
thnblin:/etc/openvpn # route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   192.168.178.99  255.255.255.0   UG    0      0        0 tap0
192.168.178.0   *               255.255.255.0   U     0      0        0 tap0
192.168.181.0   *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.178.99  0.0.0.0         UG    0      0        0 tap0
 
Hi,

um das einzugrenzen mach doch mal (am besten, wenn du per WLAN verbunden bist) ein
Code:
ifconfig eth0 0.0.0.0 && ifconfig lan 192.168.178.1

Aus der Konfiguration kann eigentlich das raus (wenn das Client-Interface eine IP aus dem Netz 192.168.178.0 hat, braucht es keine Route dahin):
Code:
push "route 192.168.178.0 255.255.255.0"

Jörg
 
ich bin per LAN B verbunden (also auch ein separates Subnet. Wenn ich
Code:
ifconfig eth0 0.0.0.0 && ifconfig lan 192.168.178.1
kommt keine Ausgabe. Hat nur zur Folge, dass die Rechner am LAN A (eth0) nicht mehr gehen.
 
Hi,

da scheint das Bridging nicht so zu funktionieren, wie gedacht. Was mir gerade einfällt: Mach doch bitte lieber (weil das ifconfig das "lan" garnicht anzeigt ist es vielleicht nach dem erstellen noch down)

Code:
ifconfig eth0 0.0.0.0 && ifconfig lan 192.168.178.1 && ifconfig lan up


Wie sieht denn danach ein "ifconfig", evtl. "ifconfig -a" und "route" aus? Kannst du dann von der Box mal ein Ping in das 178-er LAN versuchen?

Ansonsten sähe ich noch die Möglichkeit, die Brücke (falls das geht) "ins WLAN zu verlegen", also das TAP der schon vorhandenen WLAN Bridge hinzuzufügen...

Jörg
 
Nachdem ich das Interface lan gestartet habe, sehe ich es
Code:
lan       Link encap:Ethernet  HWaddr F6:8B:38:C0:1A:C8
          inet addr:192.168.178.1  Bcast:192.168.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:231 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17581 (17.1 KiB)  TX bytes:246 (246.0 B)
Die Route sieht jetzt so aus:
Code:
/var/mod/bin $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.178.0   *               255.255.255.0   U     0      0        0 tap0
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.182.0   *               255.255.255.0   U     0      0        0 wlan
192.168.181.0   *               255.255.255.0   U     0      0        0 eth1
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         *               0.0.0.0         U     2      0        0 dsl
Ein Ping in das 178er Netz geht immer noch nicht. Nur auf die jeweiligen eigenen IPs. Und mein anderer PC am eth0 der Box ist nicht mehr erreichbar und kann auch nichts ins Internet.

Die Brücke ins WLAN zu machen, möchte ich eigentlich nicht, weil mein PC am eth0 (LAN A) hängt und ich darauf Zugriff (von außen) haben möchte.

Gruß Thomas
 
Könntest du dann auf der Box mal ein "arp -a" machen, ob der PC an eth0 sichtbar ist und das auch auf "lan"?!?

Wichtig wäre auch, den ersten Ping von der Box zu starten, damit die Änderung der MAC-Adresse (lan-MAC statt eth0-MAC) beim PC ankommt.

EDIT: Am besten, du fügst noch folgendes mit ein:

Code:
ifconfig eth0 0.0.0.0 && ifconfig lan 192.168.178.1 && ifconfig lan down && ifconfig lan hw ether <MAC-Adresse von eth0> && ifconfig lan up



Jörg
 
Zuletzt bearbeitet:
Mein Laptop und mein PC sind sichbar:
Code:
? (192.168.181.20) at xx:xx:xx:xx:xx:xx [ether] on eth1
rio2007 (192.168.178.26) at xx:xx:xx:xx:xx:xx [ether] on eth0

Sobald ich eth0 zur Brücke mit aufnahme ist der PC zwar noch sichbar, aber von der Box aus nicht mehr anpingbar.

Edit: Jetzt ist der PC mit arp -a nicht mehr sichbar (hat eine Weile gedauert).
Edit: Jetzt habe ich die Box nochmal neu gestartet und die komplette Zeile eingegeben:
Code:
/var/mod/sbin $ arp -a
? (192.168.181.20) at xx:xx:xx:xx:xx:xx [ether] on eth1
? (192.168.178.200) at <incomplete> on tap0

Gruß Thomas
 
Zuletzt bearbeitet:
Jetzt gibt mir arp-a folgendes aus:
Code:
/var/mod/sbin $ arp -a
? (192.168.181.20) at xx:xx:xx:xx:xx:xx [ether] on eth1
? (192.168.178.200) at <incomplete> on tap0
rio2007 (192.168.178.26) at <incomplete> on tap0
Und eine Weile später, als ich den OpenVPN CLient beendet habe:
Code:
? (192.168.181.20) at xx:xx:xx:xx:xx:xx [ether] on eth1
rio2007 (192.168.178.26) at xx:xx:xx:xx:xx:xx [ether] on lan
? (192.168.178.200) at <incomplete> on tap0
rio2007 (192.168.178.26) at <incomplete> on tap0
Aber ein ping auf 192.168.178.26 ist von der Box nicht möglich.
 
Ist natürlich alles etwas schwierig, so per Ferndiagnose...

Also zunächst sollte die Brücke und das LAN funktionieren, ehe das VPN dazukommt. Haben denn bei einem ifconfig lan und eth0 die selbe MAC-Adresse? So sieht das zumindest mit dem "lan"-Interface aus, was die Box selbst anlegt.
Dann sollte, wenn die IP auf dem lan eingetragen ist, auch die arp-Auflösung bei "lan" erscheinen, so wie in deinem untersten Beispiel oben.

Also, ich würde im ersten Schritt folgendes vorschlagen:

  • tap0 erstmal "stillegen" mit ifconfig tap0 down
  • wir oben dem eth0 die IP wegnehmen und lan geben, dabei sollte lan die gleiche MAC-Adresse haben, wie eth0

In dieser Konstellation müsste erstmal die Funktionalität auf dem eth0 hergstellt werden. WEnn es so nicht klappt wäre auch interessant, was ein "arp -a" auf dem PC über die IP der Box sagt (evtl. vorher mit "arp -d * " alle Einträge löschen).

Jörg

EDIT: So, ich habe das mal auf meiner "alten" FBF WLAN versucht, wenn auch nur mit Kernel 2.4. Ich vermute, dass du noch ein "eth0:0" oder "eth0:1" mit der "Fallback-IP" 192.168.178.254 hast.
Dann sollte das in etwa so funktionieren, auch diese IP auf das Brückeninterface "umzuziehen":

Code:
ifconfig eth0:0 0.0.0.0 && ifconfig lan:0 192.168.178.254

Bei mir konnte ich danach "normal" im LAN arbeiten
 
Zuletzt bearbeitet:
ENDLICH
Jetzt habe ich nochmal frisch die Box gestartet und alles ganz langsam gemacht:

Code:
/var/mod/sbin $ ./brctl addbr lan
/var/mod/sbin $ ./brctl addif lan eth0
/var/mod/sbin $ ifconfig eth0 0.0.0.0 && ifconfig lan 192.168.178.1 && ifconfig lan down && ifconfig lan hw ether <MAC-Adresse von eth0> && ifconfig lan up
Zusätzlich noch:
Code:
/var/mod/sbin $ ifconfig tap0 down
/var/mod/sbin $ arp -a
? (192.168.178.22) at <incomplete> on eth0
? (192.168.181.20) at xx:xx:xx:xx:xx:xx [ether] on eth1
? (192.168.178.22) at xx:xx:xx:xx:xx:xx [ether] on lan
Dann habe ich tap0 gestartet und zur Bridge hinzugefügt und OpenVPN gestartet:
Code:
/var/mod/sbin $ ifconfig tap0 up
/var/mod/sbin $ ./brctl addif lan tap0
Und schon klappte der Ping durch den Tunnel. Und als ich meinen PC in Windxxx gestartet habe, konte ich auf die Freigane zugreifen.

Danke nochmals für Deine Hilfe.

Jetzt ist nur noch die Frage, wie man das ganze automatisieren kann, dass es beim Starten der Box gleich eingerichtet ist.

Gruß Thomas
 
Also das kannst du entweder per "debug.cfg" oder über ein "Skript vor den Openvpn" erreichen. Nehmen wir mal an, dieses Skript hieße "/var/tmp/flash/startbridge" , wäre mit "chmod +x /var/tmp/flash/startbridge" ausführbar gemacht und mittels "modsave" gesichert ;-):

Code:
#! /bin/sh
# vorher brctl z.B. mittels downlader nach /var/tmp oder
# ein wget hier einfügen 

# Schon mal gelaufen, also hat lan schon eine IP? Dann exit
tmp=`ifconfig lan | grep "inet addr:"`
if [ -n "$tmp" ]; then exit 1 ; fi

mac=`ifconfig eth0 | grep HWaddr`
mac=${mac##*HWaddr }
ip=`ifconfig eth0 | grep "inet addr"` 
ip=${ip%% Bcast*}
ip=${ip##*addr:}

/var/tmp/brctl addbr lan
/var/tmp/brctl addif lan eth0
ifconfig eth0 0.0.0.0
ifconfig lan down
ifconfig lan hw ether $mac 
ifconfig lan up
ifconfig lan $ip 

ifconfig tap0 down
ifconfig tap0 up
/var/tmp/brctl addif lan tap0

Wenn das Skript bei dir richtig läuft, dann könntes du das versuchen am Ende der "debug.cfg" aufzurufen. Alternativ (aber etvas aufwendiger) auch "vor" dem Start des Openvpn, dann müsstest du aber die VPN-Dateien anpassen (müsstest du nach suchen, oder später hab ich vielleicht noch etwas Zeit, das zu beschreiben).

Jörg
 
Zuletzt bearbeitet:
Das Script hat funktioniert, außer dass es einen kleinen Fehler hat:
Code:
mac=`ifconfig eth0 | grep HWaddr`
mac=${mac##*HWaddr }
ip=`ifconfig [color=red][b]eth0[/b][/color] | grep "inet addr"` 
ip=${ip%% Bcast*}
ip=${ip##*addr:}

Aber beim Aufruf aus der debug.cfg wurde die Bridge nicht angelegt. Kann es sein, dass die debug.cfg vor dem Downloader abgearbeit wird. Habe mir nämlich damit brctl runter geladen.

Nachdem ich die Netzte wieder zusammengeführt habe, brauche ich diesen ganzen Aufwand mit der Bridge nicht, Jetzt hat der Eintrag inh der ar7.cfg gereicht. Gut, ich werde das ganze am Freitag mal von außen testen.

Jörg, danke nochmal für Deine Hilfe.

Gruß Thomas
 
Oops, Fehler habe ich oben korrigiert.

Ja, dass das Downloaden dann noch nicht erledigt ist, kann sein.
Auch wenn es jetzt nicht nötig ist:

Du könntest ein "Custom-Skript" für das Openvpn anlegen, was das vor dem Start erledigt. Das Start-Skript in /etc/init.d/ schaut zunächst nach, ob ein Config-Skript in /var/tmp/flash liegt, ehe es das Standard-Skript nutzt. Daher wäre eine "Billigvariante" diese Skript dort als /var/tmp/flash/openvnn-lzo_conf anzulegen (und auch ausfürhbar machen und mit modsave speichern:

Code:
# Das Startbridge-Skript aufrufen
# Da die Ausgabe das Config-Skript erzeugt, vorsichtshalber alles "wegwerfen"
/var/tmp/flash/startbridge > /dev/null
# .. und dann ganz normal das "originale" Skript starten
/mod/etc/default.openvpn-lzo/openvpn-lzo_conf


Jörg
 
Zuletzt bearbeitet:
startbridge schlägt fehlt, da tap0 noch nicht existiert

Hallo,

ich möchte auf einer Box mit 29.04.57-freetz-1.0 OpenVPN im Bridging-Modus verwenden und MaxMuster hat mit dem Skript startbridge und dessen automatischen Aufruf in der /var/tmp/flash/openvpn_conf genau die richtigen Zutaten geliefert :)

Ich beobachte jedoch das Problem, dass das Device tap0 nur dann vorhanden ist, wenn OpenVPN bereits läuft. Die Bridge wird mit dem Skript jedoch vor dem Start von OpenVPN angelegt. tap0 wird nicht gefunden und daher auch nicht in die Bridge aufgenommen:

Code:
/var/mod/root # brctl show
bridge name     bridge id               STP enabled     interfaces
wlan            8000.00150c7a3727       no
lan             8000.00150c7a3727       no              eth0
/var/mod/root #

Vermutlich muss tap0 irgendwie dauerhaft angelegt werden. Aber wie?

Grüsse,
DSLFritze
 
Hi,

Das aktuelle OpenVPN-Skript prüft, ob du eine TAP-Config und ein "brctl" hast. Wenn ja, fügt es alle tap-Interfaces zur Bridge "lan" hinzu (sollte es zumindest, allerdings wird damit hier ein Problem beschrieben, ist also vielliecht noch buggy).

Ansonsten kannst du das tap ja auch später noch ninzufügen:
Code:
# Das Startbridge-Skript aufrufen
# Da die Ausgabe das Config-Skript erzeugt, vorsichtshalber alles "wegwerfen"
/var/tmp/flash/startbridge > /dev/null
# .. und dann ganz normal das "originale" Skript starten
/mod/etc/default.openvpn-lzo/openvpn-lzo_conf
[B]# vorsichtshalber 1 Sekunde warten, damit das Interface auch da ist
sleep 1
/var/tmp/brctl addif lan tap0[/B]
z.B. sollte reichen, um das tap-Interface nach dem Starten in die Brücke aufzunehmen...


Jörg
 

Statistik des Forums

Themen
244,808
Beiträge
2,218,758
Mitglieder
371,494
Neuestes Mitglied
msh7
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.