Schon wieder Port Forwarding mit IPTABLES (Linux)

Anonym · 5. September 2003 um 22:22

So, ich habe die „Firewall“ die eigentlich nichts anderes
macht als ein paar IPTABLES Regeln zu schreiben wieder
aktiviert, jetzt klappt das Routing wieder. Ich werf Dir
einfach mal die Ausgaben vor, die er auspuckt auf die 3
Befehle, die ich von Dir habe. Hoffe, Du kannst mir was dazu
sagen.
Ich habe die eMule Ports wieder eingebunden (nach Neustart)
via Script, aber der connection Test sagt mir, dass die Pakete
von der Firewall abgefangen werden. Obwohl ich die Ports
eigentlich (via YAST2 GUI) freigegeben hatte (*PATSCH* Dein Supportvertrag mit diesem Forum ist soeben abgelaufen.

Sag mal, sonst geht’s Dir noch!? Mag ja sein, dass ich gestern irgendwie den Eindruck von guter Laune oder Langeweile erweckt hab, aber ich werde mich jetzt bestimmt nicht durch 180 Zeilen Filterregeln wuehlen, die Du, ohne gross drueber nachzudenken, vom YaST zusammenkleistern hast lassen. Oder gibt es einen tieferen Grund, dass in Deinem Paketfilter das encapsulated security payload beruecksichtigt wird? Was hast Du Dir bei den ganzen Markierungen an den Paketen gedacht? Warum mangle’st Du an den ganzen type of service rum?

Bitte, fuer so ein Monster faengst Du selber an, nachzudenken. Auch, wenn ich inzwischen schon ziemlich eingekreist, woran es liegt (AFAICS erlaubst Du nur ausgehend neue Verbindungen. Deine eMule-Regeln werden gar nicht durchlaufen.), wenn ich Dir das jetzt sage, bist Du naechste Woche mit einem aehnlichen Problem da.

webserver:/home/webserver # route -n
[snip]
webserver:/home/webserver # cat /proc/sys/net/ipv4/ip_forward
1
webserver:/home/webserver # iptables-save
[~180 mal snip]

Kopfschuettelnd,
Gruss vom Zentrum.

Marcus_Scholz_f35377 · 6. September 2003 um 02:09

*PATSCH* Dein Supportvertrag mit diesem Forum ist
soeben abgelaufen.

Danke! Nur weil man von Windows auf ein verlässliches Routersystem wie Linux umsteigen will (von dem man halt noch keinen so tiefen Durchblick hat) bekommt man gleich so einen Scheiss ins Gesicht geballert!

Sag mal, sonst geht’s Dir noch!? Mag ja sein, dass ich
gestern irgendwie den Eindruck von guter Laune oder Langeweile
erweckt hab, aber ich werde mich jetzt bestimmt nicht durch
180 Zeilen Filterregeln wuehlen, die Du, ohne gross drueber
nachzudenken, vom YaST zusammenkleistern hast lassen.

Bitte nimm einmal an, dass Du von dem Dir scheinbar sehr vertrauten Linux auf ein komplett anders strukturiertes Betriebsystem umsteigen willst (und sei es auch nur eins, bei dem man die Fenster nach Form und Farbe deutet), was würdest Du zuerst machen? Wahllos in irgendwelchen Konfigurationsdateien rumpfuschen? Oder lieber ein sich Dir anbiederndes GUI in Anspruch nehmen? Vielen Dank für Dein Verständnis!
Ich weiss selbst nicht, was YAST2 bzw. SuSEfirewall2 sich da zusammenstrickt, aber das Routing funktioniert zumindest erst mal nach dessen Änderungen. Ich verlange ja gar nicht, Dich durch 180 (?) Zeilen Code durchzuwühlen, es hätte ja sein können, dass Dir beim Überfliegen der Zeilen etwas spontan ins Auge gefallen wäre - was es ja scheinbar nicht ist!

Oder gibt es einen tieferen Grund, dass in Deinem Paketfilter das
encapsulated security payload beruecksichtigt wird?

Bitte was? Formulier das mal bitte in der Sprache von bunten Fensterchen? Form, Farbe, Position bitte!

Was hast Du Dir bei den ganzen Markierungen an den Paketen gedacht?

nichts? Copy & Paste aus Verzweiflung?

Warum mangle’st Du an den ganzen type of service rum?

hä?

Bitte, fuer so ein Monster faengst Du selber an, nachzudenken.
Auch, wenn ich inzwischen schon ziemlich eingekreist (hatte), woran
es liegt (AFAICS erlaubst Du nur ausgehend neue Verbindungen.
Deine eMule-Regeln werden gar nicht durchlaufen.)

obwohl ich sie anhand dieses Scriptes eingebunden hatte! Vielleicht ist das ja schon der Schwachpunkt von YAST2? bzw. der Firewall? oder der ITABLES Konfiguration? (natürlich mit chmod 700)

#! /bin/sh
#iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 4242 -j DNAT --to 192.168
#iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 4242 -j DNAT --to 192.168
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 4661 -j DNAT --to 192.168.
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 4661 -j DNAT --to 192.168.
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 4662 -j DNAT --to 192.168.
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 4662 -j DNAT --to 192.168.
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 4665 -j DNAT --to 192.168.
iptables -t nat -A PREROUTING -i ppp0 -p udp --dport 4665 -j DNAT --to 192.168.

iptables -A FORWARD -i ppp0 -p tcp --dport 4662 -j ACCEPT
iptables -A FORWARD -i ppp0 -p udp --dport 4662 -j ACCEPT
iptables -A FORWARD -i ppp0 -p udp --dport 4661 -j ACCEPT
iptables -A FORWARD -i ppp0 -p tcp --dport 4661 -j ACCEPT
iptables -A FORWARD -i ppp0 -p udp --dport 4665 -j ACCEPT
iptables -A FORWARD -i ppp0 -p tcp --dport 4665 -j ACCEPT
#iptables -A FORWARD -i ppp0 -p tcp --dport 4242 -j ACCEPT
#iptables -A FORWARD -i ppp0 -p udp --dport 4242 -j ACCEPT

, wenn ich Dir das jetzt sage, bist Du naechste Woche mit einem
aehnlichen Problem da.

Sehe ich aus wie ein Erstklässler in der Grundschule der nur vorgescriptete Eingaben in seine Linux Box einhackt ohne nachzudenken? Ich dachte eigentlich nicht… aber wenn Du meinst! Danke für das Verständnis für einen n00b!

webserver:/home/webserver # route -n
[snip]
webserver:/home/webserver # cat /proc/sys/net/ipv4/ip_forward
1
webserver:/home/webserver # iptables-save
[~180 mal snip]

Kopfschuettelnd,

Genauso sitze ich auch vor der Linux Kiste und vor Deinen sehr mitfühlenden Kommentaren!

Gruss vom Zentrum.

Anonym · 6. September 2003 um 18:42

Ich antworte mal hier, weil ich das Quoting Deiner Regeln brauche.

So, ich habe die „Firewall“ die eigentlich nichts anderes
macht als ein paar IPTABLES Regeln zu schreiben wieder
aktiviert, jetzt klappt das Routing wieder. Ich werf Dir
einfach mal die Ausgaben vor , die er auspuckt auf die 3
Befehle, die ich von Dir habe. Hoffe, Du kannst mir was dazu
sagen.

Ich hab dir die Worte markiert, mit denen Du maechtig daneben gegriffen hast. Du bist nicht im mindesten bereit, Dir 'ne Platte zu machen ueber das, was YaST da verzapft hat, erwartest aber, dass ich das jetzt tue.

bin ja ein Windows n00b

Das ist 'ne ganz miese Aussrede. Ich hab ein paar Monate gebraucht, bis ich netfilter kapiert hab. (Das lag vielleicht auch daran, dass ich mir gleichzeitig noch TCP/IP anlesen musste). Das soll ich Dir jetzt in ein paar Minuten ueber so ein Webforum erklaeren?

Vielleicht (hoffentlich) kannst Du mir was dazu sagen.

Ich erklaere Dir, wo Deine Pakete haengen bleiben. Vielleicht lernst Du dann auch ein wenig, wie ein Paket durch solche Regeln laeuft, dass scheint naemlich Dein Hauptproblem zu sein.

|ich bin ein eMule-Paket von 0/0:4661 und gehe an Deine externe |
|IP EXTIP:4661 |


> webserver:/home/webserver # iptables-save  
> [Quark]  
> # Completed on Fri Sep 5 21:36:53 2003  
> # Generated by iptables-save v1.2.7a on Fri Sep 5 21:36:53  
> 2003  
> \*nat  
> 
> > PREROUTING ACCEPT [51592:2219229]  
> > POSTROUTING ACCEPT [768:81475]  
> > OUTPUT ACCEPT [863:87856]
> 
> -A PREROUTING -i ppp0 -p udp -m udp --dport 4661 -j DNAT --to-destination 192.168.0.3

|hier krieg ich als Ziel 192.168.0.3 in den Header geschrieben, ich |
|bin jetzt also von 0/0:4661 und gehe an .0.3:4661, weiter geht's in |
|die FORWARD chain |


> [mehr eMule-Kram]  
> -A POSTROUTING -o ppp0 -j MASQUERADE  
> COMMIT  
> # Completed on Fri Sep 5 21:36:53 2003  
> # Generated by iptables-save v1.2.7a on Fri Sep 5 21:36:53  
> 2003  
> \*filter  
> 
> > INPUT DROP [0:0]  
> > FORWARD DROP [0:0]

|die policy DROP passiert mir, wenn ich nicht irgendwo anders vorher |
|matche |


> [viel Quark, den Du dringend verstehen solltest]  
> -A FORWARD -i ppp0 -j forward\_ext

|ich bin von aussen (ppp0) reingekommen und werde deshalb in die |
|forward\_ext geschickt |


> -A FORWARD -i eth0 -j forward\_int  
> -A FORWARD -j LOG --log-prefix "SuSE-FW-ILLEGAL-ROUTING " --log-tcp-options --log-ip-options  
> -A FORWARD -j DROP

Hier matchen alle Pakete, die in die FORWARD gekommen sind. Alles, was ab hier noch in dieser Kette steht wird nie erreicht.

> [komplett nutzloses Zeugs]  
> [unwichtige OUTPUT]  
> [unwichtige forward\_dmz]  
> [unwichtiges aus forward\_ext]  
> -A forward\_ext -o ppp0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

|wuerde ich nach draussen (ppp0) wollen haette ich hier den |
|Freifahrtschein |


> -A forward\_ext -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT

|wuerde ich von draussen (ppp0) kommen und zu einer bestehenden |
|Verbindung gehoeren (RELATED,ESTABLISHED) waere ich durch, zu dumm, |
|das ich NEW bin |


> [noch mehr Zeugs mit -j LOG]  
> -A forward\_ext -j DROP

|hier werde ich leider ins Nirvana entsorgt \_\_\__oergs_\_\_\_ |


> [mehr Zeugs, dass ich jetzt nicht lesen will.]

Und was tust Du jetzt? Ich werd mich hueten, Dir zu sagen, wo Du Deine Regeln dazustecken musst, weil das gesamte Geruest jedem Konzept wiederspricht, das ich jemals umgesetzt haette. Ausserdem waere das IHMO aeusserst kontraproduktiv, weil Du scheinbar gar nicht kapiert hast, wie dieses Monster laeuft, geschweige denn netfilter ueberhaupt. Wenn Dir die SuSE-Leute nicht die Werkzeuge (Tools, Dokumentation) gegeben haben, um eigene Regeln in dieses Ding einzubasteln wirst Du Dir wohl die Muehe machen, es doch zu lernen und ohne Hilfsmittel auszukommen. Die wirlich gute Dokumentation hab ich hinreichend propagandiert. Bei konkreten Fragen bist Du willkommen, aber ‚Geht nicht, hier guckt mal.‘ ist total mies.

EOT,
Gruss vom Zentrum.