[BC3] Iptables DNAT ivm. games

[Verwijderd]

Zullen we niet wat PREROUTING(gebeurt als verkeer de router binnenkomt) van maken?
POSTROUTING (gebeurt als het verkeer de router verlaat) wordt waarschijnlijk al gedaan door de MASQ regel die je erin hebt staan!

[BC3 Victim]

Ok, ik wil ''achter'' deze bak een drakan gameserver draaien (windows).

Gegevens ''router'':
Mandrake 7.2
Kernel 2.4.1
Iptables
BIND (dns)

De router heeft 2 ethernetkaarten, op eth0 ''zit'' mijn @home ip en op eth1 mijn interne IP (192.168.1.1).

Om internet te delen maak ik gebruik van SNAT, hieronder de relevante rules uit mijn rc.firewall

''firewall'':
iptables -A INPUT -i eth0 -s ! $INT_RANGE -m state --state ESTABLISHED,RELATED -j ACCEPT
''nat'':
/sbin/iptables -t nat -A POSTROUTING -o eth0 -d ! $INT_RANGE -j SNAT --to $EXT_IP

Dit werkt perfect.

Drakan gebruikt voor de gameplay vnl. UDP verkeer, waarbij de clients altijd zenden vanaf poort 27045. TCP verkeer op dezelfde poort komt ook voor, maar minder.

Nu zou imo de volgende regel genoeg moeten zijn:

iptables -t nat -A POSTROUTING -o eth0 -d udp --sport 27045 -j SNAT --to $GameServer
iptables -t nat -A POSTROUTING -o eth0 -d tcp --sport 27045 -j SNAT --to $GameServer
iptables -A INPUT
/sbin/iptables -A INPUT -i eth0 -p udp --dport 27045 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 27045 -j ACCEPT

Dit lijkt ook te werken. De server draait en spelers kunnen connecten. Zolang de speler stil blijven staan (weinig UDP traffic) dan blijven ze allemaal connected. Zodra ze echter gaan bewegen (toename udp traffic) dan worden er op random basis spelers gedropped, waarbij vaak de spelers met een langzame verbinding er als eerste aan gaan. De server geeft vaak niet aan waarom een speler gedropped is, soms meld hij ''lost UDP response''. TCPDump levert niets abnormaals op, al de game-traffic wordt netjes geroute zoals het hoort. Aan de client kant (de clients die gedropped worden) zie ik dat vlak voor de disconnect een ICMP ''host unreacheble'' de deur uitgaat.

Iemand een idee?

[BC3 Victim]

Heb ik ook al geprobeerd, geeft hetzelfde effect. Overigens zou ik in PREROUTING wel DNAT moeten gebruiken ipv. SNAT.

Deze methode werkt wel, als je goed kijkt gebeurd alles in de NAT table en is het alleen zaak op te letten dat mijn ''game-dnat-rules'' voor de ''deel-illegaal-mijn-netwerk'' dnat rule staat:)

Maar goed, het feit dat clients kunnen joinen geeft al aan dat het wel werkt, iets wat ik ook uit de TCPdump afleid. Het enige wat ikzelf tot nu toe heb kunnen bedenken is dat de game-server z''n hostname op een of andere manier gebruikt en dat daar problemen mee ontstaan.

[Verwijderd]

Ik zie nu overigens pas, dat je sowieso een verkeerde SNAT gebruikt!! (Misschien dat de netfilter HOWTO iets voor je is?)

Als de onderstaande regels niet werken dan zou ik het niet meer durven zeggen:

code:

/sbin/iptables -A INPUT -i eth0 -p udp -s $UNIVERSE -d $GameServer --dport 27045 -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp -s $UNIVERSE -d $GameServer --dport 27045 -j ACCEPT

/sbin/iptables -A OUTPUT -i eth0 -p udp -s $GameServer --sport 27045 -d $UNIVERSE -j ACCEPT
/sbin/iptables -A OUTPUT -i eth0 -p tcp -s $GameServer --sport 27045 -d $UNIVERSE -j ACCEPT

Denk eraan dat iptables al weet heeft d.m.v. PREROUTING waarnaartoe de packets verstuurd worden. Het is dus helemaal legaal om de $GameServer in de INPUT en OUTPUT regels op te nemen. Iets wat in het geval van ipchains niet gelde natuurlijk, daar ging het altijd om het externe IP.

