[gelöst] iptables Portforwarding -> Fehler im Script/Rege

[slu]

Hallo Forum,

ich wollte intern einen Port auf einen anderen internen Rechner weiterleiten.

Der Rechner der dies weiterleiten soll hat die IP 192.168.1.179 und soll auf Port 333 reagieren und dann auf 192.168.1.11:21 weiterleiten.

Hier mal mein Script

Code: Alles auswählen

#!/bin/bash 

#alles löschen 
iptables -F 

#alles auf DROP 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP 
iptables -P FORWARD DROP 

#localhost und eth0 komplett freischalten 
iptables -A INPUT -i lo -j ACCEPT 
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT 
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT	

# erlaube bestehende Verbindungen 
iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 

# Port auf 192.168.1.11:21 weiterleiten
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 333 -j DNAT --to 192.168.1.11:21

# allow forwarding 
echo "1" > /proc/sys/net/ipv4/ip_forward

Wo ist mein (denk) Fehler?

[jhr-online]

Bin mir nicht sicher, aber heißt es am Ende der Forwarding-Regel nicht

Code: Alles auswählen

--to-destination IP:Port

?


jhr

[nepos]

--to ist schon ok.

[slu]

@ jhr-online,

hatte ich auch schon probiert

[DynaBlaster]

Hi slu,

sieht soweit in Ordnung aus, deshalb könnte ich mir vorstellen, daß die Probleme eher mit dem Dienst, der auf Port 21 (FTP ?, passiv oder aktiv ?) lauscht, zusammenhängen.

Du könntest ja testweise mal den Port 333 statt auf Port 21 auf Port 22 umbiegen (falls ssh auf dem 192.168.1.11 läuft) und gucken, ob eine ssh-Verbindung funktioniert - zumindest könntest du dann einen Fehler im iptables-Script ausschließen und dich dann der Konfiguration des ftp-Servers zuwenden.

[herrchen]

Code: Alles auswählen

iptables -A INPUT -i eth0 -j ACCEPT 

Wo ist mein (denk) Fehler?

ich würde sagen, in der reihenfolge der regeln.
das paket kommt auf "eth0" an, bekommt "ACCEPT" und fertig.

sollte es nicht so sein, kannst du durch einstreuen von einigen "LOG"-regeln vielleicht mehr sehen.
auch "tcpdump" könnte licht in die sache bringen.

herrchen

[DynaBlaster]

Hier stellt sich mir wieder eine Frage, die mich schon seit längerem beschäftigt und auf die ich bisher nicht wirklich eine eindeutige Antwort finden konnte.

http://de.wikipedia.org/wiki/Bild:Nfk-traversal.png
Diese Darstellung kommt von Wikipedia und hier greift das Prerouting vor dem Durchreichen des Pakets an die die INPUT-, FORWARD- bzw. OUTPUT-Chain. Demnach wäre herrchens Hinweis bezüglich der Regel-Reihenfolge hinfällig, da das Paket, das an Port 333 ankommt, auf jeden Fall in der FORWARD-Chain landen würde - schließlich ist es ja nach Durchlaufen der PREROUTING-Chain ja nicht mehr für den 192.168.1.178 bestimmt.

Ich habe aber auch schon Darstellungen der Chains gesehen, wo es so aussiehht, als ob die Regeln der PREROUTING-Chain erst nach der Einteilung der Paket in die INPUT- bzw. FORWARD-Chain durch den Kernel greifen.

Lasst mich nicht dumm sterben, bitte

[slu]

@ herrchen,

ich habs mal testweise rausgenommen, das macht aber keinen Unterschied.

@ all,

ich habe gesehen das mein FTP-Server eine Anfrage vom Rechner 192.168.1.174 bekommt.

Also funktioniert es!
Client 192.168.1.174 -> Router 192.168.1.179 -> Server 192.168.1.11

In der Log vom Server ist ein Connect zu sehen von 192.168.1.174

