12.06.2020

2108

Policy Based Routing für Linux Client (OwnCloud, OpenVPN)

Hallo,

bin gerade dabei mir ein OwnCloud Server (Ubuntu Server 20.04) aufzusetzen, was auch soweit funktioniert, jedoch ist der Server nur bedingt aus dem Internet erreichbar. Mit bedingt meine ich, sobald der Server als Client über einen OpenVPN Tunnel verbunden habe, ist er nicht mehr über seine ddns-Adresse erreichbar - aus dem lokalen Netzwerk (192.168.160.0) ist er weiterhin problemlos erreichbar.

Vermute ein Routing-Problem, also das der Request/Response nicht korrekt ankommt und bin dann auf Policy Based Routing gestoßen, denke mit der korrekten Einstellung müsste es damit möglich sein. Habe meine Netzstruktur mal in einem Bild dargestellt. Die folgenden Regeln/Routen sind angelegt, aber leider bekomme ich noch nichts vom Server über den ddns zurück.

sudo ip rule add from 192.168.160.160 table no_vpn
sudo ip route add 192.168.160.0/24 dev eth0 table no_vpn
sudo ip route add 192.168.150.0/24 dev eth0 table no_vpn
sudo ip route add default via 192.168.160.1 dev eth0 table no_vpn

Was stimmt hier nicht? Hab ich irgendwo einen Denkfehler?

Besten Dank.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 578872

Url: https://administrator.de/forum/policy-based-routing-fuer-linux-client-owncloud-openvpn-578872.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

46 Kommentare

Neuester Kommentar

Vermute ein Routing-Problem,

Sehr wahrscheinlich.... Dazu müsste man aber sehr genau dein OVPN Setup kennen was leider fehlt.

Das NAS ist vermutlich der OVPN Client und initiiert die VPN Verbindung, richtig ?
Hier wäre es wichtig seine und auch die Konfig Datei des Servers zu sehen.
Du solltest dir dazu dringenst auch die OVPN ToDos durchlesen und deine OVPN Konfig daraufhin überprüfen:
Merkzettel: VPN Installation mit OpenVPN

Sehr wahrscheinlich machst du hier fälschlicherweise ein Gateway Redirect oder NAT im Tunnel oder sowas ?!
Statische Routen sind auf dem OVPN Client generell Unsinn und nicht erforderlich. Fragt sich also was diese da bewirken sollen ?! Mit Policy Based Routing hat das ganze auch nicht das Geringste zu tun. Insofern ist auch die Überschrift des Threads sehr verwirrend.
Das können wir aber, wie gesagt, nur frei raten oder in die Kristallkugel sehen weil hier leider die Details fehlen.
Das o.a. Tutorial hat aber auch unter den weiterführenden Links alle Infos dazu !
Nebenbei:
Die interne OVPN Tunneladresse mit einer öffentliche IP zu konfigurieren die offizell durch die IANA vergeben ist und NICHT dir gehört (sondern Vodafone) ist auch keine besonders intelligende Idee. Auch hier solltest du immer RFC 1918 IPs verwenden !

Welche Details brauchst noch?

Ich verbinde mich mit dem NAS/HomeServer zu ipVanish also den VPN Server kann ich nicht konfigurieren. Ich nutze hierfür die von ipVanish bereitgestellten ovpn-Konfigurationen und wechsele nur die Location bei jedem connect.

Die Skizze ist vermutlich etwas missverständlich, also ich baue zu ipVanish die Verbindung auf, der physikalische Datenfluss geht über ISP wobei der nur verschlüsselte Daten sieht.

Nun möchte ich den HomeServer über einen ddns aus dem Internet erreichen, was auch funktioniert wenn der OpenVPN nicht verbunden ist. Ähnliche Probleme führten mich zu Policy Based Routing, sah für mich plausibel aus...

Du verbindest Dein NAS also mit nem Honeypot.

Warum macht man sowas?

Möchte, dass der Traffic zum/vom HomeServer anonymisiert bzw. verschlüsselt übertragen wird.

Hier die .ovpn

client
dev tun
remote ch-zr2.ipvanish.com
port 1194
pull
auth-user-pass /home/unknown/cred
tun-mtu 1500
mssfix 1400
ca /home/unknown/openvpn/serverlocation.crt
comp-lzo
keepalive 10 60
nobind
float
cipher BF-CBC
ns-cert-type server

Ich sach mal so:

"Das ist auf so vielen Ebenen Quatsch ..."

(das ist schwer auszuhalten ... @aqui rotiert vermutlich seit der Erwähnung von "ipVanish")

a) So nen VPN-Anbieter ist - mit Ausnahme des Aushebelns von Geofencing-Maßnahmen - mehr Schein als sein. Die Nachteile dürften problemlos die (gedachten und beworbenen) Vorteile aufwiegen.

b) VPN ist NUR die Bezeichnung des Tunnels zwischen 2 IP-Geräten. Der Einsatzzweck von Dir ist ein ganz anderer als der, der von so nem Fliegenfänger wie "ipVanish" angedacht ist.

