Jun 11, 2016

2502

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

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 25, 2024 at 11: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

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

Als MTU hast du 1500 gewählt, das kann, wenn du eine DSL Verbindung hast, tödlich sein. Durch den PPPoE Overhead im DSL und UDP Encapsulation im Tunnel selber können so Frames entstehen die weit größer als die standardmässig erlaubten 1500 Bytes im Ethernet wären und Endgeräte zur Fragmentierung zwingen was diese nicht tun sondern diese Frames schlichtweg wegschmeissen !
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

Die MTU war tatsächlich falsch, das habe ich korregiert, leider ist es keine Lösung für mein Problem.

Das Routing über ein Layer3 TUN device ist geplant, der Hinweis hilft mir im Moment aber leider nicht weiter. Das Netzwerk habe ich so von meinem Vorgänger geerbt, und es hat bisher so funktioniert. Die 100MBit und die 50MBit VDSL Leitungen sind nicht so langsam, dass der Overhead ein Problem darstellt. Eine Änderung des Systems auf TUN scheint mir im moment auch nicht möglich, bzw. ich wüsste nicht, wie ich das durchführen sollte.

Ich habe noch ein wenig an der server.conf rumgeschraubt, hier ein Update.

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 1442"  
down            "/etc/openvpn/down.sh br0 tap0"  

persist-key
persist-tun
client-to-client

#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.1 192.168.11.255
tun-mtu         1442
push            "dhcp-option DNS 192.168.11.3"  
push            "dhcp-option DOMAIN net.cat-luna.de"  
push            "redirect-gateway"  
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

nach wie vor sind beide eth0 und tap0 in br0 gebridged, beide stehen auf promisc und ich habe beide über die iptables filter auf accept gestellt, egal was reibkommt.
IP-Forwarding ist im Kernel aktiviert.

Das problem ist folgendes...
Der Server der die VPN-Verbindung hat:

root@openvpn-srv:/etc/openvpn# ping 192.168.11.61
PING 192.168.11.61 (192.168.11.61) 56(84) bytes of data.
64 bytes from 192.168.11.61: icmp_seq=1 ttl=254 time=36.1 ms
64 bytes from 192.168.11.61: icmp_seq=2 ttl=254 time=34.2 ms
64 bytes from 192.168.11.61: icmp_seq=3 ttl=254 time=39.7 ms
64 bytes from 192.168.11.61: icmp_seq=4 ttl=254 time=37.3 ms
^C
--- 192.168.11.61 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3008ms
rtt min/avg/max/mdev = 34.294/36.903/39.751/1.985 ms

Ein anderer Rechner im Netzwerk (gleiches subnet, verbunden mit dem OpenVPN Rechner)

C:\Users\aileron>ping 192.168.11.61

Ping wird ausgeführt für 192.168.11.61 mit 32 Bytes Daten:
Antwort von 192.168.11.50: Zielhost nicht erreichbar.
Antwort von 192.168.11.50: Zielhost nicht erreichbar.
Antwort von 192.168.11.50: Zielhost nicht erreichbar.
Antwort von 192.168.11.50: Zielhost nicht erreichbar.

Ping-Statistik für 192.168.11.61:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),

Es scheint, das die anderen Rechner nicht wissen, welche IP-Adressen sich hinter dem VPN-Server befinden und diesen nicht als Switch akzeptieren...
Oder der VPN-Server bekommt die Packete aus dem Netzwerk, sieht aber, dass sie nicht an ihn gerichtet sind und verwirft sie wieder anstelle sie ins VPN weiterzuleiten...

Mit freundlichen Grüßen,
Aileron

Hallo Aileron,

IP-Forwarding ist aber aktiv?

root@openvpn-srv:/etc/openvpn# cat /proc/sys/net/ipv4/ip_forward
1

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.255
Die .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

Ersteres bekommst du raus indem du mal den OVPN Client auf der anderen Seite vom Server pingst.
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 !!

German Question Networking Basics Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments