Umleitung eines PortA von Server A nach Port B-ServerB

F

frannek

Registered User
Hallo zusammen,

ich benötige kurz eine Hilfe in Sachen Umleitung. Da ich sonst immer mit Suse gearbeitet habe und dort im Yast das recht einfach war nun meine Frage zu iptables (womit ich mich noch nie wirklich beschäftigt habe):

Ich möchte von Server A: 85.25.XXX.XXX den Port 80
an Server B: 188.138.XXX.XXX Port 8080

Kann mir da jemand kurz auf die Sprünge helfen? (ja, im Grunde sicher einfach, aber ich brauch sogesehen ein "Template" um das ganze zu verstehen ;-) )

Besten Dank


Frannek
 
Besten Dank - System nun verstanden. Yast war dann eben doch zuu sehr Oberflächlich.
Nachtrag:

Im Grunde funktioniert das und das System habe ich verstanden aber nun habe ich eine anderes Problem:
Bei dem Port handelt es sich um einen Windows Stream. Die Umleitung funktioniert soweit aber der Player selbst wird wieder umgeleitet zu internen IP´s welche sich in einer virtuellen umgebung befinden. Wie kann ich es jetzt schaffen, dass es so aussieht, dass der Server, der Umleitet aussieht, als wäre es der Streamserver?

Nochmal besten Dank
 
Last edited by a moderator:
Was ist ein "Windows Stream"?
Wodurch wird der Player umgeleitet? Durch eine Metainformation im Protokoll? Tja, dann musst Du diese wohl austauschen - auf Layer 3 können durch iptables nun mal keine Layer 5+ Informationen ausgetauscht werden.
 
Okay, das war Bahnhof für mich.

Der Windows Media Stream kommt aus einer virtuellen Windows Umgebung auf einem Debian-System. Dort liegt der Stream auf dem port 8080. Auf Grund der Kompatibilität zu Firewalls (und weil ich gerade diese Recourcen des Port 80 auf dem anderen Server nicht benötige) möchte ich, dass auf dem zweiten Server der Port 80 quasi das macht, was auf dem 8080 anliegt.... nur aber so, als wäre der Port 80 Server der eigentliche Windows Server.

Gehe ich mit dem Player auf dem 8080er Port, funktioniert es... gehe ich auf dem 80er (welche ich ja umleiten möchte), wird der Player zwar umgeleitet, aber zu ganz anderen Ports (dort erscheit im VLC dann 8002).

Die Anfrage geht durch aber die Antwort kommt auf 8002 raus. Die sollte aber bei 80 raus kommen
 
Last edited by a moderator:
Die Anfrage geht durch
Click to expand...

Diesen Schluss ziehst Du aufgrund welcher Beobachtung?

aber die Antwort kommt auf 8002 raus
Click to expand...

Du hast ein Destination-NAT mit IP-Tables gebaut. Wenn ich das Ursprungsposting betrachte dann war da nur Port 80 und 8080 im Spiel. Warum also nun eine "Antwort" von 8002 kommen sollte stelle ich in Frage. Vielmehr vermute ich, dass hier mehr als nur ein Service im Spiel ist, auf 8080 wohl nur das Steuerfile transportiert wird und auf 8002 dann der eigentliche Stream.

Die sollte aber bei 80 raus kommen
Click to expand...

Wenn ich meine Vermutung betreffend mehrerer Services auf diese Frage umlege, dann willst Du offenkundig auf einem Port auf der gleichen IP-Adresse mehrere Services betreiben. Das ist technisch aber recht trickreich und nur in besonderen Fällen möglich. Du kannst entsprechende IPTables Regeln bauen, die so etwas ermöglichen, aber Du brauchst Identifizierungsmerkmale auf Layer 2-4 auf Basis derer IPTables die Datenströme unterscheiden kann.

Warum hängst Du den Windows-Server nicht direkt ins Netz? Hat doch offenkundig eine routbare IP-Adresse. Mir erschließt sich der Grund nicht, diesen hinter einem DNAT zu verstecken.
 
Das Problem ist, dass ich nur zwei physische IP Adressen habe... diese sind aber auf zwei verscheidenen Servern.
Server A CENTOS:
- Webserver (80) / Shoutcast (8000-8020) und eben das ganze andere...
- VMWare mit Windows Server (interne IP 172.16.70.127 -> 8002 ist der HTTP Stream des Windows Media Dienstes). Der Port 8002 wurde per Masquerade dann auf dem port 8080 extern zugänglich gemacht. Dort kommt der Stream auf der eth0 raus.

Server B:
keine Webdienste, Port 80 frei, soll im Moment als Router dienen damit auf Port 80 eben das raus kommt, was auf Server A bei Port 8080 anliegt.

Die 8002 taucht im VLC Player dann auf, wenn ich auf Port 80 zugreife. Er muss demnach ja irgendwie eine Verbindung haben denn sonst wüsste er nicht die interne IP Adresse von Server A.
 
Ich erkenne keinen Zusammenhang mehr zur ursprünglichen Fragestellung - dort waren völlig andere Informationen (IP-Adressen und Ports) angegeben.

Ich erkenne auch keinen Zusammenhang zur Antwort von vorhin, da sprachst Du noch von "Debian mit virtuellem Windows", nun lesen wir CentOS und VMWare. Ist zwar grundsätzlich egal - aber irgendwie kenn ich mich nicht mehr aus, ob wir überhaupt noch von den gleichen Maschinen sprechen oder Du hier kurzerhand zwischen mehreren Szenarien herumspringst.