Vervolgens de volgende PREROUTING regels gebruiken:

code:

iptables -A PREROUTING -t nat -i eth0 -p udp -d $EXTIP --dport 27045 -j DNAT --to $GameServer:27045
iptables -A PREROUTING -t nat -i eth0 -p tcp -d $EXTIP --dport 27045 -j DNAT --to $GameServer:27045

Gevolgd door een algemene masquerade regel in de POSTROUTING chain, die al het interne verkeer naar buiten toe masquereerd:

code:

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

Of als je toch liever per poort apart op wil geven, zet je hetvolgende in de POSTROUTING chain:

code:

iptables -A POSTROUTING -t nat -o eth0 -p udp -s $GameServer --sport 27045 -j SNAT --to $EXTIP:27045
iptables -A POSTROUTING -t nat -o eth0 -p tcp -s $GameServer --sport 27045 -j SNAT --to $EXTIP:27045

Tja bovenstaande moet toch eigenlijk wel gegarandeerd werken

[BC3 Victim]

haha, die snat komt rechstreeks uit de netfilter howto. (misschien moet je hem zelf ook eens lezen

MASQUARADE is bedoeld voor inbel verbindingen, oftewel dynamische IP''s. Aangezien ik mijn IP statisch ingesteld heb (kan bij @home best met die lease tijden) kan ik gewoon SNAT gebruiken.

Voor alle duidelijkheid.. typefouten daargelaten is het door mij geposte script gewoon correct. Daar zit het probleem niet in.

De suggestie die jij doet (DNAT gebruiken ipv. SNAT) heb ik idd ook al eens geprobeerd, met hetzelfde effect...

Uiteraard had ik e.e.a. ook in de output table staan, die heb ik hier niet gepost omdat het niet zozeer om de firewalling gaat maar om de routing.

[BC3 Victim]

In je postrouting chain kun je overigens niet aan DNAT doen.. da''s een prerouting aangelegenheid...

[Verwijderd]

Op woensdag 18 april 2001 20:18 schreef hezik het volgende:
In je postrouting chain kun je overigens niet aan DNAT doen.. da''s een prerouting aangelegenheid...

LEZEN is moeilijk of niet:?
Waar heb ik dat ooit beweerd?

Op woensdag 18 april 2001 20:17 schreef hezik het volgende:
haha, die snat komt rechstreeks uit de netfilter howto. (misschien moet je hem zelf ook eens lezen

MASQUARADE is bedoeld voor inbel verbindingen, oftewel dynamische IP''s. Aangezien ik mijn IP statisch ingesteld heb (kan bij @home best met die lease tijden) kan ik gewoon SNAT gebruiken.

Voor alle duidelijkheid.. typefouten daargelaten is het door mij geposte script gewoon correct. Daar zit het probleem niet in.

De suggestie die jij doet (DNAT gebruiken ipv. SNAT) heb ik idd ook al eens geprobeerd, met hetzelfde effect...

Uiteraard had ik e.e.a. ook in de output table staan, die heb ik hier niet gepost omdat het niet zozeer om de firewalling gaat maar om de routing.

Dit geeft wel duidelijk aan dat je ten eerste het verschil tussen DNAT en SNAT niet begrijpt, anders had je namelijk in één keer alles goed opgeschreven.

Dat je SNAT niet begrijpt, blijkt ook wel uit het feit dat je naar een INTERNIP SNAT i.p.v. je externe IP
(SNAT: intern=>extern
DNAT: extern=>intern)

Tja ik denk niet dat ik de netfilter HOWTO nog maar een keer zal doornemen. Ken hem zo''n beetje uit m''n hoofd;)

Verder mag je van mij best eigenwijs blijven hoor, maar je zou ik m''n tips op kunnen volgen om te kijken:?

[BC3 Victim]

[edit]:
Ik moet leren dat ik niet moet koken en posten tegelijk.

Ik snap het namelijk wel, ik zit alleen teveel uit m''n nek te lullen.

Het punt MASQUARADE vs SNAT is het enige wat klopt in mijn eerdere posting, de rest is idd. bull.

Volgende keer moet ik ''t gewoon cut ''n pasten uit m''n rc.firewall, dan had er idd. DNAT gestaan ipv. SNAT

Waarom deze discussie zo loopt is een beetje afkomstig uit m''n eigen geirriteerdheid met dit probleem. Ik weet nl. echt _wel_ waar ik mee bezig ben maar dit probleem laat zich niet fixxen. De enige manier waarop ik dit spel aan de praat gekregen heb - tot nu toe - is via een pptp verbinding, maar daar wil ik van af.

Ik heb m''n volledige script al eens gepost op de mailinglist van netfilter (welke ik overigens actief volg) en veel verder dan ''iemand moet maar een helper schrijven'' kwam Rusty niet..

Source NAT is domweg het vervangen van het source IP en Destination NAT het vervangen van het destination IP, dat weet ik ook wel

Overigens _kan_ het wel degelijk met SNAT, maar da''s een lang verhaal (heb dit nl. op advies van Rusty ook ooit met SNAT geprobeerd, maar dan heb je een heleboel meer rules nodig).

Ik had die rules alleen gepost ter verduidelijking hoe en wat, helaas heb ik ze verkeerd gepost zodat mijn oorspr. vraag ondergesneeuwd is. Goed, in de rebound dan. Als je in mijn eerste post DNAT leest ipv SNAT waar het de port-forwarding van de game-traffic betreft dan klopt het allemaal helemaal. Toch werkt het niet.

Je had e.e.a. overigens af kunnen leiden uit het feit dat clients wel kunnen connecten op die game server + het feit dat ik zelf al aangeef dat het met TCPdump er allemaal goed uitziet. Had er echt SNAT gestaan dan had er nooit een client kunnen connecten

[Verwijderd]

Op woensdag 18 april 2001 21:27 schreef hezik het volgende:
[edit]:
Ik moet leren dat ik niet moet koken en posten tegelijk.

Dat lukt mij nou ook nooit;)

Het punt MASQUARADE vs SNAT is het enige wat klopt in mijn eerdere posting, de rest is idd. bull.

bull is een groot woord. Wat sommige mensen hier wel eens verkondigen komt eerder in de buurt van bull:)

Waarom deze discussie zo loopt is een beetje afkomstig uit m''n eigen geirriteerdheid met dit probleem. Ik weet nl. echt _wel_ waar ik mee bezig ben maar dit probleem laat zich niet fixxen. De enige manier waarop ik dit spel aan de praat gekregen heb - tot nu toe - is via een pptp verbinding, maar daar wil ik van af.

Okee mijn stijl van reageren was nou ook niet de meest vriendelijke, maar goed.
Ik ben blij dat ik tenminste met iemand te maken heb die er verstand van heeft.

Ik heb m''n volledige script al eens gepost op de mailinglist van netfilter (welke ik overigens actief volg) en veel verder dan ''iemand moet maar een helper schrijven'' kwam Rusty niet..

Ik had die rules alleen gepost ter verduidelijking hoe en wat, helaas heb ik ze verkeerd gepost zodat mijn oorspr. vraag ondergesneeuwd is. Goed, in de rebound dan. Als je in mijn eerste post DNAT leest ipv SNAT waar het de port-forwarding van de game-traffic betreft dan klopt het allemaal helemaal. Toch werkt het niet.

Dit is wel heel vreemd!
De clients maken een verbinding vanf die opgegeven poort voor zover ik het begrepen heb. Wordt deze verbinding naar de server geinitieerd op dezelfde poort op de server als waarop de client verbind?
Zo ja, dan zou het in principe geen problemen moeten opleveren.

Je had e.e.a. overigens af kunnen leiden uit het feit dat clients wel kunnen connecten op die game server + het feit dat ik zelf al aangeef dat het met TCPdump er allemaal goed uitziet. Had er echt SNAT gestaan dan had er nooit een client kunnen connecten

Yep, maar ik weet niet wat voor een regels je nog meer in je script had staan, die dat eventueel zouden kunnen bewerkstelligen

[BC3 Victim]

Komt alles toch nog goed

Nou ja, behalve dan natuurlijk dat die #!*(#!@*(#! gameserver niet werkt zoals ik dat wil..

De verbinding wordt in stand gebracht middels TCP op dezelfde poort. UDP wordt alleen gebruikt voor plaats/actie-omschrijvingen, vrij logisch gezien het feit dat UDP minder overhead heeft dan TCP.

Het rare is dat e.e.a pas gebeurd zodra er wat meer traffic veroorzaakt wordt (zodra alle spelers gaan bewegen). Loopt er bv. maar 1 speler rond dan gaat alles wel goed, zodra er meer gaan lopen dan worden ze random gedropped.

Frappant is ook dat het _de client_ is (externe PC) die de verbinding dropped, imo zou die er geen benul van kunnen hebben dat hij belazerd wordt, maar blijkbaar komt dat toch op de een of andere manier over.

Hoe zit dat eigenlijk met quake bijvoorbeeld? Wat zijn daar de rules voor of wordt daar nog steeds een helper voor gebruikt, zoals in ipchains? Ik heb me altijd afgevraagd wat die helper voor quake precies doet, maar nooit de tijd gehad die source eens te bekijken, misschien toch maar eens doen..

oh, misschien ten overvloede.. al het verkeer komt altijd binnen op poort 27045, de server geeft echter wel aan de clients verschillende poorten door. De clients zenden (op basis van wat de server ze aangeeft) hun packets vanaf poort 27910 en upward. De 1e client zend dus van 27910 naar 27045, de 2e van 27911 naar 27045 enzovoort. De server zend terug van 27045 naar de aan die client toegewezen poort.

[Verwijderd]

Hoe groot is je upstream bandbreedte?
Hoeveel verkeer wordt er richting server gegenereerd?
Hoe hoog/laag ligt de response tijd?

Ik zou me zo voor kunnen stellen, dat je niet genoeg bandbreedte hebt, waardoor er packets gedropped worden ed.

Verder is het in ieder geval nu zo, dat er een extra hop in de verbinding zit, waardoor die sowieso een langere response tijd heeft.

Kan je buiten een ICMP host unreachable via tcpdump helemaal niks vreemds vinden?

Je zou natuurlijk puur om te testen even een scriptje kunnen maken, waarin je alle verkeer dat op je server uitkomt wordt doorgestuurd naar die gameserver (DNAT;)).
Verder ook al het verkeer ernaartoe toe laten en al het verkeer ervanaf toelaten.
Als ie het dan niet doet, dan moet het toch echt wel aan het spel liggen.

Hoe het bij quake zit met die module voor ipchains zou ik niet durven zeggen, aangezien ik geen spelletjesfreak ben.

[BC3 Victim]

Hoe groot is je upstream bandbreedte?

''t is een @home verbinding, dus theoretisch zo''n 3.8Mbit down/256Kbit up. Ik heb het geluk dat het in mijn wijk niet echt druk te noemen is, gemiddeld haal ik zeker 2Mbit down en die 256Kbit up haalt ie sowieso wel.

Hoeveel verkeer wordt er richting server gegenereerd?

Het gebeurd al bij 3 clients welke dialup gebruiken bij hun ISP. Hoeveel verkeer het spel precies veroorzaakt heb ik eigenlijk nooit nagekeken, temeer daar het via die PPTP verbinding wel werkt.

Hoe hoog/laag ligt de response tijd?

Wat bedoel je met die response tijd? De latency? Zoals gezegd heb ik geluk met a) een snelle provider (@home) en b) een rustige wijk. Mijn ping binnen het eigen @home netwerk ligt eigenlijk altijd onder de 50 ms, de spelers welke inloggen op mijn server komen veelal uit zweden. Op een zweedse server haal ik een ping van tussen de 49 - 110.

Ik zou me zo voor kunnen stellen, dat je niet genoeg bandbreedte hebt, waardoor er packets gedropped worden ed.

Dat dacht ik eigenlijk eerst ook en had de zaak laten rusten. Todat iemand mij PopTop wees en het wel bleek te kunnen.

Kan je buiten een ICMP host unreachable via tcpdump helemaal niks vreemds vinden?

