nicht angemeldet
Halihallo Michael und Alexander
Moin Moin!
Ich verdreh' mal etwas die Reihenfolge ...
POP3-Proxy (schon mal selbst gebastelt), wird z.B. bei GMX als Loadbalancer benutzt.
Datenbank-Proxy (DBI bzw. DBD::Proxy)
DNS-Proxy (kam mindestens in alten Versionen von fli4l vor)
Hm. Die von dir genannten Proxies haben alle Kenntnis vom Protokoll.
Das müssen sie. Denn sonst wären sie keine Proxies, sondern Port-Forwarder. Kennen sie mehr als ein Protokoll und setzen sie zwischen ihnen um, nennt man sie nicht mehr Proxy, sondern Gateway. (Ja, CGI=Common Gateway Interface kommt genau daher.)
Simples Port-Forwarding funktioniert übrigens nicht, wenn das Protokoll intern Rechnernamen oder -adressen benutzt. Siehe FTP und das FTP-Masquerading-Helfer-Modul von Linux, das den FTP-Datenstrom umschreibt.
Ein Proxy kann alles durchleiten, was er versteht - er
muß das entsprechende Protokoll in beide Richtungen
sprechen und entsprechende Umsetzungen vornehmen.
Ein Proxi kann alles durchleiten, was er versteht... OK, das ist klar (zugegeben, ich war zu sehr auf HTTP fixiert). Aber ob er sogar p2p Verbindungen herstellen kann? - Wenn ich mich mit Sockets genügend auskenne, muss er doch wissen, wann ein Transfer abgeschlossen ist, das muss der KaZaA kommunizieren und dazu muss es der Proxi noch verstehen. Oder sehe ich das falsch? - Wenn wir hier nicht von "einfachem" Portforwarding sprechen, dann _muss_ doch eine Software zwischen die Kommunikation verstehen.
Genau. Der einfachste Proxy - unabhängig vom Protokoll - gibt sich zum Client hin als Server aus und zum Server hin als Client. Dazwischen mauschelt er eventuell - je nach Zweck - etwas an den Daten rum. Quasi eine Man-in-the-middle-Attack. Der Telnet-Proxy, der mir eine Weile vorgesetzt wurde, war für den Telnet-Client ein ganz normaler Telnet-Server, und für den Server ein ganz normaler Telnet-Client. Die Datenübertragung war 8-bit-clean, nichts wurde verändert.
Es gibt FTP-Proxies, die analog funktionieren. Mein POP3-Proxy hat ebenso funktioniert. Allerdings muß man dabei für die Server-Auswahl etwas tricksen. Mein POP3-Proxy hat statt des einfachen Usernamens die Syntax popserver.example.com::username erwartet. Ähnliches passiert bei FTP-Proxies.
HTTP ist eines von den Protokollen, die explizit mit Proxies klarkommen (mehr oder weniger gut), deswegen verhält sich der Client gegenüber einem Proxy (geringfügig) anders als gegenüber einem Server (Servername, Port und Protokoll werden in die erste Request-Zeile aufgenommen).
Fragt sich:
Die Frage wäre also, ob es einen Proxy gibt, der das
von Kazaa gesprochene Protokoll hinreichend gut unter-
stützt.
Die Kazaa-Hersteller sollten das am ehesten wissen ...
genau. Eben ;)
Da Port-Forwarding anscheinend (laut FLI4L-Links in meinem letzten Posting) funktioniert, braucht man wohl keinen Proxy. Zumindest, wenn nur ein Rechner hinter der Firewall mit Kazaa arbeiten soll.
Ansonsten muß man wohl das Kazaa-Protokoll genau kennen, um einen Proxy zu bauen, der einer (externen) IP-Adresse mehrere Clients zuzuordnen. Das Gemeine an Kazaa - verglichen mit Telnet, FTP, HTTP, POP3 und anderen - ist, daß die Verbindung nicht unbedingt von "innen" nach "außen" aufgebaut wird (was dem Proxy das Leben leicht macht), sondern auch mal anders herum, und das ist die Hölle. Denn die Firewall darf eigentlich gar keine Requests von "außen" annehmen, und die Zuordnung, welcher der "inneren" Rechner den Request behandeln soll, dürfte sehr schwierig werden. Bei HTTP kann man sich noch anhand der URL orientieren, welcher der inneren Server den Request behandeln soll (http://www.perl.org/tpc/1998/Perl_and_Apache/Performance Tuning/conferencetalk.pdf, um Seite 20, oder auch Kai Krebber (hb) "Torwächter -- Apache als Secure Reverse Proxy mit LDAP unter Linux", iX 5/00, Seite 140). Mit FTP würde das im Prinzip auch funktionieren, POP3, IMAP und SMTP können anhand des Usernamens den Server auswählen.
Alexander
Viele Grüsse
Philipp