4
Masquerading umgehen
Ich habe folgendes Problem:
Möchte einen Cs Server laufen lassen der momentan hinter einem Dlink DI 624+ steht. Da der Router durch sein Masquerading mir alles versaut und alles forwarden und triggern dem logischerweise keine abhilfe schafft will ichs anders probieren.
Meine Vorstellung dabei ist das der CS server vor dem ROuter steht, die Internetverbindung aufbaut und der Router diese so animmt. Ansich ja kein Problem allerdings will ich gleichzeitig das die PCS die hinterm router sind die Firewall und das Masquerading weiter benutzen.
Hab dazu mal eine kleine skizze angehangen.
Der DI-624 hat VPN kann mir das eventuell mit dem cs server helfen? hätte auch kein problem damit wenn der cs server hinter nem Router steht, nur muss der port stimmen und für "fremde" erreichbar sein.
alternativ sollten wir zu keiner Lösung kommen, kennt jemand nen Router der kein masqeurading benutzt?
Möchte einen Cs Server laufen lassen der momentan hinter einem Dlink DI 624+ steht. Da der Router durch sein Masquerading mir alles versaut und alles forwarden und triggern dem logischerweise keine abhilfe schafft will ichs anders probieren.
Meine Vorstellung dabei ist das der CS server vor dem ROuter steht, die Internetverbindung aufbaut und der Router diese so animmt. Ansich ja kein Problem allerdings will ich gleichzeitig das die PCS die hinterm router sind die Firewall und das Masquerading weiter benutzen.
Hab dazu mal eine kleine skizze angehangen.
Der DI-624 hat VPN kann mir das eventuell mit dem cs server helfen? hätte auch kein problem damit wenn der cs server hinter nem Router steht, nur muss der port stimmen und für "fremde" erreichbar sein.
alternativ sollten wir zu keiner Lösung kommen, kennt jemand nen Router der kein masqeurading benutzt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43271
Url: https://administrator.de/contentid/43271
Ausgedruckt am: 08.11.2024 um 13:11 Uhr
4 Kommentare
Neuester Kommentar
Hi,
häng deinen Server einfach in die DMZ des Routers:
http://firewalling.com/dlink/di-624-DMZ.htm
HTH,
Ex
häng deinen Server einfach in die DMZ des Routers:
http://firewalling.com/dlink/di-624-DMZ.htm
HTH,
Ex
hab ich versucht, aber auch das hilft nicht weiter´, leider 
Dann hast du aber anscheinend ein grundlegendes Problem mit deinem Server.
Steht der Server in der DMZ, sind alle darauf laufenden Dienste exponiert, also erreichbar von ausserhalb.
Steht der Server in der DMZ, sind alle darauf laufenden Dienste exponiert, also erreichbar von ausserhalb.
klar ist ja logisch, weiter wird aber das masquerading ausgeführt und die jenigen die versuchen den router von aussen anzupingen können nicht weil der router (masquerading) die packets dropped.
Die Frage ist also wie umgehe ich dieses sche*** Masquerading.
edit:
füge mal eine problembeschreibung aus den FAQs von Cstrike.de, geschrieben von mckenzie ein. Das beschreibts hervorragendend:
Nun kommt der Part mit dieser STEAM-Liste. Aber dazu ganz von vorne:
Euer Server wird gestartet und bringt ein paar Meldungen, was für eine Version er ist, usw.. Irgendwo in diesem Buchstabenverhau kommen ein paar wichtige Zeilen:
Die erste wäre
Connection to Steam servers successful
Diese Meldung sagt Euch, das Euer Server Kontakt zu STEAM und damit zum Internet hat.
Des weiteren kommen dann noch drei Meldung (die IP-Adressen können abweichen):
Adding master server 198.74.32.53:27010
Adding master server 216.52.220.16:27010
Adding master server 198.74.32.52:27010
Und hier passiert's: Euer Server schickt an diese 3 Master-Server ein „Hallo-hier-bin-ich“ Paket. Jetzt wird's ein wenig komplizierter: Dieses Begrüßungs-Paket hat von Eurem Server dessen IP-Adresse und seinen Port mit eingetragen bekommen, also 192.168.0.20:27015. Das Paket wird mit dem UDP-Protokoll verschickt. Der Server weiß, das er dieses Paket z.B. an 198.74.32.53 (den ersten der drei Master-Server) schicken soll, schaut in seiner Routing-Tabelle nach und merkt: das ist nicht im lokalen Netzwerk (192.168.0.XXX) – ich muss dieses Paket an den Router schicken, der weiß schon, wohin damit.
Maskenball: Der Router
Das Paket kommt nun bei Eurem Router an und der tut, was eine „Masquerading Firewall“ nun mal so macht: er setzt Eurem Paket eine Maske auf. Das heißt, er verändert die Quelladresse des Paketes so ab, als ob der Router als Absender dieses Paketes angesehen würde und schickt es weiter ans Internet. Hierbei verändert er aber nicht nur die Adresse, sondern in der Regel auch den Port des Pakets. Die neue Portnummer wird dabei mehr oder minder zufällig vergeben.
Nehmen wir an, das Paket, das von Eurem Server kam (Quelladresse 192.168.0.20:27015), erhält somit nun die Quelladresse 213.100.100.100 und den Quellport 12345. Nach dieser Veränderung schickt Euer Router das Paket ins Internet und merkt sich diese Änderung. Denn falls der angesprochene Server eine Antwort zurückschicken will, müssen bei den Antwortpaketen die Änderungen vom Router genau wieder rückgängig gemacht werden, damit die Pakete im LAN auch den CS-Server erreichen. Das macht der Router automatisch: mit jedem Paket, das Ihr sendet (bewusst oder unbewusst), macht ihr sozusagen eine kleine Tür auf, durch die ausschließlich der angesprochene Server antworten darf.
Die Master-List
Das Begrüßungs-Paket kommt nun nach einer kurzen Reise beim Master-Server an und dieser schaut in den IP-Header des Pakets, woher es denn kommt (Quelladresse und -port) und schreibt diesen in seine Master-List, die eigentliche STEAM-Liste. Bei unserem Beispiel landet in der STEAM-Liste die Info, dass es einen Server gibt, den man unter 213.100.100.100:12345 (die Adresse des Routers!) erreichen kann.
Die Client-Anfrage und der verschwundene Server
Was passiert nun, wenn Ihr in Eurem Client auf „Update“ klickt? Der Client sendet eine Anfrage an STEAM und bekommt auch prompt von einem der Server eine (vorgefilterte) Liste mit IP-Adressen und -Ports von Spiele-Servern zugesandt, die sich am Master-Server gemeldet haben, unter anderem in unserem Beispiel die 213.100.100.100:12345. Es werden keinerlei Informationen wie z.B. über die Anzahl der Spieler oder den eigentlichen Namen des Servers übermittelt – das versucht der Client selber vom CS-Server online zu bekommen. Dazu schickt er ein UDP-Paket mit einer Anfrage nacheinander an jeden CS-Server aus der Liste. In unserem Beispiel geht es dann an die Adresse des Routers ( 213.100.100.100:12345).
So, und nun kommt ein Feature des Routers zum tragen: Nur der ursprünglich angesprochene Rechner (also der STEAM-Server, an den das Begrüßungs-Paket ging) darf über diesen Port (12345) antworten – Pakete von allen anderen Quellen werden verworfen („dropped“). Dass Ihr mühevoll Port 27015 geforwardet habt, ist hierbei nicht weiter wichtig – das ist für den Router eine vollkommen andere Sache. (Das Ganze soll Hackern vorbeugen, die irgendwie von Eurem offenen Port Wind bekommen haben und über diesen nun bei Euch „rein“ wollen.)
Der Client erhält somit keine Antwort. Er vermutet, das der Server nicht mehr online ist und löscht diese IP aus seiner Liste und geht zur nächsten über (merkt man an den Hängern beim Ingame-Browser, wenn er die Servernamen durchrattert). Der Server taucht nie auf.
Also ist Euer eigener Router daran Schuld, das STEAM nicht den Port 27015, sondern irgendeinen anderen speichert – unter dem aber, dank Firewallreglement, wiederum für keinen Rechner, außer dem ursprünglich angesprochenen STEAM-Server selber, etwas zu erreichen ist.
Für dieses Problem gibt es nun 3 Ansatzpunkte:
Lösung A: Outbound NAT Preset
Ihr bringt Eurem Router bei, dass er, zumindest bei UDP-Paketen, die von Eurem Server und dessen Port 27015 kommen, bitteschön nicht den Port verändern, sondern dort 27015 stehen lassen soll. Damit würde die Masterlist die Adresse 213.100.100.100:27015 speichern und die Client-Anfragen kämen dank eingerichtetem Forward auch am Server an und würden beantwortet. Somit erfährt der Client u.a. den Namen Eures Servers und kann den in der Liste anzeigen, statt in sang- und klanglos zu löschen.
Wie dies im einzelnen für Euren (Hardware-)Router geht, entnehmt Ihr dessen Beschreibung (RTFM ) oder nehmt Kontakt zu Eurem Händler oder zum Hersteller auf - die haben die Kohle von Euch, sollen sie also auch was dafür tun. WIR WISSEN NICHT, WIE EUER ROUTER SPEZIELL EINGESTELLT WERDEN MUSS – also fragt auch bitte erst gar nicht per Mail oder ICQ. Benutzt bei totalem Versagen der erwähnten Quellen bitte Google, das ServerOp-Forum oder im IRC den Channel #serverop
Lösung B: „Loose UDP Patch“ für Linux-Router
Normalerweise darf durch einen Port, den der Router einem Paket zugeordnet hat, nur der Rechner antworten, an den das ursprüngliche Paket gerichtet war. Die Quick‘n‘Dirty Lösung ist nun: Ihr sagt Eurem Router, er soll genau diese Überprüfung abschalten.
D.h. durch den von unserem Begrüßungs-Paket geöffneten UDP-Port 12345 werden alle Pakete an den CS-Server weitergeleitet, egal von welchem Rechner im Internet aus sie gesendet wurden. Man könnte dieses Feature auch „Auto-Forwarding“ nennen – es werden automatische Forwards eingerichtet.
Da dies eine Schwächung der Firewall ist, sollte in hoch kritischen und hackanfälligen Umgebungen (wichtige Webserver, etc.) von diesem Patch abgesehen werden – für Euer Heim-LAN sollte dies jedoch keine große Gefahr darstellen. Mit diesem Patch benötigt Ihr auch nicht mehr unbedingt den 27015er-Forward – er wird schlichtweg nicht mehr gebraucht, da alle Clients über den via STEAM veröffentlichten Port 12345 anfragen.
Das ganze ging bei 2.0er und 2.2er Kernel. Wie‘s bei anderen Versionen aussieht weiss ich nicht. Genaue Installationsanweisungen entnehmt Ihr dem Web, siehe bei Google oder, weiter unten, den Links.
Die Frage ist also wie umgehe ich dieses sche*** Masquerading.
edit:
füge mal eine problembeschreibung aus den FAQs von Cstrike.de, geschrieben von mckenzie ein. Das beschreibts hervorragendend:
Nun kommt der Part mit dieser STEAM-Liste. Aber dazu ganz von vorne:
Euer Server wird gestartet und bringt ein paar Meldungen, was für eine Version er ist, usw.. Irgendwo in diesem Buchstabenverhau kommen ein paar wichtige Zeilen:
Die erste wäre
Connection to Steam servers successful
Diese Meldung sagt Euch, das Euer Server Kontakt zu STEAM und damit zum Internet hat.
Des weiteren kommen dann noch drei Meldung (die IP-Adressen können abweichen):
Adding master server 198.74.32.53:27010
Adding master server 216.52.220.16:27010
Adding master server 198.74.32.52:27010
Und hier passiert's: Euer Server schickt an diese 3 Master-Server ein „Hallo-hier-bin-ich“ Paket. Jetzt wird's ein wenig komplizierter: Dieses Begrüßungs-Paket hat von Eurem Server dessen IP-Adresse und seinen Port mit eingetragen bekommen, also 192.168.0.20:27015. Das Paket wird mit dem UDP-Protokoll verschickt. Der Server weiß, das er dieses Paket z.B. an 198.74.32.53 (den ersten der drei Master-Server) schicken soll, schaut in seiner Routing-Tabelle nach und merkt: das ist nicht im lokalen Netzwerk (192.168.0.XXX) – ich muss dieses Paket an den Router schicken, der weiß schon, wohin damit.
Maskenball: Der Router
Das Paket kommt nun bei Eurem Router an und der tut, was eine „Masquerading Firewall“ nun mal so macht: er setzt Eurem Paket eine Maske auf. Das heißt, er verändert die Quelladresse des Paketes so ab, als ob der Router als Absender dieses Paketes angesehen würde und schickt es weiter ans Internet. Hierbei verändert er aber nicht nur die Adresse, sondern in der Regel auch den Port des Pakets. Die neue Portnummer wird dabei mehr oder minder zufällig vergeben.
Nehmen wir an, das Paket, das von Eurem Server kam (Quelladresse 192.168.0.20:27015), erhält somit nun die Quelladresse 213.100.100.100 und den Quellport 12345. Nach dieser Veränderung schickt Euer Router das Paket ins Internet und merkt sich diese Änderung. Denn falls der angesprochene Server eine Antwort zurückschicken will, müssen bei den Antwortpaketen die Änderungen vom Router genau wieder rückgängig gemacht werden, damit die Pakete im LAN auch den CS-Server erreichen. Das macht der Router automatisch: mit jedem Paket, das Ihr sendet (bewusst oder unbewusst), macht ihr sozusagen eine kleine Tür auf, durch die ausschließlich der angesprochene Server antworten darf.
Die Master-List
Das Begrüßungs-Paket kommt nun nach einer kurzen Reise beim Master-Server an und dieser schaut in den IP-Header des Pakets, woher es denn kommt (Quelladresse und -port) und schreibt diesen in seine Master-List, die eigentliche STEAM-Liste. Bei unserem Beispiel landet in der STEAM-Liste die Info, dass es einen Server gibt, den man unter 213.100.100.100:12345 (die Adresse des Routers!) erreichen kann.
Die Client-Anfrage und der verschwundene Server
Was passiert nun, wenn Ihr in Eurem Client auf „Update“ klickt? Der Client sendet eine Anfrage an STEAM und bekommt auch prompt von einem der Server eine (vorgefilterte) Liste mit IP-Adressen und -Ports von Spiele-Servern zugesandt, die sich am Master-Server gemeldet haben, unter anderem in unserem Beispiel die 213.100.100.100:12345. Es werden keinerlei Informationen wie z.B. über die Anzahl der Spieler oder den eigentlichen Namen des Servers übermittelt – das versucht der Client selber vom CS-Server online zu bekommen. Dazu schickt er ein UDP-Paket mit einer Anfrage nacheinander an jeden CS-Server aus der Liste. In unserem Beispiel geht es dann an die Adresse des Routers ( 213.100.100.100:12345).
So, und nun kommt ein Feature des Routers zum tragen: Nur der ursprünglich angesprochene Rechner (also der STEAM-Server, an den das Begrüßungs-Paket ging) darf über diesen Port (12345) antworten – Pakete von allen anderen Quellen werden verworfen („dropped“). Dass Ihr mühevoll Port 27015 geforwardet habt, ist hierbei nicht weiter wichtig – das ist für den Router eine vollkommen andere Sache. (Das Ganze soll Hackern vorbeugen, die irgendwie von Eurem offenen Port Wind bekommen haben und über diesen nun bei Euch „rein“ wollen.)
Der Client erhält somit keine Antwort. Er vermutet, das der Server nicht mehr online ist und löscht diese IP aus seiner Liste und geht zur nächsten über (merkt man an den Hängern beim Ingame-Browser, wenn er die Servernamen durchrattert). Der Server taucht nie auf.
Also ist Euer eigener Router daran Schuld, das STEAM nicht den Port 27015, sondern irgendeinen anderen speichert – unter dem aber, dank Firewallreglement, wiederum für keinen Rechner, außer dem ursprünglich angesprochenen STEAM-Server selber, etwas zu erreichen ist.
Für dieses Problem gibt es nun 3 Ansatzpunkte:
Lösung A: Outbound NAT Preset
Ihr bringt Eurem Router bei, dass er, zumindest bei UDP-Paketen, die von Eurem Server und dessen Port 27015 kommen, bitteschön nicht den Port verändern, sondern dort 27015 stehen lassen soll. Damit würde die Masterlist die Adresse 213.100.100.100:27015 speichern und die Client-Anfragen kämen dank eingerichtetem Forward auch am Server an und würden beantwortet. Somit erfährt der Client u.a. den Namen Eures Servers und kann den in der Liste anzeigen, statt in sang- und klanglos zu löschen.
Wie dies im einzelnen für Euren (Hardware-)Router geht, entnehmt Ihr dessen Beschreibung (RTFM ) oder nehmt Kontakt zu Eurem Händler oder zum Hersteller auf - die haben die Kohle von Euch, sollen sie also auch was dafür tun. WIR WISSEN NICHT, WIE EUER ROUTER SPEZIELL EINGESTELLT WERDEN MUSS – also fragt auch bitte erst gar nicht per Mail oder ICQ. Benutzt bei totalem Versagen der erwähnten Quellen bitte Google, das ServerOp-Forum oder im IRC den Channel #serverop
Lösung B: „Loose UDP Patch“ für Linux-Router
Normalerweise darf durch einen Port, den der Router einem Paket zugeordnet hat, nur der Rechner antworten, an den das ursprüngliche Paket gerichtet war. Die Quick‘n‘Dirty Lösung ist nun: Ihr sagt Eurem Router, er soll genau diese Überprüfung abschalten.
D.h. durch den von unserem Begrüßungs-Paket geöffneten UDP-Port 12345 werden alle Pakete an den CS-Server weitergeleitet, egal von welchem Rechner im Internet aus sie gesendet wurden. Man könnte dieses Feature auch „Auto-Forwarding“ nennen – es werden automatische Forwards eingerichtet.
Da dies eine Schwächung der Firewall ist, sollte in hoch kritischen und hackanfälligen Umgebungen (wichtige Webserver, etc.) von diesem Patch abgesehen werden – für Euer Heim-LAN sollte dies jedoch keine große Gefahr darstellen. Mit diesem Patch benötigt Ihr auch nicht mehr unbedingt den 27015er-Forward – er wird schlichtweg nicht mehr gebraucht, da alle Clients über den via STEAM veröffentlichten Port 12345 anfragen.
Das ganze ging bei 2.0er und 2.2er Kernel. Wie‘s bei anderen Versionen aussieht weiss ich nicht. Genaue Installationsanweisungen entnehmt Ihr dem Web, siehe bei Google oder, weiter unten, den Links.
