am Sat, dem 27.12.2003, um 9:58:35 +0100 mailte Werner Mahr folgendes: > Am Freitag, 26. Dezember 2003 14:33 schrieb Andreas Kretschmer: > Bleibt doch noch eine Frage: > > Lokal > > ... -p TCP --sport 1024: --dport 22 -j ACCEPT # (eingehend) > > ... -p TCP --sport 22 --dport 1024: -j ACCEPT # (ausgehend) > NAT > > - outgoing Ziel-Port 22 ist > > - eingehend Source-Port 22 ist > > Lokal kommt eingehend die Verbindung von >1024 auf PORT 22 rein. > Lokal geht augehend die Verbindung von 22 auf >1024 raus. > > Warum ist das bei NAT genau umgekehrt, ich dachte die Verbindung zum > Server läuft genauso ab, nur halt das der Server die Anfrage nicht > selbst bearbeitet, sondern alles nur weiterleitet. NAT: Client: 192.168.0.1, Port 30000 NAT-Gateway: 192.168.0.100 lokal, 123.123.123.123 extern Ziel: 234.234.234.234 Client will SSH zu Ziel aufbauen 192.168.0.1:30000 -> 234.234.234.234:22 NAT-Gateway macht daraus: 123.123.123.123:40000 -> 234.234.234.234:22 Antwort: 234.234.234.234:22 -> 123.123.123.123:40000 NAT-Gateway macht daraus: 234.234.234.234:22 -> 192.168.0.1:30000 Die Pakete gehen also 2 mal durch das NAT-Gateway: - raus: SRC-Port 40000, DST-Port 22 - rein: SRC-Port 22, DST-Port 30000 Nach den Client-Ports zu filtern geht nicht, die sind nicht fix. Also filtere ich nach den Ports des Dienstes und muß mir überlegen, in welcher Richtung ich diese sehe. Das NAT-Gateway selber ist weder Ziel noch Quelle¹, es steht halt eben nur so rum ;-) und beobachtet die Pakete. ¹ vom Standpunkt der SSH-Verbindung aus gesehen, nicht vom physikalischen Weg der Pakete. Ja, all das mag zuerst etwas verwirrend sein. Aber irgendwie auch faszinierend, oder? ;-) Andreas -- Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau- fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
Attachment:
pgpmDGFeS79YY.pgp
Description: PGP signature