Am Samstag, 7. Juni 2003 19:18 schrieb

Am Samstag, 7. Juni 2003 20:02 schrieb Christian Schneider: linux@haedicke.homelinux.com:

...

Kannst Du mir mal sagen was NAT überhaupt heißt und wozu es gut ist? Dann helfe ich Dir erst weiter. Ich habe nämlich das Gefühl das Du uns hier am verarschen bist!

ich glaube hier kann ich helfen: Network Address Translation (NAT) entspricht IP Masquerading.

'Troll Candidate 2' ??? *SCNR* -- Andreas Scherer <andreas.scherer@lingua.at> Reg. LinuxUser #157823 EDV-Dienstleistungen Scherer Tel.: +43 2735 77144 http://www.lingua.at - http://www.scherer.co.at

OK, OK, peinlich... Tut mir leid, ich habe eben erst die Mailingliste abonniert und den Anfang nicht ganz mitbekommen. Ich dachte die Frage sei ernst gemeint. Am Samstag, 7. Juni 2003 21:05 schrieb Matthias Houdek:

[Christian Schneider]:

...

Hi,

ich glaube hier kann ich helfen: Network Address Translation (NAT) entspricht IP Masquerading.

Ich glaub, das wusste Frank auch schon alleine, evtl. sogar besser (NAT != IP-Masquerading, NAT ist mehr). Darum ging es hier auch nicht, sondern darum, dass MS sich erst mal über Grundlegendes informieren sollte, bevor er Spezielles dazu fragt.

[ ... TOFU mal wieder entsorgt ... ]

Am Samstag, 7. Juni 2003 23:00 schrieb Joerg Rossdeutscher:

In Kurzform: Wenn du einen Suse-Rechner als Router benutzt UND gleichzeitig beispielsweise einen Webserver drauf laufen hast, kommen die Clients im lokalen Netz nicht auf die externen Dienste des Servers.

Einfach gesagt:

Client= 192.168.0.2

Server =192.168.0.1 und 111.222.111.222 ("www.domain.foo")

...dann können die Clients sich die Website unter http://192.168.0.1 angucken, aber mit http://www.domain.foo kommt -nichts-. Für alle Dienste. Daher setze ich die SuseFW2 zukünftig nicht mehr ein.

Die FW2 setzt die notwendigen Regeln nicht.

Als kleines Workaround könntest Du auf Deinen Clienten ja folgende Zeile in die 'hosts' aufnehmen. 192.168.0.1 www.domain.foo und schon klappt es auch local. ;-) Das heissst auch 'Virtuelle Server' klappen! ;-) lg, -- Andreas Scherer <andreas.scherer@lingua.at> Reg. LinuxUser #157823 EDV-Dienstleistungen Scherer Tel.: +43 2735 77144 http://www.lingua.at - http://www.scherer.co.at

[Joerg Rossdeutscher]:

Moin,

Am Sam, 2003-06-07 um 21.05 schrieb Matthias Houdek:

...

Ich glaub, das wusste Frank auch schon alleine, evtl. sogar besser (NAT != IP-Masquerading, NAT ist mehr). Darum ging es hier auch nicht, sondern darum, dass MS sich erst mal über Grundlegendes informieren sollte, bevor er Spezielles dazu fragt.

Ist halt ein bescheidenes Problem mit der SuseFirewall2, das mir absolut nicht in den Kopf will, warum das nicht endlich mal gefixt wird...

In Kurzform: Wenn du einen Suse-Rechner als Router benutzt UND gleichzeitig beispielsweise einen Webserver drauf laufen hast, kommen die Clients im lokalen Netz nicht auf die externen Dienste des Servers.

Einfach gesagt:

Client= 192.168.0.2

Server =192.168.0.1 und 111.222.111.222 ("www.domain.foo")

...dann können die Clients sich die Website unter http://192.168.0.1 angucken, aber mit http://www.domain.foo kommt -nichts-. Für alle Dienste. Daher setze ich die SuseFW2 zukünftig nicht mehr ein.

Die FW2 setzt die notwendigen Regeln nicht.

Nö, das Problem ist ein anderes: bei http://192.168.0.1 gehe ich nicht über die Firewall, bei http://www.domain.foo schon, weil der Name ja in die externe IP-Adresse aufgelöst wird (111.222.111.222). Und wenn die Firewall dafür nicht freigeschaltet ist, komme ich so auch nicht auf meinen eigentlich lokalen Rechner. Mach eine lokale Namensauflösung für www.domain.foo, und schon sollte es funxen. -- Gruß MaxX

Am Son, 2003-06-08 um 13.03 schrieb Michael Meyer:

Joerg Rossdeutscher wrote:

...

Ist halt ein bescheidenes Problem mit der SuseFirewall2, das mir absolut nicht in den Kopf will, warum das nicht endlich mal gefixt wird...

it's not a bug, it's a feature.

It's shit. :-)

...

...dann können die Clients sich die Website unter http://192.168.0.1 angucken, aber mit http://www.domain.foo kommt -nichts-. Für alle Dienste.

das ist eine anti-spoofing-regel, die dir da in die quere kommt. in [1] wird dir in abschnitt 8.1.6 die lösung präsentiert.