Kann das sein das mein Problem wo ganz anderest liegt, nämlich das alle Rechner im gleichen Subnetz liegen?

Sehe ich das richtig das der Server dann 192.168.1.174 direkt antwortet und somit nicht über den Router geht, was dann auch die Ursache für das nicht zustande kommen der Verbinung ist?

Das würde auch das hier erklären:

Code: Alles auswählen

slu@debiannb:~$ telnet 192.168.1.179 21
Trying 192.168.1.179...
    

[DynaBlaster]

Sehe ich das richtig das der Server dann 192.168.1.174 direkt antwortet und somit nicht über den Router geht, was dann auch die Ursache für das nicht zustande kommen der Verbinung ist?

Kann schon sein, kommt halt darauf an, ob ein Firewall auf 192.168.1.174 läuft bzw. wie er konfiguriert ist. Wie gesagt, kann auch sein, daß hier das Problem beim FTP-Protokoll liegt (soweit ich weiss baut der FTP-Server schießlich über Port 20 [FTP-DATA] eine Verbindung zum Client auf, der zuvor auf Port 21 angefragt hatte) - kenne mich mit FTP aber nicht aus.

Schau mal auch hier nach: http://www.debianforum.de/forum/viewtopic.php?t=72910

[slu]

Hi DynaBlaster,

es läuft nun so wie ich möchte!

Code: Alles auswählen

#!/bin/bash 
#alles löschen 
iptables -F 

#alles auf DROP 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP 
iptables -P FORWARD DROP 

#localhost und eth0 komplett freischalten 
iptables -A INPUT -i lo -j ACCEPT 
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT 
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT	


# erlaube bestehende Verbindungen 
iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 

iptables -t nat -A POSTROUTING -p tcp --dport 21 -j SNAT --to 192.168.1.11:21	



# allow forwarding 
echo "1" > /proc/sys/net/ipv4/ip_forward

Hab es nun mit POSTROUTING gelöst.
Denke damit hat sich evtl. meine Vermutung bestätigt wegen dem selben Subnetz. Nun sehe ich zwar die IP des Routers auf dem Server aber das macht ja nichts.

Leider hab ich nun ein anderes Problem, egal was ich bei --dport angebe, es funktioniert nur wenn ich bei --dport auch 21 angebe.

Ich kann nicht sagen 333 auf 21

...

Ich hab gerade den Rechner nochmal neu gestartet, nach dem ich mein Script ausgeführt habe geht es nicht mehr.


Kann es sein das ich irgendetwas gesetzt habe das mit

Code: Alles auswählen

iptables -F

nicht gelöscht wird?
Das wäre die einzigste Erklärung warum es nach dem Neustart nicht mehr geht.

EDIT: Mach ich nach dem neustart ein telnet auf 192.168.1.11:21 vom Router aus geht es. Führe ich das Script aus und mache dann nochmal ein telnet vom Router aus geht es nicht mehr. Auch nach einem iptables -F geht es nicht.

[DynaBlaster]

Hi DynaBlaster,

es läuft nun so wie ich möchte!

Freut mich

Deine Vermutung bezüglich des Nicht-Löschen durch dein Script ist richtig. Schau dir mal an, was in der NAT-Table vorhanden ist:

Code: Alles auswählen

iptables -t nat -L -n

zu löschen ist das ganze mit:

Code: Alles auswählen

iptables -t nat -F

Zu deinem Script, wo ist denn die Prerouting-Zeile hin ? Auch wenn du im Anschluß per SNAT die FTP-Anfrage maskierst, musst du vorher mittels Prerouting das Paket entsprechend umleiten, also:

Code: Alles auswählen

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 333 -j DNAT --to 192.168.1.11:21
iptables -t nat -A POSTROUTING -p tcp --dport 21 -j SNAT --to 192.168.1.11:21

[slu]

Hi DynaBlaster,

danke für deine Antwort.

Leider will es einfach nicht mehr

Code: Alles auswählen

#!/bin/bash 
#alles löschen 
iptables -F 
iptables -t nat -F

#alles auf DROP 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP 
iptables -P FORWARD DROP 

#localhost und eth0 komplett freischalten 
iptables -A INPUT -i lo -j ACCEPT 
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT 
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT	

	
# erlaube bestehende Verbindungen 
iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 21 -j DNAT --to 192.168.1.11:21
iptables -t nat -A POSTROUTING -p tcp --dport 21 -j SNAT --to 192.168.1.11:21	

# allow forwarding 
echo "1" > /proc/sys/net/ipv4/ip_forward

Immerhin kann ich nach dem starten des Scriptes wieder vom Router auf den Server mit telnet.
EDIT: Doch nicht, hatte mich vertan.

Irgendwas hatte ich vohin beim ausprobieren noch reingschrieben vor dem neustart, es muss also irgendwo noch ein Fehler in den Regeln sein.

EDIT: Ich habs

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Nun möchte ich erreichen das das MASQUERADE nur bei dem Weiterleiten auf 192.168.1.11 angewandt wird.
Desweiteren möchte ich das nur die IP 192.168.1.174 diese Weiterleitung benutzen kann.

Könntest du mir hier nochmal unter die Arme greifen?

[DynaBlaster]

Argh !, manchmal sieht man den Wald vor lauter Bäumen nicht: Die Postrouting-Zeile muss ja auch so aussehen:

Code: Alles auswählen

iptables -t nat -A POSTROUTING -p tcp --dport 21 -j SNAT --to 192.168.1.179

EDIT: bzw. so, wenn du die oben genannten Einschränkungen umsetzen willst

Code: Alles auswählen

iptables -t nat -A POSTROUTING -s 192.168.1.174 -p tcp -d 192.168.1.11 --dport 21 -j SNAT --to 192.168.1.179

Die Masquerading-Zeile kann dann rausfliegen ...

[slu]

Hi DynaBlaster,

aha!

Nun geht es.

Super, vielen vielen Dank!

[DynaBlaster]

Bitte, bitte, bist du dir denn sicher, daß es wirklich klappt ? Ich bin mir nämlich nicht 100% sicher - habe ja oben bereits angedeutet, daß ich nicht wirklich sicher bin, wie und wann welche Regeln greifen.

[slu]

Hi DynaBlaste,

du meinst das mit dem Forward?

Es geht auch nur wenn...

Code: Alles auswählen

iptables -A FORWARD -i eth0 -j ACCEPT

...gesetzt ist.

Fertig Regeln im gesamten:

Code: Alles auswählen

#!/bin/bash 
#alles löschen 
iptables -F 
iptables -t nat -F

#alles auf DROP 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP 
iptables -P FORWARD DROP 

#localhost und eth0 und tun0 komplett freischalten 
iptables -A INPUT -i lo -j ACCEPT 
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT 
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
#	iptables -A FORWARD -o eth0 -j ACCEPT	

	
# erlaube bestehende Verbindungen 
iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 333 -j DNAT --to 192.168.1.11:21
iptables -t nat -A POSTROUTING -s 192.168.1.174 -p tcp -d 192.168.1.11 --dport 21 -j SNAT --to 192.168.1.179

 # allow forwarding 
 echo "1" > /proc/sys/net/ipv4/ip_forward

[DynaBlaster]

Schon klar:

Evtl. solltest du noch die Prerouting-Regel etwas anpassen; im Moment werden noch alle Anfragen an 192.168.1.179:333 auf 192.168.1.11:21 umgebogen und weitergeleitet, egal von welcher IP sie komemn. Die Verbindung kommt zwar mangels SNAT nicht zu Stande, aber trotzdem.

Code: Alles auswählen

