IP Masuerading?

Gemeinsam ins Internet mit Firewall und Proxy.
Antworten
xash
Beiträge: 5
Registriert: 04.11.2002 22:09:26

IP Masuerading?

Beitrag von xash » 04.11.2002 22:18:55

Ich bin grad aufs höchste verwirt , auch die anderen einträge hier im Forum haben mir nich geholfen:
Funktioniert IP-Masuqerading wie ein Proxy?
Wenn nicht wie dann?
Und was is NUT??

thx

xash

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 04.11.2002 22:43:19

Masquerading funktioniert wie ein vollständig transparenter Proxy auf IP Ebene (wenn Dir das hilft...)

Es bewirkt eigentlich nur, dass alle Rechner im Internet glauben, dass Dein Router der Ausgangspunkt der Verbindungen ist, statt Dein interner Rechner (der ja wahrscheinlich ein nicht routingfähige IP hat (192.169.x.y z.B.)

NAT (nicht NUT) ist Network Address Translation. Masquerading ist im Prinzip ein Spezialfall für NAT. Mit NAT kannst Du z.B. Ports von Deinem Router an die Workstation weiterreichen (P2P proggis brauchen sowas normalerweise)

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

xash
Beiträge: 5
Registriert: 04.11.2002 22:09:26

Beitrag von xash » 05.11.2002 15:34:49

hmm also was'n proxy is denk ich weiss ich (nur was bedeutet "transparent" und auf IP Ebene"?)
Hab ich das richtig verstanden dass das praktisch nun so funktioniert:
Der Client1 im Netzwerk stellte eine anfrage z.B. zum surfen über den Port 80(muss es in diesem fall port 80 sein?)oder auf den rechner mit internet verbindung , dieser stellt die anfrage an den web server der eigentlich erreicht werden soll. Wenn dieser antwortet erkennt der der server da die antwort auf port XXX das er die antwort weiter an Client1 senden soll.

Noch ne ganz praktische Frage: t-online find das mit routing nich wirklich cool , aber wenns über'n proxy läuft is das doch für die nich zu erkennen oder?

THX

xash

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 05.11.2002 16:13:51

Transparent = unsichtbar, der Client muss nicht konfiguriert werden. Der proxy ist einfach da und funktioniert.
Auf IP Ebene: ist halt kein HTTP (Web) Proxy oder FTP proxy, sondern der arbeitet auf der Ebene des Netzwerkprotokolls (in diesem Fall halt IP).

Vermeide den Begriff Proxy in Verbindung mit Masquerading, da ein Proxy eigentlich was anderes macht. Wenn Du über Masquerading online gehst, kann man das auf der Internetseite nicht erkennen, es sieht einfach so aus, als ob nur der Router online ist.

Die Funktionsweise von Masquerading:
Deine Workstation stellt eine Anfrage direkt an den Server. Als Absenderadresse ist hier natürlich die interne 192.168.x.y eingetragen, die im Internet nicht funktioniert. Der Router erkennt das, und ersetzt die interne Adresse mit der IP Adresse, die Du bei der Einwahl vom Provider bekommen hast. Der Server im Internet antwortet jetzt an den Router, der sich wiederum gemerkt hat, von welchem internen Rechner die eigentliche Verbindung ausging, ändert die Adresse passend, und fertig.

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

Benutzeravatar
Bert
Beiträge: 3751
Registriert: 16.07.2002 14:06:52
Wohnort: Dresden
Kontaktdaten:

Beitrag von Bert » 05.11.2002 16:24:12

Dein Provider sollte eigentlich von NAT nichts merken.

Masquerading ( oder richtiger Source Network Address Translation) verstehe ich so:
Beispiel.

DU hast einen
- Client im Netz mit der IP 192.168.0.100
- ein Gateway mit der internen IP 192.168.0.1 und der externen IP 213.23.68.28
- die interne IP des GW ist als Gateway im Client konfiguriert

Wenn jetzt der Client ein Packet vom Port 1025 an z.B. 217.115.142.124 Port 80 senden will, reicht er dieses an den GW. Der GW schreibt die Source-Adresse (192.168.0.100:1025) des Packetes auf 213.23.68.28:1099 um (Port hab ich zufällig gewählt) und sendet das Packet weiter und merkt sich die Zuordnung zwischen 192.168.0.100:1025 zu 1099. Kommt jetzt ein Packet am GW auf Port 1099 an, so kann der GW das aufgrund der Zuordnung an den Client Port 1025 weiterreichen.

Der Client merkt davon nichts, für Ihn scheinen die Packete von der externen Adresse ( 217.115.142.124 ) zu kommen. Daher auch transparenter Proxy auf IP Ebene. Ein Proxy ist ein Stellvertreter; diese arbeiten meistens auf Anwendungsebene ( http, pop, ... ) und müßen das entsprechende Protokoll kennen. Ein "TCP/IP Proxy" guckt nicht in die Packete, sondern nur in die Header ( Adressen und Ports)

Ich hoffe, das stimmt soweit und ist halbwegs verständlich.

Achso, über die Ports können auf einer IP Adresse (Host) mehrere Applikationen lauschen. Z.B. kann euf einem Host ein WWW-Server(80) und ein ssh-Server(22) laufen. Über die Port passiert die Zuordnung. Schau mal in /etc/protokols nach. Da sind die definiert.
Alle Ports unter 1024 sind priviligierte Ports und dürfen nur mit root Rechten geöffnet werden.

Hmm. Patrick war mal wieder schneller 8O
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de

xash
Beiträge: 5
Registriert: 04.11.2002 22:09:26

Beitrag von xash » 07.11.2002 21:20:41

THX erstman
mhh also soweit ganz klar nur wie stellt der client die anfragen an den router?
Er schickt also die für den server im internet bestimmten packete "bewusst" an die interne adresse des routers jedoch mit der zusatz info das diese "eigentlich" für die ip des servers im intenret sind(und dazu stellt er die anfrage an dne gateway auch auf dem port auf dem der den server im internet erreichen will)??


cya
xash

Benutzeravatar
Bert
Beiträge: 3751
Registriert: 16.07.2002 14:06:52
Wohnort: Dresden
Kontaktdaten:

Beitrag von Bert » 07.11.2002 21:45:06

ich hoffe jetzt keinen Quatsch zu erzählen. Durch Angabe des Gateways auf dem Client wird dort die Routing-Table verändert. Durch die Netzkonfiguration kann jeder Rechner entscheiden, ob ein Paket für das lokale Netz bestimmt ist, oder außerhalb des Netzes liegt. Geht das Packet an einen Rechner im Netz, so wird (Ethernet vorrausgesetzt) durch einen Broadcast die MAC des Zeilrechners bestimmt, und das TCP/IP Packet noch zusätzlich in ein Ethernet Packet gewrapped. Im Header des Ethernet-Packets ist die MAC des Zielrechners drin.

Geht das Packet an einen Rechner außerhalb des lokalen Netzes, so wird es auch in ein Ethernet-Packet verpackt (wie auch sonst), als ZielMAC kommt jetzt aber die des Gateways rein.

Der Gateway empfängt das Packet, entpacket es und stellt fest, das es nicht für ihn ist. Durch seine Routingtabelle weiß er aber, wohin damit...

Alle Rechner in einem Netzwerk lauschen am Kabel, der Treiber ( oder schon die Hardware? ) entscheiden aber, ob eintreffende Packete überhaupt für diesen Rechner bestimmt sind, und verwerfen alles, was nicht an diesen Rechner gerichtet ist. Nur der Rest wird überhaupt an den TCP/IP Stack weitergereicht.

Wenn Du als root einen Sniffer wie tcpdump, nmap oder ähnliches startest, wird die Netzwerkkarte in den sogennanten "promiscous" Mode versetzt, d.h. alle Packete werden an den TCP/IP Stack weitergeleitet.
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de

xash
Beiträge: 5
Registriert: 04.11.2002 22:09:26

Beitrag von xash » 07.11.2002 23:05:39

so funzen tut das jetzt alles , kennt ihr trotzdem nochmaln tut wo das ganze ein bisschen theoretischer erklärt wird?
Und : Was heisst er sollte nichts merken?
Wie kann er was merken , kann ich was dagegen machen?

thx

xash

Benutzeravatar
pdreker
Beiträge: 8298
Registriert: 29.07.2002 21:53:30
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Nürnberg

Beitrag von pdreker » 08.11.2002 01:34:02

http://www.netfilter.org

Da gibt's 'ne ganze Menge technischr Doku, die den ganzen Kleinkram erklärt

Masquerading: W ist die Workstation, R ist der Router, S ist der Server im Internet.
W hat eine interne IP, R hat eine interne und eine externe, S hat nur eine externe.
W will eine Verbindung mit S beginnen. W schickt ein Paket mit Absender/Empfänger (W/S) los. Er weiss, dass er dies durch R machen muss (Gateway Angabe). Das Paket kommt bei R vorbei und R bemerkt, dass die Absender Adresse im Internet nicht routbar ist. Also ersetzt er einfach ungefragt (!) die Absenderadresse durch seine eigene externe Adresse, und merkt sich für diese Verbindung, dass sie von der internen Adresse W kam (das nennt man Connection Tracking). Wenn jetzt eine Antowrt von dem Server kommt, geht diese an R. R schaut in seiner Tabelle nach, und sieht dort, dass das Paket eigentlich an W gehen muss. Er ersetzt also die Zieladresse (seine eigene externe Adresse) durch die interne Adresse von W, und schickt das Paket weiter.

Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de

Antworten