Ja, kenne ich, ich war schon von allein drauf gekommen. Finde ich Müll. Das leitet _alle_ internen Anfragen auf das externe Interface auf ACCEPT. Das will ich nicht. Also fange ich an, einen ganzen Stapel Regeln einzubauen: Anfrage OK für http. Für ftp. Für DNS. Für POP3. Für SMTP. Für... Wenn ich eine komplette Route für diverse Services selbst einbauen muß, dann besorge ich mir lieber eine andere FW. Genau die Aufgabe sollte mir die FW2 ja eigentlich abnehmen, indem ich einfach nur "ftp,http,bind,pop3" in eine Configdatei schreiben muß. Das Gewurschtel mit teilweise Sachen in die Configdatei schreiben und teilweise "pures" iptables geht mir zu sehr durcheinander. Man muß zur Ehrenrettung der FW2 sagen, daß andere FW-Software auch nicht transparenter ist, oder sogar die gleiche Macke mitbringt (Shorewall. Allerdings sagen die's wenigstens groß in der Anleitung, samt Lösung) Daher ziehe ich "plain" iptables vor, und nicht "generiertes" iptables.

...

Daher setze ich die SuseFW2 zukünftig nicht mehr ein. Die FW2 setzt die notwendigen Regeln nicht.

die SF2 macht in diesem fall genau das, was sie machen soll.

Wo soll da der Sinn sein? Ich habe 'ne Linuxkiste im Netz hängen, die macht für einen kleinen Betrieb "alles", und ich muß Klimmzüge machen, damit die Kollegen auf die Website, an ihre Post und ans ftp drankommen. Das ist ja irgendwie auch eine Allerweltskonfiguration. Wenn ich das mit DMZ und Router!=Server realisiere, habe ich mehr Linuxkisten in der Firma stehen als Arbeitsplätze. :-))) Und die Geschichte mit zwei ip's oder Namen nehmen, je nachdem sich die Laptopuser befinden kriegst du in die Köpfe Normalsterblicher nicht rein. Es klappt einfach nicht. Ist auch Quatsch. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Moin, Am Mon, 2003-06-09 um 14.49 schrieb Johannes Kapune:

Joerg Rossdeutscher schrieb:

...

Das leitet _alle_ internen Anfragen auf das externe Interface auf ACCEPT. Das will ich nicht. Also fange ich an, einen ganzen Stapel Regeln einzubauen: Anfrage OK für http. Für ftp. Für DNS. Für POP3. Für SMTP. Für... Wenn ich eine komplette Route für diverse Services selbst einbauen muß, dann besorge ich mir lieber eine andere FW.

Aber wie bau ich eine Route nur für DNS ein? Mein Problem scheint die FW2 zu sein. Ich kann auf dem Server keine DNS Auflösung für lokale Namen hinbekommen. Da vile andere Lösungsansätze nichts geebracht haben, könnte es ja noch an der FW2 liegen - oder doch nicht?

Das hier beschriebene Problem ist ein Spezialfall, der nur für die externe IP und interne Clients gilt. Ich habe mir DNS in der firewall2-custom.rc.config freigegeben mit iptables -A INPUT -j ACCEPT -d 111.222.111.222 --protocol tcp --destination-port 53 iptables -A INPUT -j ACCEPT -d 111.222.111.222 --protocol udp --destination-port 53 ...was definitv mehr durchlässt als normalerweise korrekt (Keine Prüfung auf gespoofte Adressen). In diesem Fall aber in Ordnung, da DNS auch nach draussen gebraucht wird (Laptopuser) und deswegen sowieso "freie Bahn für alles" angesagt ist. Außerdem sollte man gucken, ob nur tcp oder nur udp gebraucht wird, wozu ich zu faul war. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Burkhard Schichtel wrote:

Am Mon, 2003-06-09 um 16.42 schrieb Joerg Rossdeutscher: [DNS Anfragen durchlassen]

...

Außerdem sollte man gucken, ob nur tcp oder nur udp gebraucht wird, wozu ich zu faul war.

DNS Queries benutzen UDP. TCP wir i.a.R. nur für Zonentransfers benötigt.

Falsch. Ein Query nach einem Eintrag mit sehr vielen Antworten wird auch als TCP uebertragen. Du kannst in ein UDP-Paket ja nicht beliebig viel hineinstopfen. Peter

Burkhard Schichtel wrote:

Und woher soll der anfragende Rechner wissen, dass es für die Anfrage sehr viele Antworten gibt?

Er kriegt per UDP ne Fehlermeldung und dann kommt der TCP-Query. Die Maximale Datengroesse im UDP-Paket sind 512 Bytes. Nicht wirklich viel Und du hast natuerlich auch Recht: Zonte-Transfers immer ueber TCP. Peter

Burkhard Schichtel wrote:

Hast Du mal ein Beispiel?

Nein, habe ich nicht. Du erhaelst in jedem Fall auch soviel Antwort, wie in das Paket reinpasst. Mein "Building Internet Firewalls, 2nd Ed." und die DNS RFC sagen: Du brauchst auch TCP/Port 53 um DNS zu fahren. Ich muss auch Zone-Transfers machen. Also bleibt bei mir auch TCP auf. Wenn es bei dir anders laeuft, schoen fuer dich.

Der Query geht als udp Paket raus, und als Antwort kommen ein oder mehrere udp Pakete zurück. Auf einen query auf z.B. www.microsoft.com bekomme ich 7 udp Pakete mit den verschiednen IP Adressen zurück.

Hm, bei mir ergab das 71 Pakete. Hast du nen lokalen Nameserver gestartet? Wenn ja, welchen? Peter

Burkhard Schichtel wrote:

Am Die, 2003-06-10 um 08.56 schrieb Peter Wiersig:

...

Burkhard Schichtel wrote:

...

Hast Du mal ein Beispiel?

Gerade gebastelt. Probier mal. s.u.

...

Nein, habe ich nicht. Du erhaelst in jedem Fall auch soviel Antwort, wie in das Paket reinpasst.

...

upd oder tcp?

UDP. $ dig testbe-d.de mx @ns.glamus.de ;; Truncated, retrying in TCP mode. Zeig du mal die Ausgabe von obigen Befehl. Peter