Helaas.. We hebben zowel de traffic vanaf client kant als vanaf server kant bekeken (windows mbg. dsoft''s sniffer). Als we een sessie met linux ertussen en een sessie zonder linux ertussen naast elkaar leggen zien we geen verschil, tot op het moment dat die client die ''host unreachable'' de deur uitdoet (waar overigens geen reactie op komt).

Je zou natuurlijk puur om te testen even een scriptje kunnen maken, waarin je alle verkeer dat op je server uitkomt wordt doorgestuurd naar die gameserver (DNAT).

Net even getest, zelfde effect

Ik heb de indruk dat e.e.a best met bandbreedte te maken zou kunnen hebben, vandaar dat ik ook met packet shaping aan het experimenteren ben geweest..

Daar heb ik ook vragen over.. mocht je daar in thuis zijn, ik heb hier dat gedeelte van mijn script even neergezet - maar niet hier gepost omdat je dan een onoverzichtelijke chaos krijgt .

Ik heb de indruk dat dit wel goed werkt (gewoon door te testen) maar eerlijk gezegd ben ik er niet genoeg in thuis om dit op basis van kennis te kunnen bevestigen. Misschien dat jij hier meer in ziet

Als je ''t script bekijkt zal je opvallen dat de 10:400 en 20:400 classes ontbreken, dat waren de classes voor drakan, echter heb ik er weer uitgehaald.

[edit: kleine typo''s]
[edit2: @home is natuurlijk niet 256Kbit maar 128Kbit upstream]

[BC3 Victim]

misschien ten overvloede: in dat script spreek ik van ''downstream'' en ''upstream'', misschien werkt dit verwarrend. Aangezien het queuing is wat hier gebeurd en dat alleen kan op uitgaande pakketjes zie ik de uitgaande pakketjes op m''n isp IP als ''upstream'' en de uitgaande pakketjes op m''n interne IP als ''downstream''.

[Verwijderd]

dubbelpost

[Verwijderd]

Ik heb eens naar de Traffic Control regels gekeken en die zien er gewoon goed uit.
Ik heb wel enige ervaring met Traffic Shaping en Quality Of Service, maar dat ik er nou echt van alles vanaf weet is een beetje overdreven.

Het enig dat ik zou doen (ik weet niet hoe je voorheen de klasse voor dat spel ingedeeld hebt) is een klasse aanmaken voor dat spel met een redelijke hoge rate, hoge priority en zorgen dat hij niet boundend is.

Vervolgens zou ik eens met de maxburst gaan spelen. Ik heb wel eens gelezen, dat als je minburst en maxburst omhoog gooit, dat de throughput lager wordt.
Als je maxburst wat omlaag zet, dan zal je waarschijnlijk wat minder last van het burst effect hebben, dat je met CBQ hebt. (heb ik eens ooit ergens gelezen in een van de papers van een belangrijke vrouw achter het hele CBQ gebeuren. Ik kan wel eens kijken of ik daar nog iets van terug kan vinden)
Het zou me eigenlijk ook niet verbazen, dat dit samen met de beperkte upstream bandbreedte van @Home ervoor zou kunnen zorgen, dat het niet goed gaat.

Ik zou ook een bandbreedte monitor aanzetten op de server als ik jou was. Ik heb sterk het vermoden dat bijna de volledige upstream bandbreedte wordt gebruikt.
Hier bij Chello zorgt dat ervoor dat er bijna geen downstream verkeer meer mogelijk is, zodra er veel upstream verkeer is.
Ik denk dat daar ook eerder het probleem zal liggen dan in het hele NAT gebeuren.

[BC3 Victim]

k, zal dat eens doen dan.. nog tips omtrend een goede monitor hiervoor?

[Verwijderd]

Nee niet echt, goede monitors zijn
iptraf en tcpstat (althans dat zijn de monitors die ik wel eens gebruikt heb, of ze dan ook goed zijn is een heel ander verhaal)

[Verwijderd]

LET OP!!!

You *might* want to read this first:

http://slashdot.org/developers/01/04/19/047249.shtml

Security bug in Kernel 2.4.x !

[BC3 Victim]

Als ik het goed lees geldt die bug alleen als je de ip_conntrack_ftp module geladen hebt.. dat heb ik niet, gebruik altijd pasv ftp.

Maar bedankt voor de tip!