hallo troublewolf,
dein problem läßt mir keine ruhe, verwende iptables oft und bin an no-go situationen mit iptables
immer interessiert. hast du es schon lösen können? könntest du bitte posten, was jetzt wirklich los
war? danke.
falls du noch am tüfteln bist, hätte ich noch einige fragen zu deinem problem:
1. deine netzwerktopologie:
linux gateway: eth0 mit modem verbunden, ip eth0: 192.168.0.20
spielerechner: hängt direkt an eth2 von gateway rechner, ip spielerechner: 192.168.2.20, ip eth2: ??
welche ip ist am spielerechner für d. gateway eingetragen?
was ist die ip d. modems?
2. das spiel:
wie läuft das spiel von der verbindung her gesehen ab?
habe immer gedacht, daß du eine verbindung zum spieleserver aufbaust, dich dort einloggst und der spieleserver
dann eine 2. verbindung zu dir aufbaut, über die dann das spiel abläuft. das scheint aber nicht der fall
zu sein, wenn ich mir deine statusangaben von 30.7. anschaue (deine fw. ist für mich eine quelle d.
irrungen). stimmt es, daß das spiel nur über 1 verbindung läuft und nicht über 2?
wenn das spiel nur über 1 kanal rennt, dann ist dnat für das ganze gar nicht zuständig, da die
nat-tables nur einmal beim verbindungsaufbau durchlaufen werden und dann d. rest durch das conn.
tracking module erledigt wird (s. deine statusmeldungen von so., kein einziger hit bei deinen
pre-rules, das ist kein bug). das spiel wird nur über eine verbindung abgewickelt, du startest die
verbindung, masquerading wird aktiviert und fertig- glaube ich jetzt mal, aber ich kann mich wieder
irren...
es ist mir unklar, was an diesem spiel so speziell ist, andere spiele und normale inet
verbindungen funktionieren und genau dieses eine spiel nicht, wobei es für mich interessant ist,
wie restriktiv du deine forward-kette gehalten hast: du erlaubst d. spielerechner genau 3
privilegierte verbindungstypen aufzubauen- smtp(25), http (80) und pop3 (110), htpps(443) z.b. ist
schon nicht mehr dabei..., o.k. letztlich ist alles unsicher
.
damit wäre für mich ein mögliches szenerio deines problems:
du startest das spiel und nimmst mit dem spieleserver auf port 80 kontakt auf (kann mir nicht
vorstellen, daß du schon mit port 3724 startest), der leitet nicht transparent und
ohne icmp-redirects (typ5)- motto:"za wos brauch' ma des?"- um auf port 3724 (möglicherweise sogar
auf einem anderen server), die pakete vom (neuen) server kommen bei dir an und werden vom conn.tr.module
nicht erkannt (wie sollte es auch, no icmp-redirects und nicht transparent), deshalb
in die input chain geroutet und dort ihrer bestimmung zugeführt...
wenn du dir deine logs im posting vom 23.7. anschaust:
kein verworfenes packet hatte dst=192.168.2.20 und srcpt war 3724 und nicht 80
auch deine statusmeldungen vom 30.7., wo du die forward-chain für srcpt=3724 voll aufmachst, sind
ein indiz für meine vermutungen: kein einziger hit
3. noch eine frage, die nicht das forwarding problem betrifft:
die regel2 der input chain (syn-accept auf 1723er port) ist mir sofort ins auge gesprungen und wird mir
immer unklarer (hat mich so verwirrt, daß ich zuerst an ein völlig verdrehtes pptp setup gedacht
habe, s. mein vorl. posting). was soll diese regel bewirken? du hast einen server auf deiner linux
kiste laufen, der an einem variablen hi-tcp port lauscht. der provider sitzt am anderen ende der
ppp verbindung u. baut dann mit d. privaten srcip 10.0.0.138 (die er manipulieren muß, weil sonst die
pakte mit d. ip d. entfernten endes d. ppp-links hinausgehen würden) von port 1723 eine
verbindung über d. ppp-link (wan-interface) zu deiner linux kiste auf? wozu dient diese seltsame
verbindung, ist d. portnr. d. servers tatsächlich variabel, wie kriegt der provider die portnr.
mit, portscan, variant of portknocking? könntest du mich bitte aufklären, ich glaub', ich hab'
im schlimmen fall einen gröberen knopf, im guten fall kann ich noch 'ne menge lernen.
lg zid
ps: falls ich dich in deinem streß nerve -> just "rausdamit"
pps: alzheimer-light läßt grüßen: wie schaut das ganze übrigens mit tcpdump/ereal auf eth0 aus? -> post it
>EDIT
oops, doch noch was vergessen:
[s]falls du den spieleserver doch schon von beginn an auf port 3724 kontaktierst (sprich: du hast spez.
software für das spiel heruntergeladen), dann solltest du den port 3724 in der forward-kette für
outbound conns öffnen (masqu. geht sonst schief):
[/s]
habe bei blizzard nachgeschaut (s.u.) und bei der forward accept regel für reinkommende, neue
verbindungen (regel5) state u. richtung spezifiziert, die restl. einträge sind
nur logs um das ganze besser verfolgen zu können:
# Generelle Regeln fuer Antwortpakete
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Debugging fuer WoW
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-IN-RELATED WoW-packet" -m state --state ESTABLISHED,RELATED -p tcp -i $INET -o $LANS --sport 3724
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-IN-RELATED WoW-packet" -m state --state ESTABLISHED,RELATED -p tcp -i $INET -o $LANS --dport 3724
iiptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-OUT-RELATED WoW-packet" -m state --state ESTABLISHED,RELATED -p tcp -i $LANS -o $INET --sport 3724
ptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-OUT-RELATED WoW-packet" -m state --state ESTABLISHED,RELATED -p tcp -i $LANS -o $INET --dport 3724
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Unprivilegierte Ports von innen nach aussen (verbindungsaufbau erlaubt) auf
# und von aussen nach innen (verbindungsaufbau nicht erlaubt)
# Logging of outgoing conn. to port 3724 of WoW
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-OUT-NEW WoW-packet" -m state --state NEW -p tcp -i $LANS -o $INET --dport 3724
iptables -A FORWARD -p TCP -i $LANS -o $INET --sport $UNPRIV --dport $UNPRIV -m state --state NEW -j ACCEPT
# WoW weiterleiten
# WoW braucht beide Richtungen von Port 3724, state zur Regel hinzugef.
# weitere infos auf
http://www.blizzard.com/support/?id=msi0445p
# state u. Richtung zur Regel hinzugef.
# Logging of incoming conn. to local port 3724
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-ACC-IN-NEW WoW-packet" -m state --state NEW -p tcp -i $INET -o $LANS --dport 3724
iptables -A FORWARD -p TCP -i $INET -o $LANS --dport 3724 -m state --state NEW -j ACCEPT
# So was nun bishier her gekommen is wird rausgeschmissen oder zurueckgewiesen
iptables -A INPUT -j rausdamit
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-DROP-RELATED WoW-packet reached point of no return, SH...!" -m state --state ESTABLISHED,RELATED -p tcp --sport 3724
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-DROP-RELATED WoW-packet reached point of no return, SH...!" -m state --state ESTABLISHED,RELATED -p tcp --dport 3724
iptables -A FORWARD -j LOG --log-level debug --log-tcp-options --log-ip-options --log-prefix "FW-FORWARD-DROP-NEW WoW-packet reached point of no return, SH...!" -m state --state NEW -p tcp --dport 3724
iptables -A FORWARD -j rausdamit
iptables -A OUTPUT -j rausdamit
dann syslog umstellen:
touch /var/log/WoW_debug
in /etc/syslog.conf den folgenden eintrag
*.*;mail.none;news.none -/var/log/messages
durch
*.*;mail.none;news.none;kern.!=debug -/var/log/messages
ersetzen. Das funktioniert manchmal nicht (bug), dann
*.*;mail.none;news.none;kern.none -/var/log/messages
kern.info -/var/log/messages
# Firewall logs for WoW debugging go to /var/log/WoW_debug
kern.=debug /var/log/WoW_debug
syslog neu starten, ereal auf eth0 starten (ev. mit filter tcp.port==3724) und
tail -f /var/log/WoW_debug
spiel starten und schauen, was passiert.