Internetzugang für Clients im Netzwerk steuern

[Dalai]

Warum setzt keiner an der einen zentralen Stelle an, die den Internetzugang zur Verfügung stellt: dem Router? Dazu wäre es natürlich wichtig zu wissen, was für ein Router zum Einsatz kommt, und was der so alles (nicht) kann. Auf den Client anzusetzen, ist IMO der falsche Weg und daher halte ich eine Lösung in Delphi für unnötigen Aufwand. Squid selbst ist übrigens auch nicht zwingend eine Lösung, weil der sich nur um HTTP und FTP kümmert, alle anderen Protokolle (IIRC auch verschlüsselte Sachen wie FTPS und HTTPS) fallen unter den Tisch - und davon gibt es ja einige.

MfG Dalai

[hathor]

1. Muss es nicht immer einen Router geben
2. Hat man nicht immer Zugriff auf den Router (Locked)

[Dalai]

Zitat von hathor:

1. Muss es nicht immer einen Router geben

Da es hier um Clients geht, muss irgendein System den Router geben. Es wird wohl kaum jeder Rechner eine eigene Einwahl machen (dann mit jeweils eigenen Zugangsdaten).

Zitat:

2. Hat man nicht immer Zugriff auf den Router (Locked)

Dann wird man kaum das gesteckte Ziel erreichen. Klar, man kann rumfrickeln und auf jedem Client mit Skripten den Gateway mopsen bzw. wieder eintragen, aber wie heißt es so schön: "Kann man machen , muss man aber nicht" .

MfG Dalai

[BUG]

Den Internetzugang über Proxyserver zu leiten und dort zu analysieren / zu sperren, scheint mir am sinnvollsten.
Es sollte nicht nur ein HTTP-Proxy (wie Squid) sein, ein SOCKS-Proxy wäre an der Stelle sinnvoller.

Natürlich sollte man dann die Clients per Firewall (-> Router) oder anderweitig daran hindern, ohne Proxy ins Internet zu kommen.
Ich würde nicht voraussetzen, dass der Router eine gute Rechteverwaltung besitzt ... professionelles Netzwerkzeugs sind schließlich teuer.

[generic]

Proxy halte ich für umständlich und er limitiert auf die Protokolle welche er verstehen kann.

Warum nicht einfach vom Router die Firewall nutzen und IP's/MAC's von Datenverkehr ausschließen?
Das geht selbst mit einer Fritzbox. Mit einer Linux-Firewall vielleicht etwas leichter, da man sich dort auch ggf. eine API drauf setzen kann, welche Remote ansprechbar wird.

[mkinzler]

Zitat:

Proxy halte ich für umständlich und er limitiert auf die Protokolle welche er verstehen kann.

Das reicht meistens auch aus. Zusätzliche Protokolle kann man ja gezielt Freigeben.