c) Derzeit connectest Du Dein NAS von zuHause nach ... Panama?! Und der Weg dorthin ist (bestenfalls) mit OpenVPN verschlüsselt. Der Anbieter wirbt dort - am Endes des Tunnels - mit Anonymität. Was auch immer der darunter versteht ... ich finde es verwunderlich, dass Du Dich beschwerst, dass Du von "außen" dann den Weg nicht mehr "zurückverfolgen" kannst. Denn das wäre ja der Zweck dieses, Deines Konstruktes.

d) Lass den "ipVanish"-Dreck weg! Die VPN/Tunnel wird von Deinem Endgerät (iPhone, Notebook) über das Internet aufgebaut .... tata zu DEINEM Router! Und wenn der Router das nicht packt, dann auf das NAS direkt mit weitergeleiteten Ports. Wobei die Version 2 aus Sicherheitsgründen nicht so prickelnd ist.

Zur Zeichnung: Warum steht unter allem "OwnCloud"?! Die läuft ja eigentlich auf dem NAS. Wenn Du darüber hinaus noch 2 Router einsetzt (warum und welche Modelle), dann wird der Zugriff von außen eh schwierig (Stichw. NAT, bzw. doppeltes NATchen)

Hehe danke für die schnelle Antwort - habe das auch nochmal hinterfragt und bin bei dir, dass das Schwachsinn ist wenn der Tunnel schon den Traffic verschleiert.

Router ins Internet ist eine FritzBox und dahinter hängt ein ASUS RT86U. Die Fritzbox dient nur als Modem, wobei das doppelte NATn bisher gut funktioniert sofern kein VPN aktiv.

Also habe den ipVanish mal deaktiviert und einen VPN Server auf dem ASUS RT86U gestartet und verbinde mich mit diesem, aber auch dann kann ich meine OwnCloud nicht von außen über die DDNS erreichen.

Zur Zeichnung:
Ich möchte die OwnCloud über die Public IP bzw. DDNS über Port 8080 erreichen. Es gibt eine Portweiterleitung von der Fritzbox auf dem ASUS, der wiederum den Port weiterleitet an den HomeServer.

"Nur als Modem" klappt mW. bei der Fritze nicht. Und Du hättest das ggfs. auch nicht so konfiguriert, sonst hättest Du ja nicht 2 lokale IP-Bereiche hintereinander.

Worauf soll denn der VPN-Server laufen?! Auf der Fritze (IPSec), Asus (OpenVPN und PPTP) oder dem NAS?!

