Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Frage: Wie funktioniert Forwarding einzelner UDP Ports aus dem Internet in eine VM?
#1
Liebe Kenner der Materie,

seit zwei Wochen versuche ich eine Virtuelle Maschine mit OpenSim ans Laufen zu kriegen, verzweifele aber an den Portregeln. Jede Fundstelle im Internet treibt eine andere Sau durchs Dorf, aber nix geht davon bisher. Fehlermeldung: "No route to host".

Das Problem sind die UDP Ports. Mit TCP funktioniert es problemlos. Wer kennt sich mit den benötigten Regeln aus und hat vielleicht Tipps? Die Syntax zum Einzufügen "beliebiger" Regeln denke ich inzwischen drauf zu haben ... deshalb zeige ich hier nur die Regeln und nicht die Kommandos zur Erstellung derselben.

Hier die aus meiner Sicht plausibelsten Regeln. "virbr0" ist die virtuelle Ethernetkarte, "192.168.122.42" die zugehörige IP. Ich habe hier jeweils Zeilen "----- automatisch gefüllt ------" eingefügt. Darüber sind von mir selbst gemachte Regeln, die Regeln darunter kann ich nicht beeinflussen. (Meine gewöhnliche Firewall ist hier aus.)

Code:
Chain PREROUTING (policy ACCEPT 69 packets, 4298 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            1.2.3.4           udp dpt:9012 to:192.168.122.42:9012
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            1.2.3.4           udp dpt:9011 to:192.168.122.42:9011
    8   480 DNAT       tcp  --  *      *       0.0.0.0/0            1.2.3.4           tcp dpt:9010 to:192.168.122.42:9010
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            1.2.3.4           tcp dpt:22 to:192.168.122.42:22
---- automatisch gefüllt ------
Code:
Chain POSTROUTING (policy ACCEPT 36 packets, 2568 bytes)
pkts bytes target     prot opt in     out     source               destination        
---- automatisch gefüllt ------
    0     0 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24        
    0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255    
   15   900 MASQUERADE tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24   masq ports: 1024-65535
    0     0 MASQUERADE udp  --  *      *       192.168.122.0/24    !192.168.122.0/24   masq ports: 1024-65535
    0     0 MASQUERADE all  --  *      *       192.168.122.0/24    !192.168.122.0/24
Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            192.168.122.42     udp dpt:9012 ctstate NEW
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            192.168.122.42     udp dpt:9011 ctstate NEW
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            192.168.122.42     tcp dpt:9010 ctstate NEW
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            192.168.122.42     tcp dpt:22 ctstate NEW
---- automatisch gefüllt ------
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24   ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0          reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0          reject-with icmp-port-unreachable
Code:
Chain INPUT (policy ACCEPT 83 packets, 9815 bytes)
pkts bytes target     prot opt in     out     source               destination
---- automatisch gefüllt ------
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0          udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0          tcp dpt:53
    1   328 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0          udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0          tcp dpt:67
Code:
Chain OUTPUT (policy ACCEPT 81 packets, 5899 bytes)
pkts bytes target     prot opt in     out     source               destination        
---- automatisch gefüllt ------
    1   328 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0          udp dpt:68

(INPUT und OUTPUT sollten nicht relevant sein, weil (hier zum Üben) die Default Policy ACCEPT gilt und automatisch nur weitere ACCEPT Regeln eingefügt wurden.)

Hinweg (reinwärts), wie ich ihn verstehe...

PREROUTING: Wenn das Paket von irgendwoher kommt und an meine externe IP (hier 1.2.3.4) geschickt wird, dann werden die vier Ports 22, 9010, 9011 und 9012 auf die interne IP (192.168.122.42) umgeleitet.

FORWARD: Kommt irgendeine neue Verbindung an, die zur internen IP-Adresse auf virbr0 geschickt werden soll, wird sie im Falle der vier expliziten Ports weitergeleitet. Für bereits bestehende Verbindungen wurden bereits automatisch Umleitungen gesetzt.

POSTROUTING: Keine Regel zieht für die vier Ports.

Rückweg (rauswärts), wie ich ihn verstehe...

PREROUTING: Keine Regel zieht für die vier Ports.

FORWARD: bereits automatisch wird alles, was von virbr0 aus dem Adressband 192.168.122.0/24 kommt, nach überall hin weitergeleitet.

POSTROUTING: Für alles, was aus dem IP-Band 192.168.122.0/24 kommt und nicht (deshalb "!" ) ins selbe IP-Band weiter soll bekommt bereits automatisch per MASQUERADING als Absender die externe IP-Adresse verpasst.

Auffälligkeiten:
- Die FORWARD Regeln haben kein einziges Byte Daten erfasst, das gehört aber wohl so: Entfernen der Forward-Regeln gibt "Connection refused".
- Die PREROUTING und POSTROUTING Regeln haben Datenverkehr auf TCP erfasst, aber keinen auf UDP.

Viele Grüße,
Mareta
Zitieren
#2
Hier noch eine Variante mit diversen Regeln, die ich persönlich für überflüssig halte. In vielen Internetquellen ging es aber in die Richtung, deshalb möchte ich diesen Versuch auch protokollieren. PREROUTING und FORWARD sind unverändert gegenüber dem letzten Beitrag.

Fehlermeldung weiterhin "No route to host".

Code:
Chain INPUT (policy ACCEPT 44 packets, 4025 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9010
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:9011
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:9012
---- automatisch gefüllt ------
   90  6424 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    3   984 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
Code:
Chain OUTPUT (policy ACCEPT 83 packets, 21132 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:9010
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:9011
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:9012
---- automatisch gefüllt ------
    3   984 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
Code:
Chain POSTROUTING (policy ACCEPT 1 packets, 328 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 SNAT       udp  --  *      *       192.168.122.42      !192.168.122.42       udp spt:9012 to:1.2.3.4:9012
    0     0 SNAT       udp  --  *      *       192.168.122.42      !192.168.122.42       udp spt:9011 to:1.2.3.4:9011
    0     0 SNAT       tcp  --  *      *       192.168.122.42      !192.168.122.42       tcp spt:9010 to:1.2.3.4:9010
    0     0 SNAT       tcp  --  *      *       192.168.122.42      !192.168.122.42       tcp spt:22 to:1.2.3.4:12345
---- automatisch gefüllt ------
    0     0 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24        
    0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255    
   30  1800 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24
Zitieren
#3
Hallo Freaky,

brctl show virbr0 =>

Code:
bridge name   bridge id           STP enabled   interfaces
virbr0        8000.525400a6523e   yes           virbr0-nic
                                                 vnet0

EDIT: Ich baue mein System mal auf den Zustand vom ersten Beitrag zurück, als reproduzierbare Ausgangsbasis.

Grüße,
Mareta
Zitieren
#4
Heißt das, ich sollte abbrechen? Dann versenke ich wohl zwei Wochen Arbeit... Sad
Wäre echt ärgerlich so kurz vor Schluss, OpenSim läuft, meldet sich brav bei den Nachbarregionen an, nur kommt niemand drauf.

EDIT: Rest gelöscht, liest sich zu depri.
Zitieren
#5
Was hältst Du von so einer Regel, ganz am Anfang? Beispiel nur für einen Port, Das wäre dann ohne Conntrack, und der Rückweg über Masquerading. Was meine VM noch an Regeln reinwirft, habe ich oben komplett wiedergegeben. Meine Regeln habe ich oben vor die "automatischen" Regeln gesetzt, insbesondere bei FORWARD machen die Automatikregeln am Ende zu.

iptables -t nat -A PREROUTING -d 11.22.33.44 -p udp -m udp --dport 9011 -j DNAT --to-destination 192.168.122.42
iptables -I FORWARD -i eth0 -d 192.168.122.42 -p udp -m udp --dport 9011 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Frage: Wenn das die einzigen Regeln wären, was würde noch fehlen? Der Autor dieses Regelsatzes behauptet, dass es bei ihm läuft.

("Auf die Schnelle" ist nach zwei Wochen Googeln bis tief in die Nacht eher relativ meinerseits.)
Zitieren
#6
Ich habe das Shellscript umprogrammiert, mit dem Regelsatz aus dem letzten Beitrag "No route to host".

EDIT: Zu meiner VM Installation: Ich habe das Paket aus KVM, QEMU und virsh installiert. Der Teil für den Host ist schon im Hyperweb Wiki versteckt: hyperweb.eu/Centos_7_VM/KVM_Host

Man sieht schön, dass über "eigenen" Regeln für TCP und Masquerading gut Traffic ist, auch von OpenSim aus (Port 9010). Nur auf den "eigenen" UDP Regeln ist tote Hose. Allerdings läuft irgendwas von der QEMU Verwaltung rechnerintern durchaus über UDP, wie man an dem Traffich auf den automatisch angelegten Regeln sieht.

Code:
Chain PREROUTING (policy ACCEPT 74 packets, 4760 bytes)
pkts bytes target     prot opt in     out     source               destination        
    1    60 DNAT       tcp  --  *      *       0.0.0.0/0            11.22.33.44         tcp dpt:12345 to:192.168.122.42:22
   16   960 DNAT       tcp  --  *      *       0.0.0.0/0            11.22.33.44         tcp dpt:9010 to:192.168.122.42:9010
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            11.22.33.44         udp dpt:9011 to:192.168.122.42:9011
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            11.22.33.44         udp dpt:9012 to:192.168.122.42:9012

Chain POSTROUTING (policy ACCEPT 18 packets, 1348 bytes)
pkts bytes target     prot opt in     out     source               destination        
   46  3019 MASQUERADE  all  --  *     eth0    0.0.0.0/0            0.0.0.0/0          
    0     0 RETURN      all  --  *     *       192.168.122.0/24     224.0.0.0/24        
    0     0 RETURN      all  --  *     *       192.168.122.0/24     255.255.255.255    
    0     0 MASQUERADE  tcp  --  *     *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
    0     0 MASQUERADE  udp  --  *     *       192.168.122.0/24    !192.168.122.0/24    masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *     *       192.168.122.0/24    !192.168.122.0/24    

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            192.168.122.42      udp dpt:9012
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            192.168.122.42      udp dpt:9011
   16   960 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            192.168.122.42      tcp dpt:9010
   63  7397 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            192.168.122.42      tcp dpt:22
  141 36891 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24    ctstate RELATED,ESTABLISHED
  267 76097 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
Zitieren
#7
Hier jetzt ein Regelsatz mit POSTROUTING ohne Masquerade (zumindest bezüglich der vier betrachteten Ports). Einfach auch, damit ich das später selber wiederfinde ... habe so viele verschiedene Entwürfe inzwischen auf dem Rechner.

iptables -t nat -I POSTROUTING -s 192.168.122.42 ! -d 192.168.122.42 -p udp -m udp --sport 9011 -j SNAT --to 11.22.33.44:9011

Ich habe das so aufgesetzt, dass es (wie ich es verstehe) immer wirkt, wenn die Quelle auf IP 192.168.122.42 unterwegs ist und das Ziel nicht auf der selben IP liegt.

Code:
Chain POSTROUTING (policy ACCEPT 32 packets, 2328 bytes)
pkts bytes target     prot opt in     out     source               destination        
    0     0 SNAT       udp  --  *      *       192.168.122.42      !192.168.122.42       udp spt:9012 to:11.22.33.44:9012
    0     0 SNAT       udp  --  *      *       192.168.122.42      !192.168.122.42       udp spt:9011 to:11.22.33.44:9011
    0     0 SNAT       tcp  --  *      *       192.168.122.42      !192.168.122.42       tcp spt:9010 to:11.22.33.44:9010
    0     0 SNAT       tcp  --  *      *       192.168.122.42      !192.168.122.42       tcp spt:22 to:11.22.33.44:12345
    0     0 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24        
    0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255    
   15   900 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
    0     0 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24
Zitieren
#8
Gelöst! Smile

Vielen Dank Freaky nochmals für Deine mehrstündige Hilfe. Das Internet ist so voll von fehlerhaften Rezepten, und ich hatte eben an mehreren Stellen gleichzeitig Fehler drin.

Der letzte Fehler war, dass die Centos 7 Minimalinstallation (im Gegensatz zu Ubuntu) bereits unglaublich viele Firewallregeln enthält. Temporär habe ich jetzt einfach mal auf der Virtuellen Maschine "iptables -F" eingetippt. Das hat zwar nur bedingt aufgeräumt, aber die Feinarbeit kriege ich nun alleine in Ruhe hin.

(Erstmal verschwindet Ko San Ti also nochmal, wenn um 6 Uhr der Rechner bootet ... ist noch nichts gespeichert.)

Liebe Grüße,
Mareta
Zitieren
#9
Will nicht weiter stören,..aber ein wirklich toller Thread. Smile
Zitieren
#10
Der Vollständigkeit halber folgt hier noch, wie ich schließlich im Guest die Ports geöffnet habe. (Das ist die Behebung des zweiten Fehlers.)

Im Gegensatz zu Ubuntu hat Centos 7 bereits in der Minimalinstallation eine Firewall mit ziemlich vielen Regelsätzen (Chains) aufgebaut. Da mein Guest eh nur von den wenigen Ports aus erreichbar ist, die ich explizit umgeleitet habe, deaktiviere ich die Firewall.

Damit ein rudimentärer Regelsatz existiert, installiere ich als Ersatz das bekannte "iptables" und aktiviere dieses statt "firewalld". Achtung: Im Gegensatz zu den vorherigen Beiträgen geht es hier um Konfiguration auf der Virtuellen Maschine, nicht um die iptables Regeln auf dem Host!

Code:
yum install iptables-services
systemctl disable firewalld
systemctl mask firewalld
systemctl enable iptables

Nach einem Reboot kann mit dem Kommando "iptables -n -L -v" beobachtet werden, dass QEMU schon ein paar Regeln eingetragen hat, die für die Kommunikation zwischen Guest und Host notwendig sind. Leider betrifft dies auch wieder ein "REJECT all" in der INPUT Chain. Also erlauben wir als erste Regel alles. Dann ist egal, was später noch verboten würde (wird ignoriert).

Code:
iptables -I INPUT -p all -j ACCEPT
iptables-save > /etc/sysconfig/iptables

Und schwupps, sofort taucht meine liebe Insel wieder aus dem Meer auf! Shy
Liebe Grüße,
Mareta
Zitieren


Möglicherweise verwandte Themen…
Thema Verfasser Antworten Ansichten Letzter Beitrag
  Xubuntu eine Alternative? LyAvain 9 14.892 16.02.2012, 16:21
Letzter Beitrag: Bogus Curry

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste