IP-Filter Aktivität trotz Protowall

[Verlierer]

Gott zum Gruße!
Habe heute mal zum Test Protowall installiert (ein IP-Blocker wie PeerGuardian). Aus reiner Neugierde habe ich Proto mal mit dem IP-Filter von eMule gefüttert ohne diesen zu deaktivieren. Laut meinem Verständnis müsste es jetzt doch so sein, dass der Filter von eMule nix mehr zu tun haben dürfte, da Proto alle bösen IP's abfängt bevor sie mit dem Mulchen in Berührung kommen. Dem ist aber nicht so. Der Filter von eMule hat zwar deutlich weniger Treffer, aber er filtert noch einige IP's!

Wie kann das sein?

P.S. Ja, Protowall funktioniert einwandfrei.

[Sorrow]

...eigentlich ganz logisch...

...emule filtert von "innen nach aussen", und die protowall "entgegengesetzt"...
(...emule bekommt die "bad-ips" nunmal via quellentausch...)
...beobachte das einfach einmal...


greetz Sorrow

[Verlierer]

Ah verstehe, die bösen IP's werden durch den Quellenaustausch an Protowall vorbei geschmuggelt indem sie in einem Paket verpackt werden welches mir von einer netten IP gesendet wird, richtig?

[Jok3r]

Jauh, die Trefferanzahl ist natürlich deutlich geringer weil ProtoWall jeden direkten Kontakt unterbindet. Jede IP die in einem Paket von einer nicht geblacklisteten Connection kommt, und im IP Filter ist wird dann von eMule gefiltert.
Sozusagen 2 Schutzschichten, is aber Quatsch weil der IP Filter in eMule beides filtert xD

[Verlierer]

Das hatte ich in der Tat nicht bedacht *schäm*

Naja, wenn das so ist kann ich dem Mulchen ja getrost den Filter wegnehmen, dann werden die IP's vom Quellenaustausch eben in zweiter Instanz von Proto abgefangen (filtert ja sowohl ein- als auch ausgehende Anfragen), schön

[aalerich]

Naaaa... Wenn das Muli versucht, mit IPs Kontakt aufzunehmen, die Protowall dann abfängt führt das zu mehr Overhead. Wie stark dieser Effekt ist weiß ich nicht; gut möglich, daß es vernachlässigbar ist. Aber ich würde das Muli mal ruhig selbst ausmisten lassen und Protowall nur noch den kleinen Rest überlassen.

Mit freundlichen Grüßen
aalerich

[Verlierer]

Hmmm... aber müsste das dann nicht eine Art "virtueller" Overhead sein? Da Proto die Anfrage ja abfängt kann die Internetverbindung mit dieser doch auch nicht belasstet werden. Das Mulchen wird das Paket zwar sicherlich trotzdem in den gesamt Overhead einrechnen, aber tatsächlich wird es doch nicht mehr?

[aalerich]

Gute Frage.
Allerdings würde das Muli vermutlich dennoch effektiv weniger senden. Es sendet die Daten, sie kommen aber nicht durch. Sie gehen also nicht effektiv raus, das Muli schickt sie aber anstelle anderer Daten. Es weiß ja nicht, daß sie nicht durchkommen werden und wird es immer wieder versuchen. Und diese Daten muß es ja vom eigentlichen Upload abziehen.

Eigentlich könntest Du das mal richtig testen. Baue doch mal für Protowall einen Test-IP-Filter und filtere von mir aus eine Range von 60.000.000.001 bis 200.000.000.255. Ein paar Kontakte müßten übrigbleiben und wenn Du dann viele massenhaft gefragte Dateien bestellst (aktuellen Mainstream) müßte nach meiner Theorie der Overhead explodieren und der effektive Upload einbrechen. Die Internetleitung würde allerdings nicht mehr ausgenutzt werden da das, was das Muli als Overhead zu verschicken glaubt, dank Protowall ja nicht wirklich rausgeht.

Mit gespannten Grüßen
aalerich

[Verlierer]

Egal wie das Mulchen damit umgeht, unelegant ist es ja in jedem Fall, hab den Filter zurückgegeben.

Auch Protowall ist bei mir in Misskredit gefallen. Ich hab das Prog gerademal 2 Tage am laufen und schon bin ich auf ganze 5 Seiten gestoßen die davon geblockt werden. Jetzt darf ich entscheiden, ob ich mich einer (wahrscheinlich) Privatsphere verletzenden Organisation ausliefere oder auf die Seiten verzichte... sogar mein Wetterdienst Accu wird geblockt

[aalerich]

Naja, die wirklich bösen Buben stehen meiner Meinung nach sowieso nicht in IP-Filtern. Erstens passen die natürlich auf, daß sie nicht auffallen, und zweitens sehen die wohl auch regelmäßig nach ob sie doch in einem gelandet sind.

Mit freundlichen Grüßen
aalerich