Ich erkenne weiters keinen Zusammenhang zu den ursprünglich genannten Ports 80->8080, plötzlich schreibst Du, du hättest 8002 per masquerade geforwarded. Was nun? 8080 oder 8002? Ist dieser Datenstrom auf 8002 nun ein zusätzlicher zu 8080 oder ist es der einzige?
 
Debian hatte ich mal..sorry...

Nochmal zurück auf Anfang:

Centos beinhaltet eine virtuelle umgebung auf dem ein Windows Swerver läuft. Der wird benötigt um einen windows media stream zu senden. Damit die Ports eben erreichbar sind, wurde eine Masquerade in diese Virtuelle Umgebung gelegt. Am eth0 der Hardware wird der Port 8080 umgeleitet auf den port 8002 in der VM Ware. Dort läuft der HTTP Stream vom Windows Media Dienst.

Wenn ich mit VLC auf den 8080er Port gehe, spielt die Musik ohne Probleme.

Da ich aber nun den Stream auf nem 80er Port haben möchte, möchte ich den zweiten Server auf den Port 8080 zugreifen lassen und der gibt das auf port 80 raus(ja, Bandbreite ist alles im Leben - aber gerade nicht relevant)

Und genau da liegt der Haken. Wenn ich den 80er Port dann mit VLC aufrufe, dann kommt in der VLC Playliste eine weiterleitung zu dem Server A auf dem 8002er Port und ein weiterer mit der INTERNEN IP und ebenfalls der 8002er Port.


Kurz: Direkt auf server A 8080er geht Musik - über Server B geht nichts sondern wird dann im player umgeleitet auf 8002er der externen IP von server A und die Interne IP des VM (windows) mit port 8002.
 
Sorry, aber du schreibst wirres Zeug.

Am eth0 der Hardware wird der Port 8080 umgeleitet auf den port 8002 in der VM Ware.
Click to expand...

Was nun? Vorhin wars noch Port 80 den Du auf Port 8080 der Windows-VM umleiten wolltest? Gut, also nun 8080 der physischen (CentOS?) Maschine auf 8002 in der Windows-VM.

Wenn ich mit VLC auf den 8080er Port gehe, spielt die Musik ohne Probleme.
Click to expand...

Auf welcher Maschine? 8080 Muss demnach die physische CentOS Maschine sein, denn der MediaDienst läuft ja - wie Du uns gerade noch einmal erklärt hast - auf der Windows-Maschine nicht auf Port 8080 sondern 8002.

Da ich aber nun den Stream auf nem 80er Port haben möchte
Click to expand...

Möchtest Du? Grade oben wolltest Du ihn auf Port 8080 der physischen Maschine haben. Gut - ist auch egal ob nun 80 oder 8080. Du willst also entweder 80 oder 8080 auf der physischen CentOS Maschine auf Port 8002 der WindowsVM leiten.

Wenn ich den 80er Port dann mit VLC aufrufe, dann kommt in der VLC Playliste eine weiterleitung zu dem Server A auf dem 8002er Port und ein weiterer mit der INTERNEN IP und ebenfalls der 8002er Port.
Click to expand...

Server A war - lesen wir nochmals im Posting oben nach - der CentOS (also physische) Server. Das passt ja dann somit. Nur der Port ist falsch. Dann wird wohl im Datenstrom des Streaming Media Dienstes ein Redirect erfolgen.

Ich würde vorschlagen, Du konfigurierst den Windows-Media-Streaming Dienst einfach so, dass er auf Port 80 lauscht, dann musst Du lediglich die IP Adresse auf der CentOS Muttermaschine mittels IPTables umschreiben und nicht den Port - das würde diesen Konflikt, dass im Protokoll offenkundig der Port enthalten ist und daher auf diese Art nicht einfach umgeschrieben werden kann lösen.

Kurz: Direkt auf server A 8080er geht Musik
Click to expand...

Warum ist am "Server A CentOS" auf einmal am 8080er Port ein Dienst? Da wolltest Du doch das Forwarding einrichten? Ich hab das Gefühl auch dieser Post enthält wiederum nicht zusammenpassende Angaben.

Ich lass es mal vorerst mit weiteren Tipps - meine Glaskugel die dein Szenario erraten könnte ist grade auf Urlaub.
 
Ich hab mal ein Bild angefügt.

das mit dem port 80 probier ich mal aus...
 

Attachments

  • stream.jpg
    stream.jpg
    31.2 KB · Views: 152
Ein Bild sagt mehr als Tausend Worte.
Jetzt ergeben einige Deiner Angaben wieder Sinn.

Ich würde statt dem DNAT mit IPTables in diesem Fall dann die Verwendung von rinetd vorschlagen.

Wirf das DNAT daher mit iptables -t nat --flush
 wieder weg, und verwende rinet.

Quell-IP Quell-Port Ziel-IP und Ziel-Port gibst Du in der /etc/rinetd.conf Datei an. rinetd starten, fertig.
 
Wenn inetd auf Deiner CentOS Maschine B nicht installiert ist, und Du es auch nicht nachinstallieren möchtest, sollte das auch mit xinetd klappen.

Neues Konfig-File /etc/xinetd.d/media_forward mit nachfolgendem Inhalt erstellen:
Code: 
service media_forward
{
        disable         = no
        type            = UNLISTED
        socket_type     = stream
        protocol        = tcp
        user            = nobody
        wait            = no
        redirect        = remote_server_IP 8080
        port            = 80
}


Danach xinetd reloaden: /etc/init.d/xinetd reload
 
Ich hab es nun mit der xinet ausprobiert - leider der selbe mist. Den Medienserver habe ich in der virtuellen umgebung nun von 8080 auf 80 umstellen können... es ergibt sich der selbe mist. Ich schreib dir mal eine PN mit dem Link für den Player.
 
You must log in or register to reply here.
Back
Top