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. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
