Ja da hst du recht. Aber das mit dem dport hab ich schon geändert siehe Post vom 30.Juli da hab ich das ganze dann schon auf den --sport bezogen und hab den --dport weggelassen. Weil der dport bei den Paketen immer schwankt von 1024 aufwärts. Hat aber leider auch nicht geholfen. Es geht ja nicht so sehr um die FORWARD Regel sondern fiel mehr darumm das die NAT Regel die Pakete nicht umleitet.
Trotzdem danke mal für die Antwort.
Probleme mit Paketen die über Firewall sollen
Forumsregeln
Das Forum für den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!
Das Forum für den Linux-Pinguin - auch andere Unix-Derivate (*BSD, (Open)Solaris, Apple's Darwin / MacOS X, ...) sind hier willkommen!
34 Beiträge
• Seite 2 von 3 • 1, 2, 3
von TroubleWolf » Mi 02 Aug, 2006 14:33
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
von zid » Mi 02 Aug, 2006 14:44
1. mach' log einträge vor den prerouting u. forward regeln.
2. deine (accept) regeln stimmen auch nicht. Ist ein wunder, daß
a) du überhaupt ins internet kommst (fehler kompensieren sich) und
b) du noch kein opfer von syn attacken geworden bist.
2. deine (accept) regeln stimmen auch nicht. Ist ein wunder, daß
a) du überhaupt ins internet kommst (fehler kompensieren sich) und
b) du noch kein opfer von syn attacken geworden bist.
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von TroubleWolf » Mi 02 Aug, 2006 15:15
@zid
1. Ok hört sich gut an werd dann mal versuchen das ganze mit log regeln vollzuspiken und hoffe ich seh dann mehr als vorher.
2. Ok bin immer offen für kritik. Wenn du dann auch mal so nett bist und mir sagst welche regeln nicht stimmen dann kann ich die ändern damit ich zu
a. dann mit sicherheit ins internet komme und zu
b. mit sicherheit dann kein opfer von syn atackenwerde.
Es kann ja sein das ich die iptables-dokumentation nicht richtig verstanden hab und ich so Fehler gemacht hab aber bis jetzt haben meine regeln ja eigentlich jedes TCP-syn paket das nicht korrekt war gedroped und ansonsten hab ich auch keine Probleme gehabt.
mfg TroubleWolf.
1. Ok hört sich gut an werd dann mal versuchen das ganze mit log regeln vollzuspiken und hoffe ich seh dann mehr als vorher.
2. Ok bin immer offen für kritik. Wenn du dann auch mal so nett bist und mir sagst welche regeln nicht stimmen dann kann ich die ändern damit ich zu
a. dann mit sicherheit ins internet komme und zu
b. mit sicherheit dann kein opfer von syn atackenwerde.
Es kann ja sein das ich die iptables-dokumentation nicht richtig verstanden hab und ich so Fehler gemacht hab aber bis jetzt haben meine regeln ja eigentlich jedes TCP-syn paket das nicht korrekt war gedroped und ansonsten hab ich auch keine Probleme gehabt.
mfg TroubleWolf.
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
von zid » Mi 02 Aug, 2006 17:45
sorry, hab' deine einwahlmethode (pppoe und nicht pptp- bin etwas pptp fixiert 
) übersehen. accept-regel2 der input chain hat mich irritiert, war übrigens keine kritik, sondern nur eine (falsche) bemerkung.
gutes gelingen bei deinem forwarding problem
zid
) übersehen. accept-regel2 der input chain hat mich irritiert, war übrigens keine kritik, sondern nur eine (falsche) bemerkung.
gutes gelingen bei deinem forwarding problem
zid
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von zid » Fr 04 Aug, 2006 18:57
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.
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.
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von TroubleWolf » So 06 Aug, 2006 21:42
Hatte leider noch keine Zeit bisher deine angaben zu testen zid.
Ich find es toll das du dir soviel arbeit machst wegen mir. Werde dann morgen also Montag deine Regeln einarbeiten. Das mit dem Log das der in einen eigen Logordner lauft das wollte ich schon immer mal haben das gefällt mir sher danke.
Zum verständnis für die Regel
die regel2 der input chain (syn-accept auf 1723er port)
das gilt ausschließlich dazu das wenn die Firewall schon lauft das ich verbindung zum Provider aufnehmen kann sonst würde eine authentifizierung scheitern. Aber die Regel is nicht vollständig dagört noch eine dazu. Momentan starte ich Xdsl vor der Firewall und somit is die regel eigentlich hinfällig.
Zu 1. das siehst du nicht ganz richtig.
Es sieht so aus bei mir.
linux gateway:
eth0
ist momentan mit nix verbunden. Hat im Geteway die IP 192.168.0.1. Ist nur für Schleptop damit ich den auch anstöpseln kann der kriegt dann auf dem 192.168.0.0/24 Netzwerk eine IP zwischen 192.168.0.2 und 192.168.2.20 vom dhcp zugewiesen.
eth1
ist die Netzwerkarte an der das Xdsl Modem hängt und kriegt keine IP zugwiesen weil die sowieso wieder überschrieben würde vom Modem soviel ich weis. Ist auch in der /etc/conf.d/net.conf(oder war das ohne .conf hab grad mein gentoo net laufen) so eingetragen.
eth2
ist mit dem Spiel PC verbunden der die IP 192.168.2.20 vom dhcp zugewiesen kriegt. Im Geteway hat eth2 192.168.2.1 als Adresse und die is auch beim Spiel PC eingetragen als Geteway.
Ip des Modems ähm weis jetzt net genau wie du das meinst aber da ich Dynamisch IP,s von meinem Provieder zugewiesen krieg ist das glaub ich immer eine andere?
zu 2.
Kann ich dir momentan nur schnell zu meinen Forwardregeln was sagen. SMTP und POP3 sind für Emails aber das weist du ja. Port 80 also http sollte ich normal eigentlich gar net forwarden weil ich ja http über eine Proxy erledige der auf dem Getway auch noch lauft und deswegen hab ich auch https nicht geforwardet weil das auch über den Proxy läuft. Aber aus irgend einen grund kann ich mich bei dem Spiel nur bei meinem Account einloggen wenn ich den port 80ig forwarde.
Zum rest sag ich dir dann Morgen bescheid hab Heute leider keine Zeit mehr dazu.
Ich find es toll das du dir soviel arbeit machst wegen mir. Werde dann morgen also Montag deine Regeln einarbeiten. Das mit dem Log das der in einen eigen Logordner lauft das wollte ich schon immer mal haben das gefällt mir sher
danke.
Zum verständnis für die Regel
die regel2 der input chain (syn-accept auf 1723er port)
das gilt ausschließlich dazu das wenn die Firewall schon lauft das ich verbindung zum Provider aufnehmen kann sonst würde eine authentifizierung scheitern. Aber die Regel is nicht vollständig dagört noch eine dazu. Momentan starte ich Xdsl vor der Firewall und somit is die regel eigentlich hinfällig.
Zu 1. das siehst du nicht ganz richtig.
Es sieht so aus bei mir.
linux gateway:
eth0
ist momentan mit nix verbunden. Hat im Geteway die IP 192.168.0.1. Ist nur für Schleptop damit ich den auch anstöpseln kann der kriegt dann auf dem 192.168.0.0/24 Netzwerk eine IP zwischen 192.168.0.2 und 192.168.2.20 vom dhcp zugewiesen.
eth1
ist die Netzwerkarte an der das Xdsl Modem hängt und kriegt keine IP zugwiesen weil die sowieso wieder überschrieben würde vom Modem soviel ich weis. Ist auch in der /etc/conf.d/net.conf(oder war das ohne .conf hab grad mein gentoo net laufen) so eingetragen.
eth2
ist mit dem Spiel PC verbunden der die IP 192.168.2.20 vom dhcp zugewiesen kriegt. Im Geteway hat eth2 192.168.2.1 als Adresse und die is auch beim Spiel PC eingetragen als Geteway.
Ip des Modems ähm weis jetzt net genau wie du das meinst aber da ich Dynamisch IP,s von meinem Provieder zugewiesen krieg ist das glaub ich immer eine andere?
zu 2.
Kann ich dir momentan nur schnell zu meinen Forwardregeln was sagen. SMTP und POP3 sind für Emails aber das weist du ja. Port 80 also http sollte ich normal eigentlich gar net forwarden weil ich ja http über eine Proxy erledige der auf dem Getway auch noch lauft und deswegen hab ich auch https nicht geforwardet weil das auch über den Proxy läuft. Aber aus irgend einen grund kann ich mich bei dem Spiel nur bei meinem Account einloggen wenn ich den port 80ig forwarde.
Zum rest sag ich dir dann Morgen bescheid hab Heute leider keine Zeit mehr dazu.
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
von zid » Mo 07 Aug, 2006 03:16
hallo troublewolf,
danke für deine infos, deine linux kiste ist ja ziemlich aktiv...
einige gedankensplitter (dein proxy...!):
dein problem wird mir immer rätselhafter, denn die drops, die du am anfang des
threads gepostet hast sind masqu. pakete (d.h. sollten sein- sind ja nicht demaskiert worden),
andrerseits: du hast normalen zugang vom spielerechner zum internet, das ding ist schon gelaufen,
also: was ist der unterschied zw. port 80 u. port 3724...?
dein proxy "überrrrascht" mich- gelinde gesagt, hab' ihn i. d. regeln nicht gesehen, muß umdenken.
was hast du laufen? ... squid/http? (wäre eine erklärung für den unterschied v. port 80 u. 3724).
proxy + masq.- das ist ja fast schon nsa manier, bist 'n echter feinspitz.
bin gespannt auf den output v. erael.
lg zid
danke für deine infos, deine linux kiste ist ja ziemlich aktiv...
einige gedankensplitter (dein proxy...!):
dein problem wird mir immer rätselhafter, denn die drops, die du am anfang des
threads gepostet hast sind masqu. pakete (d.h. sollten sein- sind ja nicht demaskiert worden),
andrerseits: du hast normalen zugang vom spielerechner zum internet, das ding ist schon gelaufen,
also: was ist der unterschied zw. port 80 u. port 3724...?
dein proxy "überrrrascht" mich- gelinde gesagt, hab' ihn i. d. regeln nicht gesehen, muß umdenken.
was hast du laufen? ... squid/http? (wäre eine erklärung für den unterschied v. port 80 u. 3724).
proxy + masq.- das ist ja fast schon nsa manier, bist 'n echter feinspitz.
bin gespannt auf den output v. erael.
lg zid
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von TroubleWolf » Mo 07 Aug, 2006 18:33
Also ich benutze Squid als Proxy. Ist eigentlich keine große sache find ich.
Es gibt schon noch einen kleinen Unterschied zu meinem füheren System auser der Hardware. Ich hatte vorher noch Samba und Apache drauf laufen. Die hab ich bis jetzt noch nicht in meiner Linuxkiste drinen.
Hab mal auf meinem Spiel PC Ethereal mitlaufen lassen da sieht man wie der verbindugsaufbau geht. Anfangen tut er mit nem port über 1024 zu nem 80er port also Athentifizierung is noch auf Http. Da gehen dann ein paar Pakete hin und her und dann wechselt der Port mal auf 3724, und es werden auch Pakte rein und werden wieder raus geschickt. Also stheht die verbindung auch kurzzeitig . Es bestätig auch irgendwie deine Forwardtheorie das ich Nat eigentlich ja nicht brauche. Aber warumm bricht das Spiel dann wieder ab?
Ich hab mal 3 versuche gemacht und da konnte ich ganz kurzzeitig im Spiel agieren(also einen Satz schreiben und dann wars auch schon wieder vorbei) . Beim 4. versuch konnte ich 5 min Spielen mit einer guten Latenz sogar aber dann wurde die Verbindung zum Server auch wieder unterbrochen.
Mit dem debugen hab ich auch einwenig Probs gehabt meinen Systemloger anzupassen. Ich verwende ja Syslog-ng und da is das ganz anders kunfiguriert in der .conf Datei. Habs aber hinbekommen glaub ich und bei den ersten 3 versuchen kamen pro versuch immer nur 2 Zeilen.
Weis auch noch nicht wie du das mit ereal gemeint hast. Soll ich das auch auf dem Gateway laufen lassen. Haber leider das Programm net finden können. Tcpdump hab ich schon gefunden bzw installiert dann. Aber mit dem weis ich irgendwie net so recht was anzufangen.
Es gibt schon noch einen kleinen Unterschied zu meinem füheren System auser der Hardware. Ich hatte vorher noch Samba und Apache drauf laufen. Die hab ich bis jetzt noch nicht in meiner Linuxkiste drinen.
Hab mal auf meinem Spiel PC Ethereal mitlaufen lassen da sieht man wie der verbindugsaufbau geht. Anfangen tut er mit nem port über 1024 zu nem 80er port also Athentifizierung is noch auf Http. Da gehen dann ein paar Pakete hin und her und dann wechselt der Port mal auf 3724, und es werden auch Pakte rein und werden wieder raus geschickt. Also stheht die verbindung auch kurzzeitig . Es bestätig auch irgendwie deine Forwardtheorie das ich Nat eigentlich ja nicht brauche. Aber warumm bricht das Spiel dann wieder ab?
Ich hab mal 3 versuche gemacht und da konnte ich ganz kurzzeitig im Spiel agieren(also einen Satz schreiben und dann wars auch schon wieder vorbei) . Beim 4. versuch konnte ich 5 min Spielen mit einer guten Latenz sogar aber dann wurde die Verbindung zum Server auch wieder unterbrochen.
Mit dem debugen hab ich auch einwenig Probs gehabt meinen Systemloger anzupassen. Ich verwende ja Syslog-ng und da is das ganz anders kunfiguriert in der .conf Datei. Habs aber hinbekommen glaub ich und bei den ersten 3 versuchen kamen pro versuch immer nur 2 Zeilen.
- Code: Alles auswählen
Aug 7 19:14:09 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.178.112 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=2003 DF PROTO=TCP SPT=1103 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Aug 7 19:14:10 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.233.100 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=2036 DF PROTO=TCP SPT=1104 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Aug 7 19:47:17 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.178.111 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5385 DF PROTO=TCP SPT=1126 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Aug 7 19:47:18 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.233.100 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5417 DF PROTO=TCP SPT=1127 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Aug 7 19:51:49 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.178.114 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5930 DF PROTO=TCP SPT=1133 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Aug 7 19:51:50 gmundens FW-FORWARD-ACC-OUT-NEW WpIN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.233.100 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=5962 DF PROTO=TCP SPT=1134 DPT=3724 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Weis auch noch nicht wie du das mit ereal gemeint hast. Soll ich das auch auf dem Gateway laufen lassen. Haber leider das Programm net finden können. Tcpdump hab ich schon gefunden bzw installiert dann. Aber mit dem weis ich irgendwie net so recht was anzufangen.
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
von zid » Di 08 Aug, 2006 13:40
war gestern a. e. netten fest, komme heim und was ich sehe, ist nicht so erbauend.
1. zu erael:
hoffe, du bist nicht meinem schlampigen jargon zum opfer gefallen. mit "ereal"
meine ich ethereal, das gui analogon zu tcpdump. bei gentoo heißt das ding wireshark (sorry) und
dazu gibt es eine ziemlich "frische" GLSA mit impact "high" (schau nach z.b. [link=http://www.gentoo.org/security/en/glsa/glsa-200607-09.xml]hier[/link]). also laß' es
sein, tcpdump hast du schon installiert, das ist nicht ganz so chic wie wireshark/ereal, leistet
aber das gleiche.
2. wir sollten unsere diskussionsbasis kurz syncen:
masq. ist ein spezialfall von snat für dyn. adressen. der einzige unterschied besteht darin, daß bei masq. das conn.tr.module bei verbindungsabbruch die dyn-src "vergißt" und beim nächsten verbindungsaufbau die (i.schnitt neue) dyn-src wieder einliest.
das szenario, wenn alles funktioniert:
firewall-logs, forward-chain:
SYN:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.178.112 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF PROTO=TCP SPT=<hi-tcp> DPT=3724 WINDOW=<größer-als-mss> RES=0x00 SYN URGP=0 OPT (0204<keiner-als-0x5d4>*....etc)
SYN-ACK:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=ppp0 OUT=eth2 SRC=80.239.178.112
DST=192.168.2.20 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF
PROTO=TCP SPT=3724 DPT=<hi-tcp> WINDOW=<größer-als-mss> RES=0x00 ACK SYN URGP=0 OPT
(0204<keiner-als-0x5d4>*....etc)
ACK:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=eth2 OUT=ppp0 SRC=192.168.2.20
DST=80.239.178.112 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF
PROTO=TCP SPT=<hi-tcp> DPT=3724 WINDOW=<größer-als-mss> RES=0x00 ACK URGP=0 OPT
(0204<keiner-als-0x5d4>*....etc)
*mss sollte für pppoe mit snap =< 1492 = 0x05d4 sein, in deinen logs hast du 0x05b4 = 1460,
mtu also ok (war ein verdacht v. mir).
wie du siehst, kann man in den fw. logs das masq. nicht wirklich erkennen (nur indirekt, wenn die
SYN-ACKS ankommen),deshalb brauchen wir tcpdump auf eth1. m. tcpdump siehst welche masq. packete
tatsächlich rausgehen und welche (noch nicht demasq.) packete vom server reinkommen. damit kannst
du dann auch sehr genau verfolgen, was bei einem verbindungsabbruch passiert: geht ein packet m.
fw-log eintrag auf einmal nicht mehr hinaus (d.h. kein eintrag b. tcpdump) oder kommt auf einmal
ein packet vom server hinein (eintrag bei tcpdump) und landet nicht in der forward-kette (kein
fw-log eintrag), dann hast du ein problem mit iptables, dem genauer nachzugehen ist. wenn das
ganze aber plötzlich sang und klanglos stirbt und alle einträge in den fw- und tcpdump-logs
vorhanden sind, dann dürfte das problem eher bei spieleclient liegen und du solltest
versuchen, die windows kiste direkt an das modem anzuschließen und schauen, wie das ganze dann
abläuft. hast du das vielleicht schon gemacht?
format der tcpdump ausgaben für ip/tcp:
<zeit> IP src.srcpt > dest.dstpt <flags*> <seq.nr>:<next-seq.nr> (packetgröße) ack <ack.nr>
win <window-size> <tcp-options-i. klartext>
*<flags>=S(YN), F(IN), P(USH), R(ESET), "."= kein flag, W (ECN CWR), E (ECN-Echo)
das handshaking von oben müßte bei tcpdump a. eth1 also ca. so aussehen:
SYN:
<zeit> deine-dyn.ip*.<hi-tcp> > 80.239.178.112.3724 S 12345:12345**(0) win <hinreichend-groß>
<mss 1460 weitere optionen>
SYN-ACK:
<zeit> 80.239.178.112.3724 > deine-dyn.ip*.<hi-tcp> S 67890:67890**(0) ack 12346 win <hinreichend-groß>
<mss 1460 oder kleiner, weitere optionen>
ACK:
<zeit> deine-dyn.ip*.<hi-tcp> > 80.239.178.112.3724 . ack 1*** win <hinreichend-groß>
<mss 1460 weitere optionen>
* das masqu. hat schon stattgefunden, hier steht nicht mehr die private addr. 192.168.2.20,
sondern deine öffentl. ip.
** normalerweise zufallszahl, "12345" von mir hier willkürlich gewählt.
*** hier schaltet tcpdump von abs. seq-ack nummern, auf relative um, besser für seq. analyse.
3. wie könntest du vorgehen:
root konsole öffnen und verlaufsspeicher auf unbegrenzt stellen, tcpdump starten mit
tcpdump -n -i eth1
tcpdump startet dann und meldet alle ip packete, beendet wird das ganze mit strg-c.
(du könntest auch filter nehmen, also tcpdump -n -i eth1 "tcp port 3724", würde ich am anfang aber
nicht machen).
2. konsole öffnen, marker in /var/log/WoW_debug setzen und tracing einschalten
echo "----------
----- Start von WoW Test 1 --------
-----------" >> /var/log/WoW_debug && tail -f /var/log/WoW_debug
dann spiel starten und schauen, was passiert (ereal auf d. spielerechn. ev. einschalten, dann hast
du überhaupt alles).
am ende des test mußt du halt den ouput von tcp dump manuell in eine datei kopieren (w. infos: man
tcpdump)
was ist interessant?
verbindungsaufbau zu port 80, dann der switch zu port 3724 und die packete vor verbindungsabbruch.
aber auch: gibt es viele retransmissions,icmp's? typ? code?, gehen die icmp's auch korrekt durch
(sollte kein prob sein, regeln o.k.), stimmen die seq-acks (vor allem die kurz vor verbindungsabbruch)...
4. fragen:
hast du die fw. logs ungekürzt gepostet? keine syn-acks?
sind das 3 od. 6 verbindungsversuche? eigenartig, daß der client nur 1 syn sendet und dann 1-ige
sec. später auf einem neuen port eine 2. verbindung aufbaut, macht er das automatisch?
lg zid
1. zu erael:
hoffe, du bist nicht meinem schlampigen jargon zum opfer gefallen. mit "ereal"
meine ich ethereal, das gui analogon zu tcpdump. bei gentoo heißt das ding wireshark (sorry) und
dazu gibt es eine ziemlich "frische" GLSA mit impact "high" (schau nach z.b. [link=http://www.gentoo.org/security/en/glsa/glsa-200607-09.xml]hier[/link]). also laß' es
sein, tcpdump hast du schon installiert, das ist nicht ganz so chic wie wireshark/ereal, leistet
aber das gleiche.
2. wir sollten unsere diskussionsbasis kurz syncen:
masq. ist ein spezialfall von snat für dyn. adressen. der einzige unterschied besteht darin, daß bei masq. das conn.tr.module bei verbindungsabbruch die dyn-src "vergißt" und beim nächsten verbindungsaufbau die (i.schnitt neue) dyn-src wieder einliest.
das szenario, wenn alles funktioniert:
firewall-logs, forward-chain:
SYN:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=eth2 OUT=ppp0 SRC=192.168.2.20 DST=80.239.178.112 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF PROTO=TCP SPT=<hi-tcp> DPT=3724 WINDOW=<größer-als-mss> RES=0x00 SYN URGP=0 OPT (0204<keiner-als-0x5d4>*....etc)
SYN-ACK:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=ppp0 OUT=eth2 SRC=80.239.178.112
DST=192.168.2.20 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF
PROTO=TCP SPT=3724 DPT=<hi-tcp> WINDOW=<größer-als-mss> RES=0x00 ACK SYN URGP=0 OPT
(0204<keiner-als-0x5d4>*....etc)
ACK:
<datum-zeit> gmundens <dein-forward-chain-präfix> IN=eth2 OUT=ppp0 SRC=192.168.2.20
DST=80.239.178.112 LEN=<abh. v opts> TOS=0x00 PREC=0x00 TTL=<nicht-zu-klein> ID=<variabel> DF
PROTO=TCP SPT=<hi-tcp> DPT=3724 WINDOW=<größer-als-mss> RES=0x00 ACK URGP=0 OPT
(0204<keiner-als-0x5d4>*....etc)
*mss sollte für pppoe mit snap =< 1492 = 0x05d4 sein, in deinen logs hast du 0x05b4 = 1460,
mtu also ok (war ein verdacht v. mir).
wie du siehst, kann man in den fw. logs das masq. nicht wirklich erkennen (nur indirekt, wenn die
SYN-ACKS ankommen),deshalb brauchen wir tcpdump auf eth1. m. tcpdump siehst welche masq. packete
tatsächlich rausgehen und welche (noch nicht demasq.) packete vom server reinkommen. damit kannst
du dann auch sehr genau verfolgen, was bei einem verbindungsabbruch passiert: geht ein packet m.
fw-log eintrag auf einmal nicht mehr hinaus (d.h. kein eintrag b. tcpdump) oder kommt auf einmal
ein packet vom server hinein (eintrag bei tcpdump) und landet nicht in der forward-kette (kein
fw-log eintrag), dann hast du ein problem mit iptables, dem genauer nachzugehen ist. wenn das
ganze aber plötzlich sang und klanglos stirbt und alle einträge in den fw- und tcpdump-logs
vorhanden sind, dann dürfte das problem eher bei spieleclient liegen und du solltest
versuchen, die windows kiste direkt an das modem anzuschließen und schauen, wie das ganze dann
abläuft. hast du das vielleicht schon gemacht?
format der tcpdump ausgaben für ip/tcp:
<zeit> IP src.srcpt > dest.dstpt <flags*> <seq.nr>:<next-seq.nr> (packetgröße) ack <ack.nr>
win <window-size> <tcp-options-i. klartext>
*<flags>=S(YN), F(IN), P(USH), R(ESET), "."= kein flag, W (ECN CWR), E (ECN-Echo)
das handshaking von oben müßte bei tcpdump a. eth1 also ca. so aussehen:
SYN:
<zeit> deine-dyn.ip*.<hi-tcp> > 80.239.178.112.3724 S 12345:12345**(0) win <hinreichend-groß>
<mss 1460 weitere optionen>
SYN-ACK:
<zeit> 80.239.178.112.3724 > deine-dyn.ip*.<hi-tcp> S 67890:67890**(0) ack 12346 win <hinreichend-groß>
<mss 1460 oder kleiner, weitere optionen>
ACK:
<zeit> deine-dyn.ip*.<hi-tcp> > 80.239.178.112.3724 . ack 1*** win <hinreichend-groß>
<mss 1460 weitere optionen>
* das masqu. hat schon stattgefunden, hier steht nicht mehr die private addr. 192.168.2.20,
sondern deine öffentl. ip.
** normalerweise zufallszahl, "12345" von mir hier willkürlich gewählt.
*** hier schaltet tcpdump von abs. seq-ack nummern, auf relative um, besser für seq. analyse.
3. wie könntest du vorgehen:
root konsole öffnen und verlaufsspeicher auf unbegrenzt stellen, tcpdump starten mit
tcpdump -n -i eth1
tcpdump startet dann und meldet alle ip packete, beendet wird das ganze mit strg-c.
(du könntest auch filter nehmen, also tcpdump -n -i eth1 "tcp port 3724", würde ich am anfang aber
nicht machen).
2. konsole öffnen, marker in /var/log/WoW_debug setzen und tracing einschalten
echo "----------
----- Start von WoW Test 1 --------
-----------" >> /var/log/WoW_debug && tail -f /var/log/WoW_debug
dann spiel starten und schauen, was passiert (ereal auf d. spielerechn. ev. einschalten, dann hast
du überhaupt alles).
am ende des test mußt du halt den ouput von tcp dump manuell in eine datei kopieren (w. infos: man
tcpdump)
was ist interessant?
verbindungsaufbau zu port 80, dann der switch zu port 3724 und die packete vor verbindungsabbruch.
aber auch: gibt es viele retransmissions,icmp's? typ? code?, gehen die icmp's auch korrekt durch
(sollte kein prob sein, regeln o.k.), stimmen die seq-acks (vor allem die kurz vor verbindungsabbruch)...
4. fragen:
hast du die fw. logs ungekürzt gepostet? keine syn-acks?
sind das 3 od. 6 verbindungsversuche? eigenartig, daß der client nur 1 syn sendet und dann 1-ige
sec. später auf einem neuen port eine 2. verbindung aufbaut, macht er das automatisch?
lg zid
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von TroubleWolf » Di 08 Aug, 2006 17:40
Ach das gefällt mir du amüsierst dich wenigstens ab und zu .
1. Nö dein jargon stört mich eigentlich nicht, hab mir schon gedacht das du mit ereal Ethreal gemeint hast. Da ich aber auf meinem GentooRechner keinen X-server oder ähnliches laufen hab und ich alles sowieso in die Konsole klopf würde Ethreal oder Wireshark eh net laufen.
2. Danke für die Info. Wusste bisher eigentlich nur das SNAT bei Statischen IPs dem Masqu vorzuziehen ist. SNAT hatte ich auch mal laufen wie ich noch Inet über Kabel hatte. Da hatte ich eine Statische IP und da ging das prima.
3. Hier ein output wie du sagst von den Interesannten stellen.
mal der Verbindungsaufbau und switch zu port 3724
und die Pakte vor verbindungsabbruch
Also Icmp is nicht fiel unterwegs muss ich sagen. Was ich so sehe gehen die auch korekt durch.
Aber diese Zeilen
18:44:41.911130 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
die irritieren mich. Da weis ich überhaupt nicht was das sein soll.
4. Ja die von deinem WoW_debug log waren nicht gekürzt. I hab leider die Einträge bei den log-prefixen einwenig kürzen müssen weil da laut meinem Iptales nur 29 Zeichen zulässig sind.
Es waren 3 versuche.
Es kann auch sein das ich bei meinem Systemlogger das eventuell nicht ganz korreckt konfiguriert habe das mit dem Loggen da muss ich mich noch mal genau umsehen. Es sind auch diesmal wieder nur 2 einträge im WoW_debug ordner gelandet.
Also ich hoffe du kannst da etwas mehr draus lesen als ich aus den Einträgen in TCPdump.
.
1. Nö dein jargon stört mich eigentlich nicht, hab mir schon gedacht das du mit ereal Ethreal gemeint hast. Da ich aber auf meinem GentooRechner keinen X-server oder ähnliches laufen hab und ich alles sowieso in die Konsole klopf würde Ethreal oder Wireshark eh net laufen.
2. Danke für die Info. Wusste bisher eigentlich nur das SNAT bei Statischen IPs dem Masqu vorzuziehen ist. SNAT hatte ich auch mal laufen wie ich noch Inet über Kabel hatte. Da hatte ich eine Statische IP und da ging das prima.
3. Hier ein output wie du sagst von den Interesannten stellen.
mal der Verbindungsaufbau und switch zu port 3724
- Code: Alles auswählen
18:43:31.683183 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.161.122.53: 2516+ [1au][|domain]
18:43:31.683241 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.161.122.53: 49677+% [1au][|domain]
18:43:31.683273 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.161.122.53: 31653+% [1au][|domain]
18:43:31.683620 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.161.122.53: 63568+% [1au][|domain]
18:43:31.684344 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.161.122.53: 65113+% [1au][|domain]
18:43:31.714098 PPPoE [ses 0x88d] IP 195.58.161.122.53 > 85.124.0.149.32768: 49677[|domain]
18:43:31.716410 PPPoE [ses 0x88d] IP 195.58.161.122.53 > 85.124.0.149.32768: 31653[|domain]
18:43:31.719190 PPPoE [ses 0x88d] IP 195.58.161.122.53 > 85.124.0.149.32768: 63568[|domain]
18:43:31.721741 PPPoE [ses 0x88d] IP 195.58.161.122.53 > 85.124.0.149.32768: 65113[|domain]
18:43:31.738210 PPPoE [ses 0x88d] IP 195.58.161.122.53 > 85.124.0.149.32768: 2516[|domain]
18:43:31.746103 PPPoE [ses 0x88d] IP 85.124.0.149.1144 > 195.113.150.23.80: S 454643116:454643116(0) win 64240 <mss 1412,nop,nop,[|tcp]>
18:43:31.777341 PPPoE [ses 0x88d] IP 195.113.150.23.80 > 85.124.0.149.1144: S 826982276:826982276(0) ack 454643117 win 5840 <mss 1460,nop,nop,[|tcp]>
18:43:31.778107 PPPoE [ses 0x88d] IP 85.124.0.149.1144 > 195.113.150.23.80: . ack 1 win 64952
18:43:31.790042 PPPoE [ses 0x88d] IP 85.124.0.149.1144 > 195.113.150.23.80: P 1:453(452) ack 1 win 64952
18:43:31.829759 PPPoE [ses 0x88d] IP 195.113.150.23.80 > 85.124.0.149.1144: . ack 453 win 6432
18:43:31.886061 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:31.957856 PPPoE [ses 0x88d] IP 195.113.150.23.80 > 85.124.0.149.1144: P 1:814(813) ack 453 win 6432
18:43:31.968325 PPPoE [ses 0x88d] IP 85.124.0.149.1144 > 195.113.150.23.80: F 453:453(0) ack 814 win 64139
18:43:31.999277 PPPoE [ses 0x88d] IP 195.113.150.23.80 > 85.124.0.149.1144: F 814:814(0) ack 454 win 6432
18:43:31.999935 PPPoE [ses 0x88d] IP 85.124.0.149.1144 > 195.113.150.23.80: . ack 815 win 64139
18:43:33.385583 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 27, length 10
18:43:33.385918 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 27, length 10
18:43:33.886438 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:35.886337 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:37.902248 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:39.902632 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:41.903030 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:43.903171 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:45.903059 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:47.903671 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:48.112259 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 79, length 10
18:43:48.133559 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 79, length 10
18:43:49.903611 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:51.904432 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:53.439836 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.160.194.53: 39860+ [1au][|domain]
18:43:53.466371 PPPoE [ses 0x88d] IP 195.58.160.194.53 > 85.124.0.149.32768: 39860[|domain]
18:43:53.905070 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:54.801578 arp who-has 172.16.12.33 tell 172.16.12.1
18:43:55.904726 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:57.243096 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: S 460960516:460960516(0) win 64240 <mss 1412,nop,nop,[|tcp]>
18:43:57.290877 PPPoE [ses 0x88d] IP 80.239.174.207.80 > 85.124.0.149.1147: S 2195115485:2195115485(0) ack 460960517 win 5840 <mss 1460,nop,nop,[|tcp]>
18:43:57.291633 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: . ack 1 win 64952
18:43:57.297698 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: P 1:114(113) ack 1 win 64952
18:43:57.350970 PPPoE [ses 0x88d] IP 80.239.174.207.80 > 85.124.0.149.1147: . ack 114 win 5840
18:43:57.352361 PPPoE [ses 0x88d] IP 80.239.174.207.80 > 85.124.0.149.1147: P 1:229(228) ack 114 win 5840
18:43:57.503990 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: . ack 229 win 64724
18:43:57.906031 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:43:59.352248 PPPoE [ses 0x88d] IP 80.239.174.207.80 > 85.124.0.149.1147: F 229:229(0) ack 114 win 5840
18:43:59.352977 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: . ack 230 win 64724
18:43:59.906642 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:01.905178 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:02.398980 PPPoE [ses 0x88d] IP 85.124.0.149.1147 > 80.239.174.207.80: R 460960630:460960630(0) win 0
18:44:02.525847 PPPoE [ses 0x88d] IP 85.124.31.67.3151 > 85.124.0.149.445: S 0:0(0) win 64240 <mss 1460,nop,nop,[|tcp]>
18:44:02.526498 PPPoE [ses 0x88d] IP 85.124.0.149.445 > 85.124.31.67.3151: R 0:0(0) ack 1 win 0
18:44:03.906940 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:05.906188 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:07.906076 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:08.113553 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 80, length 10
18:44:08.134827 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 80, length 10
18:44:09.907175 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:11.906832 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:12.013241 PPPoE [ses 0x88d] IP 85.124.0.149.32768 > 195.58.160.194.53: 42656+ [1au][|domain]
18:44:12.041209 PPPoE [ses 0x88d] IP 195.58.160.194.53 > 85.124.0.149.32768: 42656[|domain]
18:44:12.062179 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: S 464664343:464664343(0) win 64240 <mss 1412,nop,nop,[|tcp]>
18:44:12.110084 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: S 3892938659:3892938659(0) ack 464664344 win 5840 <mss 1460,nop,nop,[|tcp]>
18:44:12.110960 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 1 win 64952
18:44:12.204632 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: P 1:46(45) ack 1 win 64952
18:44:12.253173 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . ack 46 win 5840
18:44:12.261042 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: P 1:120(119) ack 46 win 5840
18:44:12.434477 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 120 win 64833
18:44:12.720630 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: P 46:121(75) ack 120 win 64833
18:44:12.785346 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: P 120:146(26) ack 121 win 5840
18:44:12.799071 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: P 121:126(5) ack 146 win 64807
18:44:12.854131 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . 146:1558(1412) ack 126 win 5840
18:44:12.855477 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 1558 win 64952
18:44:12.861056 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . 1558:2970(1412) ack 126 win 5840
18:44:12.862419 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 2970 win 64952
18:44:12.911176 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . 2970:4382(1412) ack 126 win 5840
18:44:12.912507 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 4382 win 64952
18:44:12.917868 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . 4382:5794(1412) ack 126 win 5840
18:44:12.919198 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 5794 win 64952
18:44:12.924368 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: . 5794:7206(1412) ack 126 win 5840
18:44:12.925668 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 7206 win 64952
18:44:12.929697 PPPoE [ses 0x88d] IP 80.239.178.113.3724 > 85.124.0.149.1148: P 7206:8286(1080) ack 126 win 5840
18:44:12.933945 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: S 464915075:464915075(0) win 64240 <mss 1412,nop,nop,[|tcp]>
18:44:12.973416 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: S 1802927400:1802927400(0) ack 464915076 win 5840 <mss 1460,nop,nop,[|tcp]>
18:44:12.974186 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: . ack 1 win 64952
18:44:13.013103 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 1:9(8) ack 1 win 5840
18:44:13.043877 PPPoE [ses 0x88d] IP 85.124.0.149.1148 > 80.239.178.113.3724: . ack 8286 win 63872
18:44:13.101442 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 1:177(176) ack 9 win 64944
18:44:13.144329 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 177 win 6432
18:44:13.178668 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 9:23(14) ack 177 win 6432
18:44:13.348583 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: . ack 23 win 64930
18:44:13.387866 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 23:115(92) ack 177 win 6432
18:44:13.551712 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: . ack 115 win 64838
18:44:13.689010 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 177:183(6) ack 115 win 64838
18:44:13.767913 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 183 win 6432
18:44:13.907443 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:44:14.171981 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 115:958(843) ack 183 win 6432
18:44:14.364266 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: . ack 958 win 63995
18:44:15.649112 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 958:999(41) ack 183 win 6432
18:44:15.652570 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 183:190(7) ack 999 win 63954
18:44:15.691326 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 190 win 6432
18:44:15.849501 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: P 999:1506(507) ack 190 win 6432
und die Pakte vor verbindungsabbruch
- Code: Alles auswählen
18:51:20.489103 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25800 win 9192
18:51:21.392000 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25800:25834(34) ack 60792 win 64192
18:51:21.432728 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25834 win 9192
18:51:22.042795 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:22.058028 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25834:25868(34) ack 60792 win 64192
18:51:22.098267 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25868 win 9192
18:51:22.432056 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25868:25902(34) ack 60792 win 64192
18:51:22.471662 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25902 win 9192
18:51:22.932362 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25902:25936(34) ack 60792 win 64192
18:51:22.973024 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25936 win 9192
18:51:23.222538 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25936:25970(34) ack 60792 win 64192
18:51:23.261262 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 25970 win 9192
18:51:23.264225 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 25970:26004(34) ack 60792 win 64192
18:51:23.303449 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26004 win 9192
18:51:23.427943 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26004:26038(34) ack 60792 win 64192
18:51:23.468367 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26038 win 9192
18:51:23.844614 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26038:26088(50) ack 60792 win 64192
18:51:23.884611 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26088 win 9192
18:51:24.042929 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:24.372735 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26088:26138(50) ack 60792 win 64192
18:51:24.413568 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26138 win 9192
18:51:24.697258 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26138:26172(34) ack 60792 win 64192
18:51:24.738461 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26172 win 9192
18:51:26.042622 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:28.042982 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:28.141001 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 102, length 10
18:51:28.162734 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 102, length 10
18:51:30.044781 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:32.043267 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:33.515693 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 35, length 10
18:51:33.516035 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 35, length 10
18:51:34.043674 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:36.043561 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:38.043500 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:40.043627 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:42.050057 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:44.050648 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:46.051262 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:47.555267 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26172:26186(14) ack 60792 win 64192
18:51:47.594661 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: R 1802988192:1802988192(0) win 0
18:51:48.051872 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
18:51:48.142192 PPPoE [ses 0x88d] LCP, Echo-Request (0x09), id 103, length 10
18:51:48.164176 PPPoE [ses 0x88d] LCP, Echo-Reply (0x0a), id 103, length 10
Also Icmp is nicht fiel unterwegs muss ich sagen. Was ich so sehe gehen die auch korekt durch.
Aber diese Zeilen
18:44:41.911130 00:0f:24:dd:47:0c > 01:00:0c:cc:cc:cd SNAP Unnumbered, ui, Flags [Command], length 50
die irritieren mich. Da weis ich überhaupt nicht was das sein soll.
4. Ja die von deinem WoW_debug log waren nicht gekürzt. I hab leider die Einträge bei den log-prefixen einwenig kürzen müssen weil da laut meinem Iptales nur 29 Zeichen zulässig sind.
Es waren 3 versuche.
Es kann auch sein das ich bei meinem Systemlogger das eventuell nicht ganz korreckt konfiguriert habe das mit dem Loggen da muss ich mich noch mal genau umsehen. Es sind auch diesmal wieder nur 2 einträge im WoW_debug ordner gelandet.
Also ich hoffe du kannst da etwas mehr draus lesen als ich aus den Einträgen in TCPdump.
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
von zid » Di 08 Aug, 2006 21:54
weiß auch nicht, was diese meldungen bedeuten. habe kurz mit der fehlermeldung ("SNAP Unnumbered, ui, Flags") herumgegoogelt. nur 1 genauer treffer. da hat einer 2 vlans über eine bridge verbunden, das ist schiefgegangen und hat die gleichen fehlermeldungen erzeugt -> dürften also nix gutes bedeuten (schau den thread [link=http://www.candelatech.com/pipermail/vlan/2006-May/000682.html]hier [/link] an, vielleicht kannst was damit anfangen).
in diesem zusammenhang:
wie sind d. lokalen ip-addr. von eth1 und modem? kriegst du mit
ifconfig -a
arp -n
was ist als gateway f. eth1 eingetragen?
masq. schaut gut aus, werde mir noch die seqs. noch genauer anschauen. trotzdem wären mir d. fw. logs wichtig. wenn du probleme m. d. syslog hast, dann ändere d. log-level auf den wert, den du immer verwendest, sodaß die meldungen dann i. d. normale log. datei wandern, wird ja nicht ewig dauern.
in diesem zusammenhang:
wie sind d. lokalen ip-addr. von eth1 und modem? kriegst du mit
ifconfig -a
arp -n
was ist als gateway f. eth1 eingetragen?
masq. schaut gut aus, werde mir noch die seqs. noch genauer anschauen. trotzdem wären mir d. fw. logs wichtig. wenn du probleme m. d. syslog hast, dann ändere d. log-level auf den wert, den du immer verwendest, sodaß die meldungen dann i. d. normale log. datei wandern, wird ja nicht ewig dauern.
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von zid » Mi 09 Aug, 2006 13:45
seehr aufschlußreich dein tcpdump, ein zarter tcpdump sagt mehr als tausend worte...
im detail:
1.
zuerst werden 2 http conversations geführt, start o.k., sequence o.k., abschluß o.k.
dann v. dir verbindung zu spielerechner 80.239.178.113, port 3724. du schlägst vor mss=1412, server kommt mit mss=1460 zurück, also mss=1412. nach anfangsgeplänkel geht's zur sache, d. server schaufelt d. daten m. mss über d. verbindung, dein rechner- auch nicht fad- verarbeitet gleich alles, window size bleibt const. a. satten 64952, seq. ok., keine überkreuzungen, nix.
während diese verbindung noch steht, wird v. spieleclient eine 2. verbindung z. e. anderen server (80.239.233.100) aufgebaut, keine dns abfrage (client weiß schon alles), wieder port 3724, wieder mss=1412. hier geht es viel gemächlicher zu: anfangsgeplänkel und danach alle paar zehntel sek. ein 34 byte paketerl v. client, server bestätigt, sendet nicht und verarbeitet d. packets sofort, window size const. 9192. dürfte sich um eine kontroll- od. steuerverbindung handeln? kannst du nachschauen, ob d. 1. verbindung z. diesem zeitpunkt noch steht?
ja und dann kommt's:
18:51:24.697258 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26138:26172(34) ack 60792 win 64192
18:51:24.738461 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26172 win 9192
18:51:47.555267 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26172:26186(14) ack 60792 win 64192
18:51:47.594661 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: R 1802988192:1802988192(0) win 0
du schickst um 18:51:24.69... ein 34 byte packet, die bestätigung d. servers kommt 0,04 s später, danach 23 s sendepause, dann ein 14 byte packet von dir und d. server dreht ab, kein FIN, sondern RST.
mögliche erklärungen, die mir dazu einfallen:
i. dein letztes packet und d. RST kreuzen sich, d. server ist nach 23 wartezeit d. hintern eingeschlafen und er haut d. hut drauf, du rennst i. e. timeout (stell dir vor, so ein viel beschäftigter server muß bei jedem spieler 23 s auf eine kontrollnachricht warten, da geht ja gar nix weiter...).
ii. d. 14 byte packet behagt d. server so wenig, daß er nicht "gracefully" mit FIN schließt, sondern gleich d. tür zuhaut. was schickst du ihm da für 'ne schweinerei?
momentan nicht so wichtig: sehe noch e. verbindungsversuch von außen auf port 445 (ms-ds) wird m. e. RST beantwortet. schläft d. firewall?
2.
18:43:54.801578 arp who-has 172.16.12.33 tell 172.16.12.1
was ist daas? junge, junge dein netzwerk ist immer gut für überraschungen. wieviel lans, vlans, spanning trees hast du da hineingelegt? broadcast wird nicht beantwortet, oder besser gesagt antwort läuft nicht über eth1, d.h. 172.16.12.33 gibt's nicht bei dir, wer aber ist 172.16.12.1? modem?
3.
geschichte m. syslog rätselhaft. syslog schert sich nicht um inhalte, sondern nur um facility u. priority. wenn 1 log nach WoW_debug geschrieben wird, dann sollten alle dort landen. wahrscheinlich habe ich in meinem wahn die log regeln falsch plaziert. kannst du das bitte checken? werde deine tabs auch laden und mir das ganze in natura anschauen.
4.
fazit: glaube nicht mehr a. e. masq. prob (ablauf wie i. lehrbuch), client dürfte d. gauner sein. sollten uns überlegen, wie wir ihm auf die schliche kommen. hast du ereal b. d. test auf d. spielerechner laufen lassen und die aufzeichnungen gespeichert? kannst du nachschauen, was i. d. 34 byte packet und i. d. 14 byte packet steht?
bis bald
zid
im detail:
1.
zuerst werden 2 http conversations geführt, start o.k., sequence o.k., abschluß o.k.
dann v. dir verbindung zu spielerechner 80.239.178.113, port 3724. du schlägst vor mss=1412, server kommt mit mss=1460 zurück, also mss=1412. nach anfangsgeplänkel geht's zur sache, d. server schaufelt d. daten m. mss über d. verbindung, dein rechner- auch nicht fad- verarbeitet gleich alles, window size bleibt const. a. satten 64952, seq. ok., keine überkreuzungen, nix.
während diese verbindung noch steht, wird v. spieleclient eine 2. verbindung z. e. anderen server (80.239.233.100) aufgebaut, keine dns abfrage (client weiß schon alles), wieder port 3724, wieder mss=1412. hier geht es viel gemächlicher zu: anfangsgeplänkel und danach alle paar zehntel sek. ein 34 byte paketerl v. client, server bestätigt, sendet nicht und verarbeitet d. packets sofort, window size const. 9192. dürfte sich um eine kontroll- od. steuerverbindung handeln? kannst du nachschauen, ob d. 1. verbindung z. diesem zeitpunkt noch steht?
ja und dann kommt's:
18:51:24.697258 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26138:26172(34) ack 60792 win 64192
18:51:24.738461 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: . ack 26172 win 9192
18:51:47.555267 PPPoE [ses 0x88d] IP 85.124.0.149.1149 > 80.239.233.100.3724: P 26172:26186(14) ack 60792 win 64192
18:51:47.594661 PPPoE [ses 0x88d] IP 80.239.233.100.3724 > 85.124.0.149.1149: R 1802988192:1802988192(0) win 0
du schickst um 18:51:24.69... ein 34 byte packet, die bestätigung d. servers kommt 0,04 s später, danach 23 s sendepause, dann ein 14 byte packet von dir und d. server dreht ab, kein FIN, sondern RST.
mögliche erklärungen, die mir dazu einfallen:
i. dein letztes packet und d. RST kreuzen sich, d. server ist nach 23 wartezeit d. hintern eingeschlafen und er haut d. hut drauf, du rennst i. e. timeout (stell dir vor, so ein viel beschäftigter server muß bei jedem spieler 23 s auf eine kontrollnachricht warten, da geht ja gar nix weiter...).
ii. d. 14 byte packet behagt d. server so wenig, daß er nicht "gracefully" mit FIN schließt, sondern gleich d. tür zuhaut. was schickst du ihm da für 'ne schweinerei
?
momentan nicht so wichtig: sehe noch e. verbindungsversuch von außen auf port 445 (ms-ds) wird m. e. RST beantwortet. schläft d. firewall?
2.
18:43:54.801578 arp who-has 172.16.12.33 tell 172.16.12.1
was ist daas? junge, junge dein netzwerk ist immer gut für überraschungen. wieviel lans, vlans, spanning trees hast du da hineingelegt? broadcast wird nicht beantwortet, oder besser gesagt antwort läuft nicht über eth1, d.h. 172.16.12.33 gibt's nicht bei dir, wer aber ist 172.16.12.1? modem?
3.
geschichte m. syslog rätselhaft. syslog schert sich nicht um inhalte, sondern nur um facility u. priority. wenn 1 log nach WoW_debug geschrieben wird, dann sollten alle dort landen. wahrscheinlich habe ich in meinem wahn die log regeln falsch plaziert. kannst du das bitte checken? werde deine tabs auch laden und mir das ganze in natura anschauen.
4.
fazit: glaube nicht mehr a. e. masq. prob (ablauf wie i. lehrbuch), client dürfte d. gauner sein. sollten uns überlegen, wie wir ihm auf die schliche kommen. hast du ereal b. d. test auf d. spielerechner laufen lassen und die aufzeichnungen gespeichert? kannst du nachschauen, was i. d. 34 byte packet und i. d. 14 byte packet steht?
bis bald
zid
- zid
- Board-User Level 3
- Beiträge: 1080
- Registriert: Fr 23 Jun, 2006 09:08
- Wohnort: wien
von jutta » Mi 09 Aug, 2006 14:13
zid hat geschrieben:2.
18:43:54.801578 arp who-has 172.16.12.33 tell 172.16.12.1
was ist daas? junge, junge dein netzwerk ist immer gut für überraschungen. wieviel lans, vlans, spanning trees hast du da hineingelegt? broadcast wird nicht beantwortet, oder besser gesagt antwort läuft nicht über eth1, d.h. 172.16.12.33 gibt's nicht bei dir, wer aber ist 172.16.12.1? modem?
dazu als erklaerung ein link, den ich heute schon zweimal gepostet habe: http://xDSL.at/new/viewtopic.php?t=33723
- jutta
- Administrator
- Beiträge: 30485
- Registriert: Do 15 Apr, 2004 10:48
- Wohnort: wien
von TroubleWolf » Mi 09 Aug, 2006 17:54
@jutta
Hab da mal rumgelesen in dem Beitrag. Die 172* IP is also von der Bridge wenn ich das richtig verstanden hab. Die gehören doch zu nem Privaten Addressbereich. In meiner Firewall gibts ne Regel die CLASSB=172.16.0.0/12 bei INPUT rausschmeisst. Irgendwie denk ich mir mal das da eure Pakte von der Bridge auch rausfliegen dann. Das is nicht so gut oder? Oder habt ihr in dem 172.16.0.0/12er bereich eh keine Adresse in verwendung?
@zid
Hier mal der output von ifconfig -a
arp -n gibt folgendes
und hier output von route -n
1.
Das letzte Paket von der ersten Verbindung hört mit RST auf dann wird eine DNS abfrage abgeschickt und dann wird der port um 1 erhöt und auf ne andere IP geswitch. Da laufen auch ein paar Pakte hin und her und dann wird die Portnummer wieder um 1 erhöt und auf die IP des Spieleserversgeswitcht. Für die zweite Verbindung find ich aber kein RST Paket bei meinem Ethreal auf dem SpielPC und es werden auch dann keine weiteren Pakete mehr gesendet oder empfangen an die IP komisch.
Und ich veschick keine schweinereien
2.
Ja siehe beitrag von jutta
3.
Hab mal das loggen in den normalen log laufen lassen sprich in die messages da kommen auch nur wieder die 2 einträge. Mal sehen ob ich sie wo anders unterbringen sollte in meiner FW.
4. Seh da keinen großen unterschied bei den einträgen zwischen den 34ern und den 14ener Pakten auser in der größe. Gibts da was auf was ich achten sollte ?
Edit:
Hab hier noch ne kleine erklärung was das SNAP sein soll. Siehe Link
http://www.netzmafia.de/skripten/netze/netz4.html
bisi runterscrollen dann siehst es eh gleich. Aber was die Pakete da bei mir machen erklärt das auch nicht.
Hab da mal rumgelesen in dem Beitrag. Die 172* IP is also von der Bridge wenn ich das richtig verstanden hab. Die gehören doch zu nem Privaten Addressbereich. In meiner Firewall gibts ne Regel die CLASSB=172.16.0.0/12 bei INPUT rausschmeisst. Irgendwie denk ich mir mal das da eure Pakte von der Bridge auch rausfliegen dann. Das is nicht so gut oder? Oder habt ihr in dem 172.16.0.0/12er bereich eh keine Adresse in verwendung?
@zid
Hier mal der output von ifconfig -a
- Code: Alles auswählen
eth0 Protokoll:Ethernet Hardware Adresse 00:04:75:DF:05:C3
inet Adresse:192.168.0.1 Bcast:192.168.0.255 Maske:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:10 Basisadresse:0x6f80
eth1 Protokoll:Ethernet Hardware Adresse 00:02:44:98:BF:A7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4705 errors:0 dropped:0 overruns:0 frame:0
TX packets:3479 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:3342168 (3.1 Mb) TX bytes:722331 (705.4 Kb)
Interrupt:9 Basisadresse:0xdc00
eth2 Protokoll:Ethernet Hardware Adresse 00:E0:7D:C0:3E:1B
inet Adresse:192.168.2.1 Bcast:192.168.2.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4128 errors:0 dropped:0 overruns:0 frame:0
TX packets:4332 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:726193 (709.1 Kb) TX bytes:3224204 (3.0 Mb)
Interrupt:5 Basisadresse:0xda00
gre0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-EA-B7-17-4E-00-00-00-00-00-00-00-00
NOARP MTU:1476 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:10134 (9.8 Kb) TX bytes:10134 (9.8 Kb)
ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:85.124.148.164 P-z-P:172.25.46.73 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3885 errors:0 dropped:0 overruns:0 frame:0
TX packets:3131 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:3205598 (3.0 Mb) TX bytes:642966 (627.8 Kb)
tunl0 Protokoll:IPIP Tunnel Hardware Adresse
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
arp -n gibt folgendes
- Code: Alles auswählen
Address HWtype HWaddress Flags Mask Iface
192.168.2.20 ether 00:E0:7D:xx:xx:xx C eth2
und hier output von route -n
- Code: Alles auswählen
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.25.46.73 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
0.0.0.0 172.25.46.73 0.0.0.0 UG 0 0 0 ppp0
1.
Das letzte Paket von der ersten Verbindung hört mit RST auf dann wird eine DNS abfrage abgeschickt und dann wird der port um 1 erhöt und auf ne andere IP geswitch. Da laufen auch ein paar Pakte hin und her und dann wird die Portnummer wieder um 1 erhöt und auf die IP des Spieleserversgeswitcht. Für die zweite Verbindung find ich aber kein RST Paket bei meinem Ethreal auf dem SpielPC und es werden auch dann keine weiteren Pakete mehr gesendet oder empfangen an die IP komisch.
Und ich veschick keine schweinereien
2.
Ja siehe beitrag von jutta
3.
Hab mal das loggen in den normalen log laufen lassen sprich in die messages da kommen auch nur wieder die 2 einträge. Mal sehen ob ich sie wo anders unterbringen sollte in meiner FW.
4. Seh da keinen großen unterschied bei den einträgen zwischen den 34ern und den 14ener Pakten auser in der größe. Gibts da was auf was ich achten sollte ?
Edit:
Hab hier noch ne kleine erklärung was das SNAP sein soll. Siehe Link
http://www.netzmafia.de/skripten/netze/netz4.html
bisi runterscrollen dann siehst es eh gleich. Aber was die Pakete da bei mir machen erklärt das auch nicht.
- TroubleWolf
- Neu im Board
- Beiträge: 16
- Registriert: So 23 Jul, 2006 18:35
34 Beiträge
• Seite 2 von 3 • 1, 2, 3
Zurück zu LINUX & UNIX-DERIVATE
Wer ist online?
Mitglieder in diesem Forum: Yandex [Crawler] und 22 Gäste