feitlinger
Anmeldungsdatum: 11. August 2015
Beiträge: Zähle...
|
Hallo zusammen, ich hoffe sehr, dass ich bei Euch Hilfe für mein Problem finde, weil ich nun schon etliche erfolglose Stunde hierfür investiert habe. Zu meinem Setup:
Ich betreibe zuhause einen HP Microserver G8 mit ESXi als Hypervisor. Die für mein Problem relevanten VMs sind 1x Windows Server 2012 R2 und 1x Ubuntu Server 14.04.
Auf der Ubuntu Server VM läuft OpenVPN, welches sich als client mit meinem Uni-Netzwerk verbindet. IP-Forwarding ist auf der Ubuntu-VM aktiviert, damit ich mit der Windows VM über das Gateway der Ubuntu VM, also über das Uni-Netzwerk, surfen kann. Mein Problem ist nun folgendes:
Auf der Windows VM läuft Plex Media Server, welcher auf den Port 32400 hört. Um auch von außerhalb (WAN) zugriff auf Plex zu haben müsste ich bei meinem Setup auf dem OpenVPN Server der Uni den Port 32400 an die Ubuntu-VM weiterleiten, was leider nicht möglich ist.
Da meine Windows VM ja über das Gateway der Ubuntu Server VM (openvpn client) "surft" würde ich nun gerne dem Plex Media Server beibringen, dass er auf die Portweiterleitung meines ISP "hört". Bei meiner Fritzbox habe ich nun Port 32400 an die ubuntu-VM weitergeleitet und folgende IPtables-Einstellungen gemacht, damit alle Pakete von Port 32400 an die Windows VM weitergeleitet werden: | iptables -A FORWARD -m state -p tcp -d 192.168.178.4 --dport 32400 --state
NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 32400 -j DNAT --to-destination
192.168.178.4:32400
|
Mit diesen Einstellungen konnte ich schonmal erfolgreich eingehende Pakete an die Windows VM (Plex) weiterreichen. Zu erwähnen ist vielleicht noch, dass 192.168.178.4 die LAN-IP der Windows VM ist. Die der Fritzbox ist 192.168.178.1 und die der Ubuntu-VM 192.168.178.7. Probleme habe ich aber beim Routing ausgehender Pakete von der Windows VM über das Ubuntu-Gateway zur Fritzbox. Meine Ideal-Vorstellung wäre, dass die aktive OpenVPN-Verbindung auf der Ubuntu-VM alle Pakete über tun0 verschickt, bis eben auf die von Port 32400, die von der Windows VM kommen. Diese Pakete sollen über eth0 an die Fritzbox weitergeleitet werden.
Folgenden Ansatz habe ich bereits versucht, führte aber noch nicht zum Erfolg: | ip route add default table 100 via [Fritzbox LAN-IP]
ip rule add fwmark 1 table 100
ip route flush cache
iptables -t mangle -I PREROUTING -p tcp --dport 32400 -j MARK --set-mark 1
|
Meine Fähigkeiten bez. Linux-Firewall insbesondere mit IPtables sind begrenzt. Verstehen tu ich die Regeln, aber selber aufstellen ist was anderes 😉
Für Hilfe jeglicher Art wäre ich wirklich sehr dankbar, weil mir dieses Problem gerade jeglichen Nerv raubt. Sehr gerne würde ich dem Problemlöser einen kleinen Obolus zukommen lassen :pray Vielen Dank
Feitlinger P.S.: Ich vergaß zu erwähnen, dass ich noch folgende IPtables Regeln vor den oben genannten ausführe, um traffic nur über tun0 zu erlauben (also für clients, die über das Ubuntu-Gateway surfen) | iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o tun+ -j MASQUERADE
iptables -P FORWARD DROP
iptables -A FORWARD -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
|
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
feitlinger schrieb:
| iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o tun+ -j MASQUERADE
iptables -P FORWARD DROP
iptables -A FORWARD -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
|
Das Problem ist die Forward-Drop Regel. Wenn du sie auf Accept setzt müsste es gehen. Die anderen beiden Regeln sind ohnehin unsinnig wenn ich davon ausgehen kann, dass der Open-VPN-Tunnel (10.x.x.x) im Ubuntu-Server endet. (Also andere Maschinen nicht an dieses Subnetz angeschlossen sind.)
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
Hallo chilidude, vielen Dank für Deine Antwort. Also ich habe jetzt alle iptables Regeln auf der Ubuntu-Server-VM (wo openvpn läuft) gelöscht und dann folgende, in der angegebenen Reihenfolge, eingetragen: 1
2
3
4
5
6
7
8
9
10
11
12
13 | iptables -A FORWARD -m state -p tcp -d 192.168.178.4 --dport 32400 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 32400 -j DNAT --to-destination 192.168.178.4:32400
echo "10 plex" >> /etc/iproute2/rt_tables
ip route add 192.168.178.1 dev eth0 table plex
ip route add default dev eth0 via 192.168.178.1 src 192.168.178.7 table plex
iptables -t mangle -I PREROUTING -i eth0 -p tcp -m tcp --dport 32400 -j MARK --set-mark 10
ip rule add fwmark 0x10 table plex
|
wenn ich die Regeln so eingebe, werden eingehende und ausgehende Pakete von/zu 192.168.178.1 (fritzbox) über 192.168.178.7 (ubuntu-server-openvpn) zu/von 192.168.178.4 (windows-vm-plex) geschickt. Sprich, das klappt.
Sobald ich aber auf der ubuntu-vm den openvpn-client starte und mich mit dem uni-netzwerk verbinde, funktioniert das obige leider nicht mehr. Wo genau das Problem in der Kette ist, kann ich leider überhaupt nicht sagen...da ist mein Latein in Sachen IPtables zu Ende 😉 Falls Du, chilidude, oder jemand anderes noch eine zündende Idee hat, wäre ich sehr sehr dankbar! Viele Grüße und schönen Abend.
Feitlinger
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
Naja, dann müsstest du dir einfach mal die Routing-Tabelle vor und nach dem Start des Open-Vpn-Clients anschauen.
ip route Ausserdem wären noch die folgenden Ausgaben (einmalig) hilfreich: ip rule
ip route show table plex
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
Besten Dank weiterhin für Deine Hilfe Hier die Ausgabe von
VOR Starten von OpenVPN
| default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.7
|
NACH Starten der VPN-Verbindung: | 0.0.0.0/1 via 10.4.xxx.xx dev tun0
default via 192.168.178.1 dev eth0
10.4.xxx.x via 10.4.xxx.xx dev tun0
10.4.xxx.xx dev tun0 proto kernel scope link src 10.4.xxx.xx
128.0.0.0/1 via 10.4.xxx.xx dev tun0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.7
212.xxx.xxx.xxx via 192.168.178.1 dev eth0
|
–-
spuckt mir folgendes aus | 0: from all lookup local
32765: from all fwmark 0x10 lookup plex
32766: from all lookup main
32767: from all lookup default
|
und spuckt folgendes aus: | default via 192.168.178.1 dev eth0 src 192.168.178.7
192.168.178.1 dev eth0 scope link
|
Viele Grüße aus dem heißen München Feitlinger
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
feitlinger schrieb:
Also wenn die Windows-Vm im selben Subnetz liegt wie die Ubuntu-Vm und beide dem Router bekannt sind, dann verstehe ich nicht wozu du die DNAT-Regeln brauchst? Ich verstehe dass du den Inhalt der Windows-Vm teilweise über Ubuntu laufen lässt um den VPN-Tunnel auszunützen aber warum routest du dann den plex-Service auch über Ubuntu wenn er transparent ist?
Besten Dank weiterhin für Deine Hilfe Hier die Ausgabe von
VOR Starten von OpenVPN
| default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.7
|
NACH Starten der VPN-Verbindung: | 0.0.0.0/1 via 10.4.xxx.xx dev tun0
default via 192.168.178.1 dev eth0
10.4.xxx.x via 10.4.xxx.xx dev tun0
10.4.xxx.xx dev tun0 proto kernel scope link src 10.4.xxx.xx
128.0.0.0/1 via 10.4.xxx.xx dev tun0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.7
212.xxx.xxx.xxx via 192.168.178.1 dev eth0
|
0.0.0.0/1 via 10.4.xxx.xx dev tun0 128.0.0.0/1 via 10.4.xxx.xx dev tun0 Ich erkläre dir jetztmal was passiert. Die beiden gelb markierten Einträge überschreiben den Default-Eintrag ("default via 192.168.178.1 dev eth0") vollständig und zwingen jedes Datenpaket mit Ausnahme von "192.168.178.0/24" und "212.xxx.xxx.xxx" durch den Tunnel. Hättest du jetzt eine statische Auswärts-IP könntest du sie direkt nach demselben Schema dort eintragen. Da das vermutlich nicht der Fall ist und nur nach Port entschieden werden kann, musst du den Weg über einen zweiten Tabelleneintrag (in deinem Fall "plex") gehen. Da das nicht funktioniert vermute ich das Problem dort.
Mir ist z.B. nicht klar, ob es sich bei Port 32400 um den Quell- oder Zielport handelt, da ich den Service überhaupt nicht kenne. Ausserdem scheinen noch adere Ports eine Rolle zu spielen. Siehe hier: https://support.plex.tv/hc/en-us/articles/201543147-What-network-ports-do-I-need-to-allow-through-my-firewall- Unabhängig davon bleibt die obige Frage, warum du den Service überhaupt durch Ubuntu routest, wenn die Windows-VM direkt mit dem Router kommunizieren könnte.
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
Vielen Dank für die Erklärung der Routen.
Klingt jedenfalls für mich plausibel, wieso das nicht so funktionieren kann. Mir ist bewusst, dass die Windows VM ja der Fritzbox bekannt ist. Da ich in der Windows VM aber als Standard-Gateway hier die IP der Ubuntu-VPN gewählt habe, müsste ich auch hier Routing-Regeln anwenden, damit ausgehende Plex-Pakete nicht über das Gateway der Ubuntu-VM, sondern über die Fritzbox laufen. Leider habe ich bei Windows überhaupt keine Ahnung wie ich das bewerkstellige weswegen ich den "Umweg" über das Ubuntu-Gateway machen wollte. Mittlerweile merke ich aber, dass dieses Vorhaben wohl doch deutlich komplizierter ist. Ich denke, ich müsste mich mal bez. RRAS (Routing and Remote Access Service) auf Windows einlesen... Viele Grüße
Feitlinger
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
Du brauchst bloss folgenden Befehl auf der Ubuntumaschine zu starten: [sudo] tcpdump -i eth0 -n Dann siehst du welche Ports von wo kommen und nach wohin gehen (bzw nicht gehen). Die schaltest du dann über Tabelle "plex".
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
also ich hab den Befehl jetzt mal ohne VPN ausgeführt. Da werden alle Pakete von 192.168.178.4:32400 (windows-vm) korrekt über die Fritzbox geschickt. Bei aktiviertem VPN gibt es keinerlei Nachweise von Port 32400 durch tcpdump zu sehen. ☹
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
Wäre ja mal interessant gewesen, wenn du jeweils 10 Zeilen Ausgabe gepostet hättest. Einmal mit und einmal ohne VPN.
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
Welche Packete sind denn von Interesse? Ich hab jetzt einfach mal eine Auswahl von den Paketen der Windows-VM (192.168.178.4) gemacht. Interessant ist vielleicht zu erwähnen, dass Plex wirklich auf mehreren Ports hört, was auch der folgende Auszug und dieser link http://jack-brennan.com/configure-iptables-to-allow-plex-media-server/ bestätigt. ohne VPN 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | 16:46:25.833711 IP 192.168.178.4.58208 > 192.168.178.255.32412: UDP, length 21
16:46:25.833761 IP 192.168.178.4.58210 > 192.168.178.255.32414: UDP, length 21
16:46:30.833373 IP 192.168.178.4.58208 > 192.168.178.255.32412: UDP, length 21
16:46:30.833700 IP 192.168.178.4.58210 > 192.168.178.255.32414: UDP, length 21
16:46:31.877112 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 655291901, win 515, length 0
16:46:31.877180 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 1, win 515, length 0
16:47:11.877408 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 137, win 514, length 0
16:47:11.877472 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 137, win 514, length 0
16:47:45.832584 IP 192.168.178.4.58208 > 192.168.178.255.32412: UDP, length 21
16:47:45.833334 IP 192.168.178.4.58210 > 192.168.178.255.32414: UDP, length 21
16:46:36.616392 ARP, Request who-has 192.168.178.7 (00:0c:29:7b:4b:9e) tell 192.168.178.4, length 46
16:46:36.616433 ARP, Reply 192.168.178.7 is-at 00:0c:29:7b:4b:9e, length 28
16:46:36.887637 ARP, Request who-has 192.168.178.1 tell 192.168.178.7, length 28
16:46:36.887962 ARP, Reply 192.168.178.1 is-at 34:31:c4:62:33:bc, length 46
16:46:37.133871 IP 192.168.178.25.54691 > 192.168.178.255.32414: UDP, length 21
16:46:37.134566 IP 169.254.40.43.60956 > 169.254.255.255.32414: UDP, length 21
|
mit VPN | 16:46:30.833373 IP 192.168.178.4.58208 > 192.168.178.255.32412: UDP, length 21
16:46:30.833700 IP 192.168.178.4.58210 > 192.168.178.255.32414: UDP, length 21
16:46:31.877112 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 655291901, win 515, length 0
16:46:31.877180 IP 192.168.178.4.63342 > 194.109.153.214.443: Flags [.], ack 1, win 515, length 0
16:46:35.832626 IP 192.168.178.4.58208 > 192.168.178.255.32412: UDP, length 21
16:46:35.833403 IP 192.168.178.4.58210 > 192.168.178.255.32414: UDP, length 21
17:01:46.920544 IP 79.202.106.150.56149 > 192.168.178.7.32400: Flags [S], seq 4158078355, win 29200, options [mss 1452,sackOK,TS val 4294879797 ecr 0,nop,wscale 7], length 0
|
nach welchen Paketen soll ich denn genau Ausschau halten?
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
Das ist schon sehr verwirrend. Deine Windows-VM kommuniziert nicht direkt mit der Ubuntu-VM, sondern sendet immer eine Broadcast-Adresse. Das kann so nicht sein. Für mich stellt sich überhaupt die Frage, wie es möglich sein soll, dass die Windows-VM über die Ubuntu-VM als Mittler kommunizieren kann. Dafür ist nämlich ein eigenes Subnetz erforderlich (oder ein extra Dienst.) Router: 192.168.178.1 (Gateway) Windows-Vm: 192.168.178.4 Ubuntu-Vm: 192.168.178.7 Ohne ein extra Subnetz, welches sich von 192.168.178.0/24 unterscheidet und nur die Windows-VM mit der Ubuntu-VM (hier als Gateway) verbindet, ist es nicht möglich von der Windows-VM über die Ubuntu-VM (als Mittler) eine externe Adresse (z.B. 68.17.44.12) zu adressieren.
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
aber wieso funktioniert es dann bei inaktiver VPN-Verbindung? Bevor ich dich mit meinen Fragen zu Tode löcher 😉, wollt ich einfach mal direkt fragen, ob mein Vorhaben überhaupt ohne allzu großen Aufwand realisierbar ist?! Grundwissen in Sachen Netzwerktechnik habe ich, aber langsam bin ich mit meinem Latein am Ende 😉 Tut mir Leid für meine verspätete Antwort. Ich war über das Wochenende nicht im Lande.
Weiterhin vielen Dank für deine Anteilnahme...
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
feitlinger schrieb: aber wieso funktioniert es dann bei inaktiver VPN-Verbindung?
Das ist eine berechtigte Frage die ich dir so aus der Ferne auch nicht beantworten kann. Du kannst dich aber schrittweise heranarbeiten wenn du die ensprechenden Befehle verwendest:
ping
tcpdump -i eth0 -n; tcpdump -i tun0 -n # usw.
ip addr add 12.34.56.78/24 dev eth0 # vergibt eine zusätzliche (zweite, dritte, vierte..) adresse (hier 12.34.56.78) auf eth0. die anderen 254 adressen zu diesem sind subnetz sind über eth0 erreichbar
ip route [add | replace] default via 12.34.56.10 # beispiel zum ändern des gateway
man ip # beispiele mit unmengen an optionen
Alternativen zum Lernen und Debuggen sind auch dumpcap, tshark (wireshark), traceroute, tracepath.
Bevor ich dich mit meinen Fragen zu Tode löcher 😉, wollt ich einfach mal direkt fragen, ob mein Vorhaben überhaupt ohne allzu großen Aufwand realisierbar ist?! Grundwissen in Sachen Netzwerktechnik habe ich, aber langsam bin ich mit meinem Latein am Ende 😉
Realisierbar ist es auf jeden Fall aber es erfordert viel Netzwerk-Praxis zur Verständnisweise. Netzwerken ist wirklich eine komplexe Angelegenheit die ohne Praxis nicht zum Erfolg führt. Mit deinem Wissen wirst du bestimmt einen Monat brauchen bist du herausgefunden hast, wie was funktioniert und welche Syntax nun was bewirkt. Willst du das Problem lösen musst du dir entweder selbst die Mühe machen und dich einarbeiten oder dir einen Experten vor Ort holen. Aus der Ferne ist das nicht lösbar, es sei denn jemand hat schonmal exakt dein Problem umgesetzt. Wenn du mit Windows-VM über den Open-VPN-Tunnel routen willst, hier nochmal stichpunktartig was du zu tun hast:
auf der windows-vm das gateway (die Default-Route für ausgehende Pakte die nicht zum Subnetzwerk gehören), vormals 192.168.178.1, auf diese Subnetz-IP der Ubuntu-VM setzen. (Das eigentliche Gateway ist die Ubuntu-VM)
der Fritzbox mitteilen, dass dieses Subnetz (auf eth0) existiert oder alternativ auf der Ubuntu-VM ein Source-Nat (masquerade) und zusätzlich auch ein D-Nat (für eingehende Ports) für dieses Subnetz einrichten (nur für den Fall, dass die transparente Umleitung über die Ubuntu-VM funktionieren soll was aber Quatsch ist, da du den Router direkt anweisen kannst diesen Port an Windows-VM-IP weiterzuleiten. Umgekehrt musst du dies der Windows-VM natürlich auch beibringen für diesen Port nicht den Default-Gateway zu benutzen.)
|
feitlinger
(Themenstarter)
Anmeldungsdatum: 11. August 2015
Beiträge: 8
|
Alles klar, vielen herzlichen Dank für die tolle Unterstützung. Dann werd ich mir nun mal Gedanken machen, ob das Aufwand/Nutzen-Verhältnis stimmt und mich dann eventuell mal tiefgründiger mit Netzwerksystemen befassen. Interessant find ich das Thema allemal... Viele Grüße und nochmals ein großes Dankeschön. Feitlinger
|