OpenVPN-Server über br0 ins Netzwerk routen klappt nicht
Hallo Leute,
ich verzweifele hier gerade an einem vermutlich trivialen Problem. Meine Linux Kenntnisse sind leider nicht sehr ausgeprägt was Netzwerkrouting angeht...
Um das Problem zu veranschaulichen haben ich ein kleines Diagramm gezeichnet.
Ich habe zwei Netzwerke die ich gerne über einen VPN Tunnel verbinden will. Die Brücker soll Layer 2 sein, so dass Broadcasts (DHCP) oder pings mitgeroutet werden. Der OpenVPN Client von der Außenstelle baut die Verbindung auf.
Für den OpenVPN-Server habe ich eine HyperV-VM einen (aktuellen) Ubuntu Server aufgesetzt OpenVPN installiert und konfiguriert.
Hier die OpenVPN Configuration server.conf
Der Router auf der Aussenstelle kann sich mit dem OpenVPN-Server verbinden, und im Server kann ich die einzelnen Netzwerkendgeräte anpingen. Sie antworten mir.
Nur von anderen Rechner aus dem "linken Netzwerk" (z.B. Rechner .100) wird der Drucker .61 nicht gefunden: "Zielhost nicht erreichbar"
Die VM openvpn-server ist aus jedem Punkt aus dem Büro eins erreicht werden.
Ob die Rechner in der Aussenstelle ins Internet kommen weiß ich im Moment nicht. Sie ist lokal sehr weit entfernt, und bis anfang kommender Woche haben die Mitarbeiter dort Urlaub.
hier meine Interfaces Konfiguration:
Die Gegenstelle läuft (im Moment noch) auf einem OpenWRT gepimpten Konsumentenrouter von TP-Link. Sie hat schon seit 2 Jahren problemlos das VPN aufgebaut, zu einem baugleichen Modell das vorher aus OpenVPN Server funktioniert hat. Dieser war (und ist im Moment noch) das Gateway mit Firewall (OpenWRT auf einem TP-Link).
Aufgrund von Performance und Sicherheitsproblemen will ich aber den OpenVPN Server in eine eigenständige VM ausgliedern und den OpenWRT-Router durch einen professionelleren Router ersetzen.
Zusammengefasst: Mein Problem ist: Die IP-Packete werde vom OpenVPN Server nicht ins Netzwerk weitergeroutet. Der OpenVPN-Server bekommt verbindungen zu Geräten in der Aussenstelle.
Solltet Ihr noch andere Konfigurationen oder Logs brauchen sagt es bitte. Ich reiche sie dann nach.
Für jeden Tipp werde ich (und vor allem die Mitarbeiterinnen auf der Aussenstelle) sehr dankbar
Mit freundlichen Grüßen
Aileron
ich verzweifele hier gerade an einem vermutlich trivialen Problem. Meine Linux Kenntnisse sind leider nicht sehr ausgeprägt was Netzwerkrouting angeht...
Um das Problem zu veranschaulichen haben ich ein kleines Diagramm gezeichnet.
Ich habe zwei Netzwerke die ich gerne über einen VPN Tunnel verbinden will. Die Brücker soll Layer 2 sein, so dass Broadcasts (DHCP) oder pings mitgeroutet werden. Der OpenVPN Client von der Außenstelle baut die Verbindung auf.
Für den OpenVPN-Server habe ich eine HyperV-VM einen (aktuellen) Ubuntu Server aufgesetzt OpenVPN installiert und konfiguriert.
Hier die OpenVPN Configuration server.conf
mode server
tls-server
local 192.168.11.215 ## ip/hostname of server
port 1194 ## default openvpn port
proto udp
#bridging directive
dev tap0 ## If you need multiple tap devices, add them here
script-security 2 ## allow calling up.sh and down.sh
up "/etc/openvpn/up.sh br0 tap0 1500"
down "/etc/openvpn/down.sh br0 tap0"
persist-key
persist-tun
#certificates and encryption
ca /etc/keys/ca.crt
cert /etc/keys/server.crt
key /etc/keys/server.key # This file should be kept secret
dh /etc/keys/dh2048.pem
#tls-auth /etc/keys/ta.key 0 # This file is secret
cipher BF-CBC # Blowfish (default)
comp-lzo
#DHCP Information
ifconfig-pool-persist ipp.txt
server-bridge 192.168.11.215 255.255.255.0 192.168.11.60 192.168.11.80
push "dhcp-option DNS 192.168.11.3"
push "dhcp-option DOMAIN net.cat-luna.de"
max-clients 10 ## set this to the max number of clients that should be connected at a time
#log and security
user nobody
group nogroup
keepalive 10 120
status openvpn-status.log
verb 3
Der Router auf der Aussenstelle kann sich mit dem OpenVPN-Server verbinden, und im Server kann ich die einzelnen Netzwerkendgeräte anpingen. Sie antworten mir.
Nur von anderen Rechner aus dem "linken Netzwerk" (z.B. Rechner .100) wird der Drucker .61 nicht gefunden: "Zielhost nicht erreichbar"
Die VM openvpn-server ist aus jedem Punkt aus dem Büro eins erreicht werden.
Ob die Rechner in der Aussenstelle ins Internet kommen weiß ich im Moment nicht. Sie ist lokal sehr weit entfernt, und bis anfang kommender Woche haben die Mitarbeiter dort Urlaub.
hier meine Interfaces Konfiguration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo br0
iface lo inet loopback
# The primary network interface
iface br0 inet static
address 192.168.11.215
netmask 255.255.255.0
gateway 192.168.11.1
dns-nameserver 192.168.11.3 8.8.8.8
bridge_ports eth0 tap0
# these ones are for HyperV delay
bridge_fd 9 ## from the libvirt docs (forward delay time)
bridge_hello 2 ## from the libvirt docs (hello time)
bridge_maxage 12 ## from the libvirt docs (maximum message age)
bridge_stp off ## from the libvirt docs (spanning tree protocol)
iface eth0 inet manual
up ip link set $IFACE up promisc on
down ip link set $IFACE down promisc off
Die Gegenstelle läuft (im Moment noch) auf einem OpenWRT gepimpten Konsumentenrouter von TP-Link. Sie hat schon seit 2 Jahren problemlos das VPN aufgebaut, zu einem baugleichen Modell das vorher aus OpenVPN Server funktioniert hat. Dieser war (und ist im Moment noch) das Gateway mit Firewall (OpenWRT auf einem TP-Link).
Aufgrund von Performance und Sicherheitsproblemen will ich aber den OpenVPN Server in eine eigenständige VM ausgliedern und den OpenWRT-Router durch einen professionelleren Router ersetzen.
Zusammengefasst: Mein Problem ist: Die IP-Packete werde vom OpenVPN Server nicht ins Netzwerk weitergeroutet. Der OpenVPN-Server bekommt verbindungen zu Geräten in der Aussenstelle.
Solltet Ihr noch andere Konfigurationen oder Logs brauchen sagt es bitte. Ich reiche sie dann nach.
Für jeden Tipp werde ich (und vor allem die Mitarbeiterinnen auf der Aussenstelle) sehr dankbar
Mit freundlichen Grüßen
Aileron
Please also mark the comments that contributed to the solution of the article
Content-Key: 306868
Url: https://administrator.de/contentid/306868
Printed on: April 26, 2024 at 09:04 o'clock
7 Comments
Latest comment
Hallo Aileron,
zunächstmal muss ich sagen, dass ich mit einem Bridging-Setup nur wenig Erfahrung habe. Muss es denn bei dir unbedingt eine VPN-Bridge sein?
Wärst du mit einem gerouteten VPN nicht besser beraten? Ich kenne nur den Grundsatz: "Route if you can, bridge if you must".
Allein schon aus Performance-Gründen wäre das sinnvoll.
Ansonsten würde mir nur einfallen, dass vielleicht das IP-Forwarding deaktiviert ist: http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
Sonst müsste ich bei der Problemstellung passen.
Beste Grüße!
Berthold
zunächstmal muss ich sagen, dass ich mit einem Bridging-Setup nur wenig Erfahrung habe. Muss es denn bei dir unbedingt eine VPN-Bridge sein?
Wärst du mit einem gerouteten VPN nicht besser beraten? Ich kenne nur den Grundsatz: "Route if you can, bridge if you must".
Allein schon aus Performance-Gründen wäre das sinnvoll.
Ansonsten würde mir nur einfallen, dass vielleicht das IP-Forwarding deaktiviert ist: http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
Sonst müsste ich bei der Problemstellung passen.
Beste Grüße!
Berthold
so dass Broadcasts (DHCP) ....
Broadcasts kann man nicht routen das ist IP technischer Blödsinn.... Wenn dann bridgen. Du machst hier auch reines Bridging, sprich der OVPN Tunnel ist eine reine Layer 2 Bridge.Abgesehen davon ist die Konfiguration aber OK und soweit richtig. Siehe auch:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
Hilfreich wäre nochmal ein Posting des Verbindungsaufbaus aber dadurch das du vom Server pingen kannst über den Tunnel kann man davon ausgehen das der Tunnel selber sauber aufgebaut wird.
Bleiben dann nur noch 2 Fehlerquellen:
- MTU
- Lokale Firewall
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Sinnvoll ist es also die MTU hier zu begrenzen wenn xDSL im Einsatz ist.
Was das Thema Firewall anbetrifft muss du hier entsprechend die iptables des Servers beachten oder testweise die Firewall einmal komplett deaktivieren.
Generell sollte dir bewusst sein das Bridging bei VPN grundsätzlich keine gute Idee ist. Der gesamte Broad- und Multicast Traffic beider Netzsegmente flutet den VPN Tunnel und belastet diesen.
Da dieser immer nur einen Bruchteil der Bandbreite der LAN Segmente besitzt führt dieser Overhead Traffic beim Bridging immer zu einer massiven Performance Einbuße.
Das OVPN HowTo rät deshalb auch generell vom Bridging ab und preferiert Routing.
Abgesehen davon ist aber ein Bridging technisch natürlich möglich...keine Frage. Man sollte sich der Konsequenzen nur bewusst sein auf die Tunnel Performance.
Hallo,
warum wollen alle mit dem TAP arbeiten und nicht mit dem TUN!?
Warum ein reines Layer2 Netzwerk, schön flach und instabil!?
Man kann auch wie es @aqui schon gesprochen hat einfach
auf Layer3 Basis alles routen und gut ist es. Einfach zwei
unterschiedliche IP Adressenbereiche auf beiden Seiten
und gut ist es.
Gruß
Dobby
warum wollen alle mit dem TAP arbeiten und nicht mit dem TUN!?
Warum ein reines Layer2 Netzwerk, schön flach und instabil!?
Man kann auch wie es @aqui schon gesprochen hat einfach
auf Layer3 Basis alles routen und gut ist es. Einfach zwei
unterschiedliche IP Adressenbereiche auf beiden Seiten
und gut ist es.
Gruß
Dobby
Einen gravierenden Konfig Fehler hast du noch in deiner Bridge Konfig:
server-bridge 192.168.11.215 255.255.255.0 192.168.11.1 192.168.11.255Die .255 hat dort nichts zu suchen, das ist die Broadcast Adresse des Netzes und die ist reserviert wie die .0 !
Auch die Range .1 bis .255 ist syntaktisch falsch, denn dort dürfen nur einzig die Client IPs auftauchen und das sind die IP die bei dir der DHCP Range entsprechen.
Vergibt also dein DHCP Server z.B. Clients im Bereich .100 bis .200 dann gehört das in dies Konfig Statement !
Der Server der die VPN-Verbindung hat:
Mmmhhh, der pingt erfolgreich die .61 also einen Drucker im remoten Netz wenn man das Bild richtig liest, korrekt ?Das bedeutet das den VPN Tunnel fehlerlos funktioniert und Frames dort geforwardet werden...jedenfalls direkt vom Server.
Das es von einem lokalen PC nicht geht kann nur 2 Gründe haben:
- Die Bridge eth0 auf tap0 funktioniert nicht
- die MSS Size im lokalen LAN ist falsch
MSS müsstest du gem. obigem Blog ggf. auch anpassen.
Ggf. reicht auch schon die Korrektur des Bridge Parameters.
IP Forwarding ist übrigens Unsinn, das gilt nur bei Routing was du ja hier nicht machst. Aber besser machen solltest !!