nicht angemeldet
Halihallo Alexander
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.
Dennoch bin ich der Meinung, das das nicht so einfach geht. Also ich sehe das mal mit den Augen von "perl". Du hörst den Ports ab und leitest die Daten weiter. Dazu musst du aber erst wissen, wann ein Datenstrom beendet ist (dies wird übers Protokoll definiert), da dies jedoch von Protokoll zu Protokoll anders ist (klar, HTTP, FTP, ... halten sich alle an dieselben "Spielregeln"), aber ein p2p - Protokoll ist grundsätzlich anders aufgebaut. Da muss man dann schon etwas tiefer in die Trickkiste greifen und wirklich alle Datenpackete abfangen (was dann nicht mehr mit Sockets im Sinne von IO::Socket::INET geht).
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.
Ja, sehe ich auch so.
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.
Genau. Deswegen hatte ich ja schon immer bedenken geäussert. Das Problem ist, das KaZaA kein Protokoll im Sinne von FTP/POP/HTTP benutzt, sondern eben ein "Multi-Bidirektionales". Das könnte natürlich Probleme geben, die du ja genannt hast.
Aber eben: Portforwarding wird ja funktionieren. Aber mit "normalen" Proxis ist wenig zu erreichen
Viele Grüsse
Philipp