Hallo Daniel,
Daniel Bauer <mlist@dsb-gmbh.de> (Di 29 Jan 2013 21:15:06 CET):
> Hallo Heiko,
>
> From: "Heiko Schlittermann"
> >Daniel Bauer <mlist@dsb-gmbh.de> (Di 29 Jan 2013 18:37:06 CET):
> >>ich versuche seit Tagen verzweifelt meinen vsftp verfügbar zu machen.
> >>
> >>Als erstes kommt ein Router der als DMZ Host meine Firewall
> >>eingetragen hat. Hinter dieser Firewall steht auch der Server. Auf
> >>der Firewall wird folgendes akzeptiert:
> >>-p tcp --sport 1024:65535 --dport 21
> >>-p tcp --sport 1024:65535 --dport 20
> >>-p tcp --sport 20 --dport 1024:65535
> >>Andere Dienste wie z.B. SSH funktionieren einwandfrei.
> >
> >Und was wird nicht akzeptiert? Es wäre hilfreich, das komplette
> >Ruleset
> >zu sehen, am einfachsten die Ausgabe von "iptables-save"
>
> kann ich bei Bedarf senden, aber ich konnte das Problem weiter
> eingrenzen.
>
>
> >>Wenn ich den Server direkt hinter den Router klemme, funktioniert
> >>alles bestens, sobald er hinter der Firewall ist kommt kein FTP
> >>Connect mehr zustande.
> >>
> >>Laut $Suchmaschine ist doppeltes NAT möglich, kann mir jemand bitte
> >>einen Schups in die richtige Richtung geben.
> >
> >Doppeltes NAT sehe ich in den von Dir zitierten Regeln gar nicht.
> >Nicht
> >mal einfaches NAT.
>
> ich hatte extra nur die Regeln fürs FTP gezeigt, eigentlich sollte
> mit Connection Tracking ja auch nur der Port 21 reichen, dann
> allerdings nur für passives FTP.
Nein, der Trick am Connection-Tracking ist, daß dann der Modus (ob
aktive oder passive) keine Rolle spielt. Deine Aussage ist richtig,
wenn es kein Connection-Tracking gibt und wenn die FW vor dem Client
ist. Bei Dir ist sie aber vor dem Server. Also werden die Spielregeln
umgekehrt, das heißt, Du kannst den Server nur sinnvoll schützen, wenn
ausschließlich aktives FTP stattfindet -- es sei denn, Du setzt
Connection-Tracking ein.
Ich vermute, das vorletzte Oktett in der Server- und Firewall-Adresse ist
nur zufällig unterschiedlich, oder Du hast ein mindestens /23
> Der Aufbau ist folgender:
>
> 10.20.1.180 (FTP Server)
> |
> |
> 10.20.0.1 (Firewall)
> 192.168.1.11
> |
> |
> 192.168.1.1 (Fritzbox)
> ext. IP
> |
> |
> ext. IP
> 10.30.0.1 (Firewall)
> |
> |
> 10.30.1.x (FTP Client)
>
> Sobald ich nun den FTP Server auf die 192.168.1.12, oder den FTP
> Client auf die externe IP lege funktioniert das Ganze. Aber fast
> jeder Client ist hinter einem Router und nicht direkt im Internet.
Auf der Fritzbox werden automatisch die korrekten NAT-Regeln und
Protokollhelfer geladen sein. Deshalb wird das gehen. Vermutlich auch
aber auch nur, wenn der Client hinter seiner Firewall passives FTP
macht.
Wenn der Client eine öffentliche IP und keine Firewall hat, wird das
gehen, weil die Fritzbox sich immer noch korrekt verhält, aber Deine
Firewall nicht so konfiguriert ist, daß es gut gehen kann, sondern eben
wieder abhängig von active/passive usw.
…
> >Für iptables gibt es da Unterstützung durch nf_conntrack_ftp (filter)
> >und nf_nat_ftp (nat). Das sind Kernel-Module, die geladen werden
> >müssen.
> >(Je nach Kernelversion heißen die - glaube ich - manchmal etwas
> >anders,
> >aber nat_ftp oder conntrack_ftp haben die immer im Namen.)
> diese Module sind geladen.
Gut, ist ja schon mal was.
Auf der Fritzbox hast Du vermutlich Portforwarding für ftp(21)/TCP auf Deine
192.168.1.11 eingetragen? Oder gar gleich auf 10.20.0.180 (und dazu eine
passende Route?)
Wenn die Fritzbox nur zur 192.168.1.11 weiterschickt, müsstest Du auf
der FW erstmal ein Portforwarding einbauen:
iptables -t nat -p tcp --dport ftp -j DNAT --to 10.20.1.180
iptables -t nat -o <outerface> -j SNAT --to 192.168.0.1.11
Und dann sollte natürlich gefiltert werden:
iptables -t filter -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -d 10.20.1.180 -p tcp --dport ftp -j ACCEPT
Und natürlich sicherstellen, daß diese conntrack_ftp und nat_ftp-Module
geladen sind.
> >Die komplette Lösung überlasse ich Deiner Kreativität, die dsb-gmbh
> >(Dein Absender) bietet ja IT-Solutions an ?
>
> auch nach über 24 Jahren im Geschäft gibt es keinen Tag an dem ich
> nicht lernen muß.
Ok :) Ich kann da ISBN 978-0201633467 empfehlen (Richard Stevens, TCP/IP
Illustrated)
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
gnupg fingerprint: 9288 F17D BBF9 9625 5ABC 285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B)-
Attachment:
signature.asc
Description: Digital signature