Linux + Routing + Port/Protokollbasiert

[-uLtrA-]

Hi Leute,

um es auf den Punkt zu bringen, ich komme so nicht weiter.

Wie immer erkläre ich mein Szenario

-> Hardware Firewall (1 Internet Uplink, DMZ Bereich, Interner Bereich)

-> Webserver (http + ftp) (IP: 172.16.32.2)

Im Normalfall sollte ja aller Traffic über die Hardware Firewall Appliance gehen, das Problem ist leider das diese Hardware Firewall völlig überlastet mit Verbindungen ist, daher waren wir gezwungen, eine zweite Schnittstelle des Webservers in Betrieb zu nehmen die wir mit einer öffentlichen IP versehen und direkt ohne Firewall von der DMZ ins Internet lassen.

Hat Geldtechnische Gründe, daher kann ich das leider nicht ändern.

Geplant war also:

http Traffic über die öffentliche Schnittstelle am Server durchzulassen den Rest per IPTables komplett zu verbieten auf dieser Schnittstelle.

Nun läuft aber auf der Maschine noch ein FTP-Server. Dieser sollte weiterhin über einen Application-Layer-Filter über die Hardware durch die interne Schnittstelle geschleust werden. Und da liegt der Hund begraben

Webserver:

eth0: 172.16.32.2 (ftp und interne Angelegenheiten wie Datenbank etc.)

eth1: 193.xx.xx.xx (später nur http erlauben)

Man sollte ja nur 1x defaultgateway definieren, ich musste daher das Gateway vom öffentlichen Bereich eintragen (Schnittstelle eth1)

eth0 hatte nun keinen Gateway mehr um von der DMZ in meinen internen Bereich zu routen habe ich eine simple Route hinzugefügt.

Die IP 172.16.32.1 ist mein eigentlicher Gateway für interne Dinge.

Ok folgendes beim Thema FTP:

Ich habe also an meiner Hardware Firewall mehrere öffentliche IP's gebunden die ins interne Netz geNAT'et werden. Funktion einwandfrei.

Nungut ich habe also eine Regel an meiner Firewall die besagt:

Alles was von 193.xx.xx.10 (FTP) reingeht an meinen Server 172.16.32.2 weitergereicht wird.

Nun das Problem ist, mein Server antwortet nicht zurück.

Tcpdumpmässig schaut das leider nur so aus:

20:11:53.200870 IP (tos 0x0, ttl 122, id 32519, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK>


20:11:56.102701 IP (tos 0x0, ttl 122, id 32570, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK>


20:12:02.138010 IP (tos 0x0, ttl 122, id 32680, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK>

Wiegesagt die Regeln für das NAT sind 100% korrekt!

Ich vermute nur sehr stark das, da eine öffentliche IP anfrägt am FTP (siehe Log, das war ich z.b. von daheim..) das dieser zwar an der eth0 (interne Schnittstelle ankommt) ABER da eine öffentliche IP anfrägt, mein blöder Server denkt er müsse die Antwort über eth1 (öffentliche Schnittstelle) rausrouten und sie verschwindet im Nirvana.

Was kann ich also tun?

Es handelt sich lediglich um FTP Traffic..der muss über das interne Interface wieder zurück wo er herkam

[-uLtrA-]

Hallo Community,

(Sorry für den Doppelpost, ich kann leider nicht meinen Thread weiter unten editieren?)

Da ich auf neue Erkenntnisse stoß, möchte ich es hier nochmal versuchen:

ich hänge im Moment an einem sehr bescheidenem Routing Problem bei Linux.

Mein Szenario schaut so aus:

- Firewall Appliance

- Webserver

Das Problem derzeit ist, das wir in Performance Engpässe an der Firewall Appliance haben und uns aus Kostengründen dazu entschieden haben den Webserver mit einem Uplink direkt von der DMZ in das Internet zu hängen.

(Natürlich später mit IPTable Firewall versehen das nur http Traffic erlaubt ist)

Nun hat also die Firewall mehrere öffentliche Adressen an sich gebunden, ebenso die in Betrieb genommene (eth1) Schnittstelle des Webservers.

Weiterhin besteht am Server (eth0) die Schnittstelle in das interne Netzwerk (172.16.32.2) worüber Datenbanktraffic und weiterhin ein FTP-Server über die Firewall laufen soll.

Da liegt das Problem, aufgrund der externen Anbindung musste ich auf eth1 den öffentlichen Gateway als default Gateway definieren. Um mein internes Netzwerk zu erreichen habe ich natürlich einfach eine entsprechende Route geaddet.

Nun passiert leider folgendes

Der FTP-Server ist voll funktionstüchtig, intern ohne Probleme verbindungsbereit.

Nun, wenn ich aber den Weg über die Firewall (dort habe ich eine neue öffentliche Adresse genommen und diese lasse ich es in die DMZ NAT’n) kommt keine Antwort zurück.

Das NAT etc. funktioniert 100% korrekt.

Ich hatte einen tcpdump gemacht und festgestellt dass der FTP-Server einfach nicht mehr antwortet! Er empfängt drei Pakete, tut nichts und mein Client bringt einen Fehler.

20:11:53.200870 IP (tos 0x0, ttl 122, id 32519, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK>

Es liegt sehr Nahe bzw. das Problem muss daran liegen das er denkt er müsste die eth1 (öffentliche Schnittstelle) zum antworten benutzen. Macht er auch nicht laut tcpdump, er macht einfach gar nichts. Was ja so oder so falsch wäre. Ich habe also weiterprobiert und mich entschlossen, spaßeshalber mal folgendes einzutragen:

route add -host 87.176.87.46 gw 172.16.32.1

Das war zu dem damaligen Zeitpunkt meine IP-Adresse (sieht man schön im tcpdumplog). Was passierte? Natürlich konnte ich mich verbinden! Das ganze half also, es funktionierte. So einfach ist es ja leider doch nicht, da der Webserver noch da ist wo über die andere Schnittstelle geht, ich bin ja nicht der einzige der sich verbinden will. Ich habe also weitergesucht, Stichwort: „Portbasiertes Routing Linux“ Ich stoß auf eine Netfilter Anleitung http://lartc.org/lartc.html#LARTC.NETFILTER Das schien für mich genau das richtige zu sein! Nämlich das man entscheiden kann welche Schnittstelle welches Protokoll benutzen darf. Das Problem ist, es funktioniert nicht, was auch darin liegen könnte das der dort beschriebene IPTables Befehl eine Fehlermeldung bringt

iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 21 -j MARK --set-mark 1 –v

Dieser Output:

MARK  tcp opt -- in eth0 out *  0.0.0.0/0  -> 0.0.0.0/0  tcp dpt:21 MARK set 0x1

iptables: Invalid argument

Leider bin ich kein IPTables-Guru und kann den Fehler „Invalid Argument“ einfach nicht lösen. Ich nutze Debian 4.0 Etch.

Spasseshalber auf einem meiner Debian 3.1 System ausprobiert. Dort bekomme ich kein „Invalid Argument“ zurück.

Ich habe also trotz dieser Fehlermeldung alles weitere getan um die Pakete „zu markieren“ und darauf gehofft das es funktionieren würde. Negativ!

Jedenfalls bin ich mittlerweile am Ende meines „Latein’s“

Ich würde mich sehr freuen wenn jemand Lösungsvorschläge für mich hätte.

gruß,

Jens

[carstenj]

Hallo,

um solche Szenarien zu erklären, helfen eigentlich nur Zeichnungen. Ich verstehe momentan noch nicht so ganz, was du willst und wo es harkt.

[-uLtrA-]

ok danke für den Hinweis,

dann kommt morgen noch eine Skizze!

Hab mein bestes versucht beim Schreiben, ist eben immer etwas schwierig zu erklären

gruß Jens