Mein Ansatz wäre wohl:
DDNS auf der Fritze (natürlich

NAT beim Asus deaktivieren (in den Einstellungen des WAN-Ports)
Firewall beim ASUS deaktivieren
DHCP beim Asus deaktivieren
OpenVPN im Asus aktivieren (pptp ist des Teufels!) und konfigurieren
Die entsprechenden OpenVPN-Ports in der Fritzbox an den OpenVPN-Server weiterleiten

Dabei wirst Du Deinem NAS ne Adresse aus dem IP-Bereich der Fritze geben müssen.

Arbeiten die Geräte alle im gleichen IP-Bereich musst Du da auch beim Asus nix an das NAS weiterleiten. Du bist dann mit dem Asus im kompletten lokalen Netzwerk inkl. Drucker, NAS usw.

Moin,

aktuell habe ich zwei lokale IP-Bereiche, das Fritz-Netz (ohne Clients) und das RT86U-Netz mit allen Clients. Das Problem, ich kann beim RT86U über den WAN-Port nicht in den gleichen IP-Bereich wie die FritzBox, sollte aber auch kein Problem sein oder?

- DDNS auf Fritz - läuft
- NAT/UPnP aus bei ASUS - läuft nicht (bekomme nur eine Verbindung ins Netz wenn beides aktiv ist)
- Firewall aus bei ASUS - läuft
- DHCP aus bei ASUS - läuft nicht (wegen eigenem IP-Bereich)
- OpenVPN im ASUS - läuft
- Port bei Fritz (1194 TCP) - weitergeleitet

Mach ich noch was falsch?! ^^

nicht in den gleichen IP-Bereich wie die FritzBox, sollte aber auch kein Problem sein oder?

Das ist logisch, denn schon in der IP Grundschule lernt man ja zuallererst das IP Netze immer einzigartig zu sein haben ! Wie sollte sonst auch eine eindeutige Wegefindung realisiert werden können ?!
UPnP sollte generell immer auf einem Router deaktiviert werden, denn das birgt sehr große Gefahren das Malware, Trojaner und Co. automatisch die Firewall manipulieren von intern. UPnP auf einem Router oder Firewall ist also ein absolutes NoGo und gehört deshalb immer deaktiviert ! Weiss man als Netzwerker aber auch.

Port bei Fritz (1194 TCP) - weitergeleitet

TCP ist bei OpenVPN auch ein NoGo ! Geht zwar, aber selbst OpenVPN rät dringenst von TCP als Encapsulation ab ! Ist auch ganz klar, denn das erzeugt massiv Overhead und frisst viel CPU Performance durch das zusätzliche Sessionhandling. Durch die erheblich kleinere MTU sinkt zudem massiv der Datendurchsatz. Alles in allem zieht das also massiv die Performance des VPNs in den Keller. Deshalb gilt hier: Immer UDP verwenden !

Mach ich noch was falsch?!

Bis auf die 2 Sachen nix.
Alles weitere findest du wie immer im OpenVPN Merkzettel:
Merkzettel: VPN Installation mit OpenVPN
..und seinen weiterführenden Links.

Danke für deine Antwort - bin kein Profi, aber so einigermaßen weiß ich Bescheid allerdings befasse ich mich nur damit, wenn ich dann alle paar Monate mal an meinem Heimnetzwerk rumschraube

Also sobald ich NAT ausschalte komme ich nicht mehr ins Internet. Ich kann von Clients im ASUS-Bereich die Fritzbox und von Testclients im Fritzbox-Bereich den ASUS pingen. Also der Ping geht in beide Richtungen, ich kann auch von dem RT86U auch google/amazon pingen, aber die Clients können es ohne NAT nicht - warum? -> Hat nun funktioniert, vermutlich waren noch irgendwo alte Einstellungen aktiv (habe mal beide Router neugestartet und jetzt geht es).

Alles klar habe ich gerade wieder auf UDP gestellt, aber so will der HomeServer irgendwie nicht drauf connecten. - Funktioniert nun, war falsche IP-Adresse im File

Allerdings lässt sich der HomeServer immer noch nicht über DDNS:8080 von außer erreichen. Also auch nicht mehr, wenn VPN nicht verbunden ist.

Also sobald ich NAT ausschalte komme ich nicht mehr ins Internet.

Klar, weil du zu 99% vergessen hast eine statische Route in der FritzBox einzutragen !!
Bitte nimmt dir die Zeit und lese das hiesige Tutorial gründlich durch. Dort ist doch nun wahrlich ALLES haarklein so erklärt das es auch völlige Laien verstehen:
Merkzettel: VPN Installation mit OpenVPN
(Kapitel: Statische Route.... !)

Also auch nicht mehr, wenn VPN nicht verbunden ist.

Deine Route fehlt ! Dann kann es auch nicht klappen.
Beachte bitte die statischen Routen UND das push route.... Kommando in der OpenVPN Server Konfig !
Lesen und verstehen...!!!
Traceroute ist dein bester Freund beim Troubleshooting !

Danke dir mit Merkzettel habe ich den VPN auch zum Laufen bekommen - kann über DDNS 1194 mich mit dem OpenVPN Server verbinden.

Allerdigns erreiche ich meinen HomeServer nicht mehr über DDNS:8080 von außen, auch nicht wenn VPN deaktiviert. Habe testweise nun eine Portweiterleitung gemacht 822 auf 22 vom HomeServer gemacht und komme auch nicht mehr durch.

Allerdigns erreiche ich meinen HomeServer nicht mehr über DDNS:8080

Ist ja nun auch Quatsch wenn du ein VPN hast, denn bei aktivem VPN reicht einfach ein http://<ip_home_server>
Vermutlich hast du im Eifer des Gefechts das Router Port Forwarding für TCP 8080 auf die interne IP des Home Servers mit TCP 80 gelöscht ?! Kann das sein ?
Wie gesagt. Beim VPN brauchst du kein unsicheres Port Forwarding mehr ! Ist ein Loch weniger in der Firewall wo dein internes Netz gefährtet werden könnte.

TCP 8080 ist ein gefährlicher Trivialport den jeder Hacker und Port Scanner per Default abklopft. Sei also froh...!

Ahso jetzt verstehe ich wie du meinst, ich soll mich zum VPN connecten und dann auf meine OwnCloud zugreifen.

Also habe die Route gepusht dann bekomme ich den folgenden Fehler

ERROR: Linux route add command failed: external program exited with error status: 2

Ich kann nun von überall auf den VPN Server verbinden, aber die Clients untereinander nicht ansprechen über die IP.

Zum TCP8080, mich wundert es nur dass es nun überhaupt nicht mehr funktioniert...

aber die Clients untereinander nicht ansprechen über die IP.

Das erfordert dann auch eine konfigurierte client-to-client Option in der Server Konfig ! Siehe hier:
Merkzettel: VPN Installation mit OpenVPN
Wenn das Windows Clients sind ist hier zusätzliche eine Anpassung der Windows lokalen Firewall nötig.

Zum TCP8080, mich wundert es nur dass es nun überhaupt nicht mehr funktioniert...

Wie gesagt...entweder ist die Port Forwarding Konfig am Router falsch oder fehlerhaft oder ganz entfernt. Durch deine oberflächliche Beschreibung wissen wir auch nicht ob du Port Translation auf intern TCP 80 machst oder den Port TCP 8080 weitereichst auf den internen Server und ob dieser nun auf 80 oder 8080 lauscht ?
Warum machst du nicht einen tcpdump oder nimmst den Wireshark und siehst dir mal die per Port Forwarding weitergeleiteten IP Pakete genau an. Da siehst du doch innerhalb von 3 Minuten wo der Fehler ist !!
Warum also sinnfrei rumraten statt sauber messen ??
So oder so ist jetzt wo du ein sicheres VPN nutzt es ja sinnfrei noch das gefährliche Port Forwarding zu nutzen. Es war ja sicher deine Intention dein Netz mit einem VPN sicherer zu machen, oder ?

Halte dich an das o.a. OpenVPN Tutorial. Dort sind ALLE Optionen haarklein auch für Laien erklärt.
Die Fehlermeldung zeigt das du noch gravierende Fehler in der OpenVPN Konfig gemacht hast. Vermutlich Server...?!
Da weiterhin deine aktuelle Server Konfig Datei hier fehlt können wir auch nur im freien Fall raten...

Das erfordert dann auch eine konfigurierte client-to-client Option in der Server Konfig.

Mh das ist das was ASUS WRT aus den Einstellungen vom Merkzettel gemacht hat. Scheint nicht ganz konform zu sein ^^

 #Automatically generated configuration
daemon ovpn-server1
topology subnet
server 177.17.77.0 255.255.255.0
proto udp
port 1194
dev tun21
txqueuelen 1000
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
cipher AES-256-CBC
auth SHA256
comp-lzo adaptive
keepalive 15 60
verb 3
push "route 192.168.160.0 255.255.255.0 vpn_gateway 500"  
client-config-dir ccd
client-to-client
duplicate-cn
push "dhcp-option DNS 192.168.160.1"  
push "dhcp-option DNS 192.168.160.1"  
push "dhcp-option DNS 192.168.160.1"  
push "redirect-gateway def1"  
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
verify-client-cert none
username-as-common-name
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up updown.sh
down updown.sh
status-version 2
status status 5

# Custom Configuration
topology subnet
push "topology subnet"  
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
status-version 3
topology subnet
keepalive 10 120

Also wie auf dem Bild für die OwnCloudanwendung beschrieben. Der Server hört auf 8080, die Ports werden von 8080 über 8080 durchgeleitet an den Server, hatte auch funktioniert. Du hast recht, könnte mich mal mit Wireshark dransetzen

aber wäre auch egal, wenn der OpenVPN Server funktionieren würde, aber das Push-Route funktioniert irgendwie nicht ich erreiche im VPN Subnetz keine anderen Clients und komme vom VPN aus nicht raus.

Scheint nicht ganz konform zu sein

Das ist es in der Tat nicht ! Die gravierensten Fehler mal auf gelistet:

Der Server nutzt im internen VPN ein öffentliches IP Netzwerk was registriert ist und NICHT dir gehört sondern einem Nutzer in Brasilien !!

Sowas ist nicht besonders intelligent und Routing technisch tödlich und sollte man zwingend IMMER auf eine private_RFC_1918_Adresse ändern !!

comp-lzo adaptive sollte man aus Security Gründen NICHT mehr nutzen mit OpenVPN !! Siehe: https://community.openvpn.net/openvpn/wiki/VORACLE
push "dhcp-option DNS 192.168.160.1" Kommando sinnloserweise 3mal zu konfigurieren ist Blödsinn !
Gleicher Blödsinn topology subnet 3mal zu setzen !
Split Tunneling mit push "route 192.168.160.0 255.255.255.0 vpn_gateway 500" und dann gleichzeitig noch ein Gateway Redirect push "redirect-gateway def1" ist natürlich Konfig technischer Schwachsinn. Sorry, aber logischerweise kann hier nur eins zur Zeit gehen !! Siehe OVPN Merkzettel !! Lesen und verstehen !

Eine völlig gruselige und teils falsche OPVPN Server Konfig. Da muss einen dann nix wundern wenns kneift.
Besonders die falsche Routing Konfig ist für deine o.a. Client Fehlermeldung verantwortlich.
Ein route print auf einem (Windows) Client mit aktivem Tunnel sollte dir das Dilemma auch sofort zeigen.
Fazit:
Halte dich an das OVPN Tutorial und bringe die Server Konfig Datei auf einen sinnvollen Stand, dann klappt das auch alles wie es soll.

Danke für deine Antwort.

Wie gesagt, ich habe die Fehler anhand deines Merkzettels erkannt, aber ich kann den Server auf dem Router nur über die UI konfigurieren andernfalls wird die config jedesmal überschrieben wenn ich etwas im UI ändere.

Habe jetzt den RT86U zurückgesetzt, aber komme über den VPN-Server immer noch nicht ins Internet.

Funktioniert hier mit nem RasPi als VPN Client fehlerlos... Da hat dann wohl der RT86U ne Macke oder was wahrscheinlicher ist eine völlig falsche oder fehlerhafte VPN Konfig ?!
Lass den Wireshark oder tcpdump mitlaufen und checke was da im Netz passiert.

Hilfreich wäre nochmal die jetzt aktuell laufende OVPN Server und Client Konfig zu sehen und ein Status was genau geht und was nicht.

Also hier mal die Konfigurationen. Der Dump kommt gleich.

OpenVPN server config

Automatically generated configuration

daemon ovpn-server1
topology subnet
server 172.16.4.0 255.255.255.0
proto udp
port 1194
dev tun21
txqueuelen 1000
ncp-disable
cipher AES-256-GCM
auth SHA256
compress lz4-v2
keepalive 15 60
verb 3
push "route 192.168.2.0 255.255.255.0 vpn_gateway 500"
duplicate-cn
push "dhcp-option DNS 192.168.2.1"
push "redirect-gateway def1"
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
verify-client-cert none
username-as-common-name
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up updown.sh
down updown.sh
status-version 2
status status 5

Client config

client
dev tun
proto udp
remote mydns.ddns.net 1194
float
cipher AES-256-GCM
auth SHA256
compress lz4-v2
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>

BEGIN CERTIFICATE-----
MIIETzCCAzegAwIBAgIUZkqasA3I+hbExRn1CLlGMidahoVowDQYJKoZIhvcNAQEF

END CERTIFICATE-----
</ca>
resolv-retry infinite
nobind

Also im tcpdump taucht nichts von der IP auf, nur vom Docker-Netz.

Das ist eher ein schlechtes Zeichen und zeigt das das Routing nicht sauber rennt. Checke das nochmal wasserdicht mit Traceroute oder Pathping.
Weisst du ob der Router ggf. NAT (Adress Translation) im Tunnel macht ?! Das wäre dann tödlich und würde für das Verhalten sprechen. Wenn das der Fall ist musst du das zwingend deaktivieren.

NAT/UPnP sind wie empfohlen ausgeschaltet.

Hier ein tcpdump von der richtigen Schnittstelle bei ping von google.de

13:24:30.303021 IP (tos 0x0, ttl 64, id 30058, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.4.2 > arn09s19-in-f3.1e100.net: ICMP echo request, id 38398, seq 0, length 64
13:24:31.304074 IP (tos 0x0, ttl 64, id 30270, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.4.2 > arn09s19-in-f3.1e100.net: ICMP echo request, id 38398, seq 1, length 64
13:24:32.305175 IP (tos 0x0, ttl 64, id 30336, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.4.2 > arn09s19-in-f3.1e100.net: ICMP echo request, id 38398, seq 2, length 64
13:24:33.306256 IP (tos 0x0, ttl 64, id 30391, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.4.2 > arn09s19-in-f3.1e100.net: ICMP echo request, id 38398, seq 3, length 64
13:24:34.307356 IP (tos 0x0, ttl 64, id 30506, offset 0, flags [DF], proto ICMP (1), length 84)
172.16.4.2 > arn09s19-in-f3.1e100.net: ICMP echo request, id 38398, seq 4, length 64
13:24:34.815450 IP (tos 0x0, ttl 64, id 43824, offset 0, flags [DF], proto TCP (6), length 60)

traceroute google.de

traceroute to google.de (216.58.207.227), 30 hops max, 60 byte packets
1 172.16.4.1 (172.16.4.1) 1.273 ms 1.260 ms 1.252 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Wie du sehen kannst kommt von arn09s19-in-f3.1e100.net keine Antwort !
Ist auch kein Winder denn der Echo Request (Ping) kommt von der 172.16.4.1 gar nicht mehr weiter zum Ziel, da ist Schluss.
Es wäre übrigens besser wenn du bei tcpdump die Namensauflösung abschaltest !! Es ist sinnvoller IP Adressen zu sehen als Namen beim Troubleshooting !
Der Traceroute ended wie oben bereits gesagt bei 172.16.4.1, was bedeutet das DA der Fehler ist. Dort geht es nicht mehr weiter und dort ist eine falsche Routing Tabelle zu vermuten !
Wenn das der Router ist kannst du die Routing Tabelle mal posten oder wenn der einen Shell Zugriff erlaubt mit SSH/PuTTY kannst du dann von dort mal einen netstat -r -n posten oder sofern er den IP Commandset supportet ein ip route show ?

Meine Vermutung geht Richtung DNS?!

netstat -r -n

Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
172.16.4.0 0.0.0.0 255.255.255.0 U 0 0 0 tun21
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

ip route show

default via 192.168.1.254 dev eth0
127.0.0.0/8 dev lo scope link
172.16.4.0/24 dev tun21 proto kernel scope link src 172.16.4.1
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.253
192.168.1.254 dev eth0 proto kernel scope link

Meine Vermutung geht Richtung DNS?!

Könnte auch sein. Aber das kannst du ja kinderleicht ausschliessen wenn du mal nackte IP Adressen als Ziel pingst. Sollte man als Netzwerker auch eigentlich selber drauf kommen !!

ping 8.8.8.8 z.B. oder traceroute 8.8.8.8 pingt und traceroutet ohne jegliches DNS ins Internet.

Die Routing Tabelle zeigt das das das Default Gateway des Gerätes die 192.168.1.254 ist. Das ist vermutlich der Internet Router, richtig ?
172.16.4.0 /24 ist das Tunnelnetz
Was komisch ist ist der Fakt das das 2er Netz an einer Bridge hängt. Das ist nicht normal.
Die Routing Tabelle zeigt das keinerlei relevanter Traffic durch den Tunnel geroutet wird. Du kannst einzig nur Endgeräte im 172.16.4er Tunnelnetz erreichen und alles andere geht an die 192.168.1.254 raus.
Ist das so gewollt. also das du einzig nur VPN Clients erreichen kannst ?!

Ah stimmt, aber mit IP gehts auch nicht durch.

Genau die Fritze ist 192.168.1.254.

Die Bridge kommt vermutlich, weil er die 6 LAN Ports eth1-6 ins selbe Netz hängt? Also mit brctl show br0 zeigt er mit auch an, dass die eth1-6 dranhängen. Die sind alle im 2er Netz unter der Bridge. Und eth0 ist der WAN im 1er Netz.

Genau das möchte ich nicht, möchte sämtlichen Traffic (LAN/WAN) durch den Tunnel routen und trotzdem alle Geräte im Netzwerk erreichen. Aktuell kann ich bei verbundenem VPN die lokalen Geräte pingen (im 1er , 2er und 4er Netz).

Eventuell die Routen einfach statisch anlegen?

OK, das .2.0er Netz ist das lokale IP Netz am RT Router richtig.
Wie sind die Router denn verschaltet ?? In einer Kaskade ??

Wenn du mit dem Client auf dem RT OVPN Router eingewählt bist, was sagt denn die Routing Tabelle auf dem Client ??
Wird dort das .2.0er Netz richtig propagiert ? Und...kannst du von dort die .2er IP des Routers pingen sowie alle internen OVPN IPs ?
Windows: route print
Unixoide OS: wie oben netstat -r -n oder ip route show

Das 2er Netz ist mein lokales Netz am ASUS Router. Die Fritze ist über LAN Port mit dem ASUS am WAN Port verbunden.

Wenn ich mit dem Client eingewählt bin, dann kann ich alle Rechner/Router im 2er/1er/4er Netz pingen.

netstat -r -n

Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.16.4.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth1
<PUBLIC_IP> 192.168.2.1 255.255.255.255 UGH 0 0 0 eth1
128.0.0.0 172.16.4.1 128.0.0.0 UG 0 0 0 tun0
172.16.4.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.24.24.0 0.0.0.0 255.255.255.0 U 0 0 0 br-d5cb6383c865
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.2.0 172.16.4.1 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth1

Also den Fehler sehe ich nicht, sieht für mich so aus als ob

localhost/128.0.0.0/172.16.4.0/192.168.2.0 über tun0 geht, da müsste doch mit dem 128.0.0.0 auch das der Public Bereich mit dabei sein oder?

EDIT

Bin mit Routing nicht allzu gut vertraut, aber könnte es mir so in der Art vorstellen. Über tun0 in öffentliche Netze, über tun0 ins 2er Netz und vom 2er Netz ein Gateway ins 1er Netz - was meinst du?

netstat -r -n

Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.16.4.1 0.0.0.0 UG 0 0 0 tun0
172.16.4.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.24.24.0 0.0.0.0 255.255.255.0 U 0 0 0 br-d5cb6383c865
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.2.0 172.16.4.1 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth1

Möchtest mir helfen, die Routen voll glatt zu ziehen? Krieg das irgendwie nicht ganz gebacken.

Du musst nur lesen können um die Routen zu interpretieren.

0.0.0.0 172.16.4.1 0.0.0.0 UG 0 0 0 tun0

Das ist die Default Route. "0.0.0.0" steht für alle Netze die lokal unbekannt sind. Diese gehen also an die 172.16.4.1 als Default Gateway IP was die interne OVPN IP des Servers ist. Das ist auch klar das das so ist, denn mit push "redirect-gateway def1" erzwingst du ja einen Gateway Redirect auf dem Client, sprich ALLER Traffic (auch lokaler Internet Traffic usw.) geht in den Tunnel.
Ist das so gewollt ?? Normalerweise macht man Split Tunneling im VPN um den Tunnel nicht so zu belasten. Aber ggf. ist das so auch gewollt von dir.
Der Rest ist schnell erklärt:

172.16.4.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Ist das lokale /24 IP Netz im OVPN Tunnel Interface. ("server 172.16.4.0 255.255.255.0" Kommando)

172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0

Ist ein internes /16er IP Netz am virtuellen Docker Netzwerk Interface

172.24.24.0 0.0.0.0 255.255.255.0 U 0 0 0 br-d5cb6383c865

Ist ein /24er Netz am (vermutlich) irgendeinem Bridge Interface das wohl mehrere Interfaces in einer Layer 2 Bridge zusammen fasst. (Geraten weil "br..." irgendwie nach Bridge aussieht ?!)

192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

IP Netz am physischen eth1 LAN Interface.

192.168.2.0 172.16.4.1 255.255.255.0 UG 0 0 0 tun0

HIER ist ein fataler Fehler !!!
Das wäre eine Route die das 192.168.2.0er IP Netz in den OVPN Tunnel routet.
DAS darf aber niemals sein wenn das lokale eth1 Interface AUCH im gleichen IP Netz liegt !!!
Hier liegt dann eine doppelte IP Adressierung vor die eine eindeutige Wegefindung unmöglich macht. Das .2.0er Netz ist also unroutebar. Das musst du irgendwie fixen.

192.168.1.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth1

Das ist eine statische Route die das 192.168.1.0 /24 er Netz über eine Gatway IP .1 im 192.168.2.0er IP Netz routet. Auch diese wird vermutlich wegen der falschen Route des .2.0er Netz höchstwahrscheinlich NICHT funktionieren, da eben das .2.0er Netz unroutebar ist.
Hier stimmt also grundsätzlich etwas mit dem Routing des .2.0er Netzes nicht was du unbedingt fixen musst !

Vielen Dank, dann hab ich zwar einiges verstanden, aber auch einiges nicht.

Wie sieht so ein splitting aus? C Netze nicht Tunneln und A und B Tunneln?

Die Bridge kommt vermutlich von Containern (verbindet 3 veth)

Wie kann ich das fixen, also wo setze ich an? Am Client oder am Server? Muss ich auf dem Router/Server statische Routen?

Wie sieht so ein splitting aus? C Netze nicht Tunneln und A und B Tunneln?

Bei einem Split Tunneling wir NUR der Traffic in den VPN Tunnel geleitet der in die remoten IP Netze soll aber nicht sämtlicher Traffic. Will man lokal also nur im Internet Surfen, YouTube nutzen oder Emails ziehen passiert das über den lokalen Internet Anschluss und NICHT über den Tunnel.
Man "splittet" also quasi den Traffic auf wobei ein "Redirect" das Default Gateway umbiegt auf den Tunnel und damit dann sämtlichen Traffic in den Tunnel sendet.
Eigentlich ganz einfach und logisch wenn man mal nachdenkt.

Wie kann ich das fixen, also wo setze ich an? Am Client oder am Server?

Solche banalen Dinge solltest du aber als OVPN Netzwerker schon wissen. Das ist eher bedenklich das das bei solchen einfachen Dingen schon Probleme gibt.
Das definiert man immer mit dem push route.... Kommando auf dem Server ! Der Server propagiert ja die Routen an den Client.

push "route 192.168.2.0 255.255.255.0" = Routet nur Traffic ins 192.168.2.0er Netz in den Tunnel ! (Split Tunnel)
push "redirect-gateway def1" = Routet sämtlichen Traffic in den Tunnel ! (Gateway Redirect)

Es geht immer nur das eine ODER das andere aber niemals BEIDES !!
Deshalb kannst du schon deine falsche Server Konfig oben sehen in dem fälschlicherweise BEIDES definiert ist. Gewinnen tut immer der letzte Eintrag in der Konfig Reihenfolge und das ist bei dir dann der Redirect wie man an der Client Routing Tabelle ja dann auch sehen kann.
Diese Konfig ist also komplett FALSCH was das Routing anbetrifft, denn es geht nur ein Verfahren von beiden aber logischerweise niemals beide.
Das hiesige OVPN_Tutorial weisst auch mehrfach explizit ! auf diesen Punkt hin im Kapitel Konfiguration Server !!
Lesen und verstehen hilft hier also wirklich !!

Hast recht, aber bei mir sind das immer nur so nebenher Projekte. Ich glaub solangsam auch, dass wenn ich den OpenVPN server woanders Plain aufsetzen würde, er schon längst laufen würde.

Davon ist sicher auszugehen, denn die Konfig oben ist ja de facto falsch und kann so niemals gehen.
Du solltest dort mit einem Shell Zugang (SSH und PuTTY) draufgehen und das manuell korrigieren.

Also ich krieg das nicht raus.

Habe gefühlt alles probiert, der VPN Server lässt sich nicht über SSH konfigurieren, denn sobald ich den Server starte überschreibt er die Config wieder mit der letzten aus dem nvram.

Der push "redirect-gateway def1" und push "route 192.168.2.0 255.255.255.0 vpn_gateway 500" sind immer dabei egal was ich mache.

Was mir aber aufgefallen ist, nachdem ich den Server mehrfach auf Default zurückgesetzt habe, dass alles funktioniert wenn ich die IP des Servers nicht verändere also im Bereich 10.8.0.0 bleibe. Sobald ich die IP auf 172.16.4.0 ändere, erreiche ich Google nicht mehr.

Die Routen haben sich nicht sonderlich verändert.

denn sobald ich den Server starte überschreibt er die Config wieder mit der letzten aus dem nvram.

Was ist das denn für ein Schrott ?! Aber das ist natürlich der Fluch wenn man sich von einer Hersteller Firmware abhängig macht und die die Konfig dann immer wieder verwurstet...

Da ist man dann letztlich ja auch chancenlos wenn man der Möglichkeit beraubt wird das entsprechend sauber anzupassen.

Sobald ich die IP auf 172.16.4.0 ändere, erreiche ich Google nicht mehr.

Krank ! Der Grund dürfte vermutlich sein das in der Firmware nur die Default 10.8.0.0 über die interne IP Adress Translation (NAT) ins Internet kommt. Ändert man das verweigert vermutlich der NAT Prozess das NATing. Totaler Mist und ein Indiz dafür bei VPNs auf etwas Vernünftiges zu setzen.

Setze ich Clients will use the VPN to access auf Internet only dann verschwindet die Route ins 2er Netz. Traffic geht komplett über den Tunnel und ich kann andere Clients nur über die VPN-IP erreichen, könnte ich mit leben aber am liebsten wäre die lokale 2er IP wenn ich im VPN bin.

Vielen Dank nochmal für eure Unterstützung.

Läuft inzwischen soweit wie ich es möchte, man kann beim AC86U im persistenten Speicher /jffs scripte ausführen und so auch custom configs einspielen, wenn der Router/Services gestartet werden. Damit war es mir dann möglich den Server entsprechend zu konfigurieren und das Thema, dass ich die Clients mit ihrer lokalen Adresse ansprechen wollte, habe ich mit einem DNSMasq erledigt - vielleicht nicht die schönste Lösung, aber hat auf anhieb funktioniert.

Ein Thema bleibt noch offen, es muss ein Service über einen DynDns erreichbar sein. Hierfür habe ich an der Fritzbox einen Port geöffnet und weitergeleitet so wie ich es auch mit dem OpenVPN Port gemacht habe, aber ich erreiche den Service einfach nicht.

Fritzbox -> Weiterleitung über WAN Port von AC86U -> wird Forwarded an 8080
dyndns:34676 -> 192.168.1.253:34676 = 192.168.2.1:34676 -> 192.168.2.50:34676 -> 192.168.2.50:8080

Mit dem 1194 Port von OpenVPN geht das ganze ohne Probleme. Außerdem komme ich vom 1er Netz (Fritz) über 192.168.1.253:34676 auf den Service, sieht für mich so aus als ob die Fritze den Port nicht aufmacht, wobei ein traceroute -T -p 34676 dyndns.net durchläuft. Hast mir ein Tipp?

Nimm einen Wireshark und versuche den Verdächtigen zu identifizieren. Dem Wireshark Rechner die 192.168.1.253 geben und den AC86U temporär abklemmen und dann sniffern auf TCP oder UDP 34676. Leider hast du nicht definiert ob du TCP oder UDP Port 34676 meinst.

Die FritzBox blockt das Port Forwarding nur wenn man Ports nutzt die sie auch selber nutzt.
Es ist auch wenig intelligent bei Port Verschleierung offizielle IANA Ports zu nutzen.
Sinnvoll sind hier immer die dafür vorgesehene freien Ephemeral Ports 49152 bis 65535 !
Wenn du TCP 54676 nehmen würdes gehen die vermutlich problemlos durch die FB.
Der Wireshark wird dir das aber letztlich wasserdicht zeigen.

Ok habe einen anderen Port verwendet und mir das mal wie beschrieben angeschaut, die Fritz macht scheinbar den Port auf.

Dann verstehe ich nicht warum ich aus dem 1er Netz über den Port TCP 49760 auf den Service im 2er Netz mit TCP 8080 komme, aber nicht wenn ich von außen darauf zugreifen will. Weil die Weiterleitung funktioniert ja irgendwie teilweise zumindest ^^

aber nicht wenn ich von außen darauf zugreifen will.

Das ist auch unverständlich und ganz sicher nicht normal !
Du musst rausfinden WER der Verursacher dafür ist. Es kann also nur am Port Forwarding / Translation entweder der FritzBox oder das danach kaskadierten AC68U liegen.
Genau DAS gilt es mit Hilfe des Wiresharks herauszufinden. Dazu geht man intelligent und schrittweise vor:
Erstmal von einem PC im 1er Koppelnetz das PFW über den AC68U testen ob Frames am Host im 2er Netz ankommen. Der Wireshark ersetzt temporär den 2er Host.
Dann klemmt man den Wireshark mit der WAN IP des AC68U temporär ins 1er Netz und checkt das PFW für die FritzBox.
Wenn man dann weiss WER der Verursacher ist geht man dann dort zielgerichtet ins Eingemachte.
Muss man dir als Netzwerk Profi aber sicher in einem Administrator Forum nicht alles einzeln erklären, oder ?!

Danke für deinen Support, wie bereits mehrfach erwähnt bin ich kein Profi, aber ich stelle meine Fragen in einem Profi Forum, weil man hier gute Antworten und Hinweise bekommt, sodass man das Problem entweder selbst lösen kann oder jemand eine Lösung kennt.

Nichts für ungut, aber die subtilen Anspielungen sind angekommen. Deine Definition von Intelligenz ist mir nicht geläufig. Ich Frage lieber jemand der Ahnung hat als meine Zeit ewig mit Suchen zu verschwenden. Ist aus meiner Sicht viel wirtschaftlicher als jede Lösung neu zu entdecken (Rad erfinden undso), wenn es jemand schon mal gelöst hat.

Tut mir Leid, wenn ich das Administrator Forum missbraucht habe für ein Amateur-Problem.

Edit:
Konnte das Problem nun identifizieren, das Gerät das den Service bereitstellt hängt im VPN und die Ports werden natürlich nicht an den VPN Client weitergeleitet. Macht man sowas - Ports an VPN Client durchleiten?

hier gute Antworten und Hinweise bekommt, sodass man das Problem entweder selbst lösen kann

Genau deshalb ja die oben beschrieben Hilfen das schrittweise mit dem Wireshark zu klären !

aber die subtilen Anspielungen sind angekommen

Ooops...da siehst du vermutlich etwas was da nicht ist. WO sollen diese denn sein in der o.a. Hilfestellung ???
Nur die Hilfe zur Ursachenfindung war die Intention dir da unter die Arme zu greifen damit man zielgerichtet suchen und den Fehler fixen kann.
Aber leider war das für dich dann wohl der falsche Ansatz ?! Sorry dann für die Verwirrung. Kommt nicht wieder vor und ich bin dann raus hier aus dem Case !

gelöst Frage Linux Linux Netzwerk

Mehr von bugzzz

OpenVPN Client kann Namen nicht auflösenbugzzz - 26 Kommentare

Fritz!Box VPN zwischen 2 Boxen - bestimmter Rechner nicht erreichbarbugzzz - 14 Kommentare

VPN-Verbindung - Client über WS12 L2TP zu externem L2TP VPN-Serverbugzzz - 46 Kommentare

WS12 als VPN-Server L2TP PSK über Netzwerk I.O. über Internet Fehler 789bugzzz - 14 Kommentare

Heiß diskutiert