iptables -t nat -A PREROUTING -i eth0 -s 192.168.1.174 -p tcp --dport 333 -j DNAT --to 192.168.1.11:21

Gruß, Dyna

[slu]

Hi DynaBlaster,

Code: Alles auswählen

iptables -t nat -A PREROUTING -i eth0 -s 192.168.1.174 -p tcp --dport 333 -j DNAT --to 192.168.1.11:21
iptables -t nat -A POSTROUTING -s 192.168.1.174 -p tcp -d 192.168.1.11 -j SNAT --to 192.168.1.179

Fein, genau so wollte ich das.

Das "--dport" bei "POSTROUTING" habe ich noch rausgemacht, wird nicht gebraucht wenn ich das richtig verstehe (geht auch noch nach dem entfernen).

[DynaBlaster]

Das "--dport" bei "POSTROUTING" habe ich noch rausgemacht, wird nicht gebraucht wenn ich das richtig verstehe (geht auch noch nach dem entfernen).

Ja, jetzt wird halt alles, was von 192.168.1.174 kommt und nach 192.168.1.11 soll auf 192.168.1.179 "ge-SNAT-ted", vorher halt nur die Paket, die zusätzlich noch nach Port 21 gehen sollten.

[slu]

Hallo Forum,

ich sollte mein Vorhaben einmal genauer beschreiben.

Router -> Debian mit Squid -> Clients

Nun sollen einige Clients via

Code: Alles auswählen

Debian_IP:Port

auf den Debian zugreifen und dieser fungiert als Gateway ins Netz und verbinden in wirklichkeit zu

Code: Alles auswählen

irgendeine_DNS_name:Port

Dachte nun das ich das mit iptables lösen kann, geht im prinzip auch, nur nicht mit festen IP Adressen.

Gibt es evtl. ein Programm das sowas macht, ich konnte noch nichts finden...

[DynaBlaster]

Dachte nun das ich das mit iptables lösen kann, geht im prinzip auch, nur nicht mit festen IP Adressen.

Den Satz verstehe ich nicht. Bisher ging es doch in dem Thread darum, dass die Clients auf einen bestimmten Port des Debian-Rechners connecten und dieser dann per iptables diese Anfragen an einen anderen Server weiterleitet, der den angeforderten Dienst auch wirklich bereitstellt. Die Lösung mit SNAT scheint ja funktioniert zu haben.

Von welchen "festen IP-Adressen" redest du ? Normalerweise haben Server immer feste IP-Adressen. Du scheinst Ports an bestimmte DNS-Namen:PORT weiterleiten zu wollen. Warum ? Befinden sich die Server hinter DynDNS (und Co.) - Adressen ? Ansonsten wüsste ich nicht, warum du nicht einfach die IP des entsprechenden Servers benutzt. ftp.debian.org hat schließlich immer die gleiche IP-Adresse, die du anstatt ftp.debian.org benutzen kannst. (Gut, es kommt natürlich vor, daß der Server mal umzieht und ftp.debian.org dann einer anderen IP-Adresse zugewiesen wird. Pech, in dem Fall musst dann das Script eben den neuen Gegenheiten anpassen und die aktualisierte IP verwenden).

Evtl. deute ich auch das Problem falsch ...

[slu]

Hi DynaBlaster,

du hast es schon richtig verstanden.
Ich habe das erst intern probiert, da ich da feste IPs habe hat das auch Problemlos geklappt.

Im glauben die Lösung zu haben wollte ich das auf extern anwenden und mit DNS Namen machen eben wegen der IP Änderungen...

EDIT: Auch wenn ich keine Lösung für das Portforwarding mit DNS Namen habe, ist das Grundthema gelöst. Deshalb fügte ich in den Betreff ein [gelöst] ein.

EDIT 2: Es gibt ein Programm Namens "rinetd" mit dem läst sich das lösen.

Siehe: http://www.debianforum.de/forum/viewtop ... highlight=