Re: komisches Portforwarding...
On 22.Feb 2005 - 12:13:49, Matthias Houdek wrote:
> Am Dienstag, 22. Februar 2005 10:02 schrieb Andreas Pakulat:
> Zum Verständnis:
> Du forwardest die Ports 21, 22 und 80 auf der (öffentlichen) IP von PC1
> an die gleichen Ports auf PC2 (IP aus LAN).
Jupp.
> Von PC1 und PC3 kommst du direkt auf PC2 (z.B. FTP) - logisch, wenn sie
> in einem Subnet liegen oder PC1 ordentlich im LAN routet.
Er routet ordentlich und es geht ja auch nicht primär um den Zugang.
Ich wollte das Portforwarding testen - das klappte nicht von PC2 aus
(an dem ich sitze), deshalb frug ich hier. Portforwarding klappt zwar
mittlerweile gut, aber mir gehts jetzt darum herauszufinden ob es eine
Möglichkeit gibt vom Rechner im LAN das Portforwarding zu testen...
> Du willst jetzt von PC1 oder PC3 über ISDN ins Internet und von dort
> zurück und über das Port-Forwarding auf PC2. Und das geht nicht.
Ich will eigentlich von PC2 über ISDN ins Netz und dann zurück zu PC2.
PC3 ist ne Win-Kiste und ich hab sie nur der Vollständigkeit halber
erwähnt.
> OK. Ich vergebe mal mangels Vorgabe folgende Adressen:
>
> PC1: ISDN: 200.2.2.2, default-Route an ISP mit 200.2.2.3
Ändert sich ständig.
> zu PC3: 192.168.1.1
> zu PC2: 192.168.2.1
> PC2: 192.168.2.10, default-Route an 192.168.2.1
192.168.2.2
> PC3: 192.168.1.10, default-Route an 192.168.1.1
192.168.1.2
> PC3 schickt jetzt ein Paket an Port 21 auf der ISDN-Karte, also an
> 200.2.2.2, dass aber letztlich vom PC2 angenommen und beantwortet
> werden soll.
Genau :-)
> 1.Etappe: von PC3 an default-Route (PC1)
> Paket von 192.168.1.10 an 200.2.2.2
> 2.Etappe: auf PC1 direkt an ISDN-IF (Output)
> Paket von 192.168.1.10 an 200.2.2.2
> 3.Etappe: auf PC1 Input an ISDN-IF -> Forward-Regel
> Paket von 192.168.1.10 an 200.2.2.2 -> neu:192.168.2.10
> 4.Etappe: PC1 an PC2
> Paket von 192.168.1.10 an 192.168.2.10
>
> Antwort:
> 1.Etappe: PC2 an default-Route (PC1)
> 192.168.2.10 an 192.168.1.10
> 2.Etappe: Und hier müsste es IMHO eine Konflikt geben
Ich schätze mal...
Folgendes sehe ich mit ethereal:
DNS-Anfrage "Standard query PTR 182.621.7.213.in-addr.arpa" (ist die
public-IP in umgekehrter Reihenfolge)
Antwort ist "Standard query response PTR B3db6.b.pppool.de"
Dann ein TCP Zugriff auf 213.7.61.182:
33593 > ftp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=14947772
Antwort darauf kommt noch:
ftp > 33593 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
Hmm und danach ebend nichts mehr und der ftp-Client sagt er bekommt
keine Verbindung...
> Warum?
> Einerseits müsste das Routing dieses Paket direkt an PC3 weiterleiten
> und alles wäre an PC3 OK.
> Andererseits erkennt IPTables auf PC1 das Paket als Antwort auf das
> geforwardete und müsste es dementsprechend zurück maskieren und als
> Paket von 200.2.2.2 (neu) über ISDN an 192.168.1.10 zurückschicken
> (anscheinend wird hier automatisch das entsprechende Output-Interface
> über die Absender-IP bestimmt und kein Ziel-Routing gemacht).
>
> Da IPTables vor dem Routing das Paket in die Finger bekommt, tritt
> offensichtlich der zweite Fall ein und es wird mit der Zieladresse
> 192.168.1.10 ins Internet geschickt, womit es am Next-Hop terminiert
> wird.
Hmm, also ganz so wohl nicht, jedenfalls kriege ich 1 Antwort von
213.7.61.182. Allerdings ebend danach nichts mehr...
> Überprüfe einfach mal praktisch mit einem Sniffer auf PC1, an welchen
> Ports welche Pakete hierbei ein- und ausgehen und ob das so stimmt.
Genau das hatte ich schon gemacht (tethereal) aber ich machs nochmal
mit ausgeschalteter Firewall...
Hmm, also ich sehe auch auf PC1 in eth1 diesselben Pakete wie oben
(einmal DNS-Kram, und SYN und RST,ACK für ftp). Auf ippp0 dagegen sehe
ich _nur_ die DNS-Anfrage, nicht die ftp-Pakete...
> Lösung:
> Du solltest den Traffic von PC3 ins Internet maskieren. Dann müsste auch
> der Rückweg klappen.
Sollte das nicht durch
iptables -t nat -A POSTROUTING -o ippp+ -j MASQUERADE
passieren, das maskiert alles was an ippp+ rausgeht.
Eines noch: Wenn auf dem Router ein FTP-Server läuft komme ich von PC2
mit ftp <public-IP> auf den FTP-server auf PC1. Also ist das Problem
in der Tat, dass aus irgendeinem Grund die Pakete von PC2 nicht in die
Forward-Kette sondern in die Input-Kette laufen...
Andreas
--
You can rent this space for only $5 a week.
Reply to: