s.k.

Hallo Danielsun, seltsame Sache das. Der Router 192.168.111.253 ist aber nicht noch aktiv und auf dem Router 192.168.111.254 als Standardgateway eingetragen, oder? Denn ein ICMP-Redirect würde das Verhalten erklären... :suspect: Gruß Steffen

@Wolke2k4: eine weitere Option wäre die Verwendung einer freien Firewalldistribution. Als filtering bridge lässt sich z.B. die M0n0wall betreiben. Gruß Steffen

Hallo Wolke2k4, wenns preisgünstig sein muss, schau Dich mal bei Zyxel um. Bridging-Mode ist derzeit ab der ZW2Plus aufwärts implementiert. Ab ca. 160 EUR bist Du also dabei. Mehr Durchsatz und mehr Features treiben natürlich auch da schnell den Preis nach oben - aber immer noch meilenweit von Cisco & co entfernt. Gruß Steffen

Schön ist was anderes. Wirklich "prikelnd" ist die ganze Lösung aber ohnehin nicht (extern erreichbarer Webserver auf DC). :rolleyes: Alternativ könntest Du den Webserver lokal doch einfach so ansprechen, wie es der Reverse-Proxy des ISA-Server macht (also so, wie es in der Webserververöffentlichungsregel hinterlegt ist). Ich vermute, dass der Webserver intern auf einem anderen Port horcht, oder? Oder man sorgt dafür, dass der ISA-Weblistener lediglich auf der externen IP-Adresse lauscht (Eigenschaften des Servers-->Registerkarte "eingehende Webanfragen") und bindet den Webserver nur an localhost und/oder eine interne IP-Adresse. Ich verstehe allerdings immer noch nicht so ganz, wo das Problem ist. Du kannst doch lokal zugreifen, wenn Du den Servernamen in der URL verwendest. Warum genügt das nicht? Gruß Steffen

Hallo cebo, mir scheint, Du hast eine Webserververöffentlichungsregel (=Reverse-Proxy) eingerichtet und greifst jetzt darauf zu. Sprich: der ISA selbst lauscht auf Port 80, wertet die URL aus und ruft dann die Website vom eigentlichen Zielwebserver (hier lokal) ab. Vermutlich sind localhost und die IP-Adresse nicht im Zielsatz der Webserververöffentlichungsregel erfasst. Gruß Steffen

Hallo cebo,

Wir implementieren gerade für solche und ähnliche Informationen eine (für Unbefugte selbstverständlich unzugängliche!) Wissendatenbank auf Basis der Mediawiki. Gruß Steffen

Dann pack den Gameserver doch auf den vServer oder besorg Dir zu Hause eine fixe IP... Download, Infos und Anleitungen: http://www.janaserver.de Wiki: http://www.fam-hauck.de/wiki/index.php/Hauptseite Support: http://www.janaforum.de Gruss Steffen

Das könnte man z.B. mit einem Janaserver Extragateway realisieren. Ob das allerdings performant und/oder sinnvoll ist, ist eine ganz andere Frage. Warum sollen die Clients nicht direkt über den DynDNS-Namen auf den eigentlichen Server zugreifen? Gruß Steffen

http://en.wikipedia.org/wiki/Captive_portal http://m0n0.ch/wall/features.php http://img.m0n0.ch/screens/services_captiveportal.png Gruß Steffen

Funktioniert natürlich auch nur dann, wenn der Browser für die Suche konfiguriert ist. :( Beim IE ist das allerdings die Standardeinstellung. Dachte ich mir schon. Beim ISA2000 hätte es vermutlich funktioniert. Da wird der lokale Webtraffic nicht über das Proxymodul geleitet. Im welchem Jahr haben sie allerdings nicht gesagt, oder? :D Wie wir vor ca. 1,5 Jahren das Programm getestet hatten, hieß es auch, es käme die nächsten Wochen ein Update für ISA2004... :rolleyes: Gruß Steffen

Das erfordert allerdings, dass die User den Proxy selbst eintragen. Gerade dies scheint mir hier aber nicht gewollt zu sein. Zwei Lösungsansätze sind mir dazu noch eingefallen: 1) Isa-Firewallregelwerk dicht machen und die Browser per WPAD konfigurieren. Siehe http://www.msisafaq.de/Anleitungen/2004/Konfiguration/wpad.htm 2) den TFK-Proxy als Upstreamproxy für den ISA verwenden. Siehe http://www.msisafaq.de/Anleitungen/2004/Konfiguration/Webverkettung.htm Gruß Steffen

Entweder Downgrade auf ISA2000 oder die Linuxvariante (Squid als transparenter Proxy). Gruß Steffen

Hi, der Isa-Server leitet auch normale Routing-Anfragen intern über _sein_ Proxymodul, wenn es sich dabei um die typischen Webprotokolle handelt (http, ftp). Entsprechende Proxyerweiterungen greifen so auch für diese (Routing-)Clients. Wir nutzen ebenfalls TFK, allerdings als Plugin für den ISA2000. Der Filter funktioniert dann definitiv auch bei (Routing-)Clients. Vermutlich habt Ihr den Proventia-Filter (welcher Bestandteil von TFK ist) nicht als ISA-Plugin im Einsatz, sondern als eigenständigen Proxy. Wenn dem so ist, sehe ich keine Möglichkeit, die von Dir gewünschte Funktionalität zu erreichen. Es sei denn, Ihr stellt auf die Plugin-Variante um, wobei ich nicht weiss, ob diese zwischenzeitlich überhaupt für den ISA2004 verfügbar ist (als wir dieses Produkt implementiert haben, funktionierte das Plugin nur unter ISA2000). Gruß Steffen

Also was den Webserver angeht, ist das ziemlich einfach. Du könntest auf dem alten Webserver z.B. eine Weiterleitung per Meta-Tag einrichten: <html> <head> <meta http-equiv="refresh" content="3; URL=http://web2"> </head> <body> Klicken Sie bitte auf folgenden Link, falls Sie nach 3 Sekunden nicht automatisch weitergeleitet werden: <a href="http://web2" target="_self">http://web2</a> </body> </html> Dies veranlasst den Browser, die neue Adresse abzurufen. Eine weitere Möglichkeit wäre, den Traffic auf dem alten Server in Richtung des neuen umzubiegen. Z.B. mit einem Janaserver-Extragateway. Für den Fileserver fällt mir hingegen keine Lösung ein. Gruß Steffen

Guten Morgen, worum gehts genau? Du schreibst im Betreff von HTTP-Anfragen und dann im eigentlichen Posting von Fileserver... Gruß Steffen

Und wo soll der zentrale Proxy-Server stehen und wie ist dieser ans Internet und an die Schulen angebunden?Die Internetanbindung des zentralen Proxys müsste bei Deiner prognostizierten Userzahl schon "etwas dicker" sein. Des Weiteren müssten die Schulen auf diesen Server gesichert zugreifen können (z.B. per VPN). Auf keinen Fall sollte man einen Proxy (unauthentifiziert) über das Internet verfügbar machen. Das lädt zum Mißbrauch geradezu ein. Über einen HTTPS-Proxy kann man - wenn er dafür anfällig ist - sogar Mails versenden! Gruß Steffen

Guten Morgen, Deshalb: ;) Bei einem Viertklässler sehe ich die Gefahr als nicht allzu groß. Da halte ich es schon für wahrscheinlicher, dass z.B. ein Gymnasiast versucht, mit einem alternativen Browser unter Umgehung des Contentfilter-Proxys zu surfen. Letztlich musst Du also ohnhin per Firewallregelwerk dafür sorgen, dass von Clients aus nicht direkt ins Internet zugegriffen werden darf. Wenn Du das sichergestellt hast, ist es doch egal, ob ein Schüler den Proxyeintrag entfernt - es nützt ihm nichts. Ich schätze mal, es handelt sich um das Produkt von Time for Kids, oder? Deren Lizenzmodell sieht eigentlich eine schulweise Lizensierung vor. Es wäre also nicht legal, nur eine unlimitierte Schulversion zu kaufen und darüber alle Schulen zu schützen. :suspect: Bestimmt gibt es auf Nachfrage aber auch eine Schulträger-Version. Ob die dann allerdings wesentlich preisgünstiger ist, als die Abnahme mehrerer Schullizenzen, wage ich zu bezweifeln. Trotzdem wäre ein zentraler Ansatz wünschenswert, weil damit der Administrationsaufwand deutlich sinkt. Ich sage das aus eigener leidvoller Erfahrung, da ich (u.a.) ebenfalls knapp 20 Schulen betreue. Leider ist es mir dort aus verschiedene Gründen nicht möglich, einen zentralen Ansatz zu fahren. Ein Grund ist, dass die Anbindung an die Zentrale (über Site-to-Site-VPN) zu schmalbandig ist (insbesondere die Internetanbindung unserer "Zentrale" ist dafür zu unterdimensioniert). Bandbreite und Zuverlässigkeit der Anbindung an die Zentrale sind in meinen Augen ein wichtiges Kriterium für dieses Vorhaben. Die ausreichende Dimensionierung des zentralen Servers dürfte weniger ein Problem sein. Wie sind denn die Schulen an die Zentrale angebunden? Gemietete Festverbindungen, eigene Leitungen, RAS, VPN? Wie sind die Bandbreiten? Gruß Steffen

Hallo, Policy Based Routing geht z.B. mit der Zywall-Serie von Zyxel beginnend mit der Zywall 5 ab 400 EUR.Problem dabei: angenommen, Du routest nur den Verkehr auf den Proxy, wo der Ziel-Port gleich 80 oder 443 ist, dann werden Anfragen, wo die Seite nicht auf den Standardports liegt, nicht an den Proxy geroutet. Des Weiteren müsste der Proxy (zumindest auch) als transparenter Proxy laufen. Mit dem ISA ist dies kein Problem. Mit dem Squid (der m.W. von der Standalone-Version des Proventia Webfilters benutzt wird) gehts wohl nur unter Linux. Beachte zudem, dass m.W. keine Benutzerauthentifizierung am transparenten Proxy möglich ist, es sei denn, man setzt den ISA zusammen mit dem Firewallclient ein. Ist es denn wirklich so aufwendig, dass auch an den "Kleinst-Standorten" der Proxyeintrag gesetzt wird (entweder per Skript oder halt vom User selbst)? Zumindest an größere Standorte würde ich zudem einen "lokalen" Proxy stellen, welcher den Webfilter-Proxy als Upstream-Proxy benutzt. Gruß Steffen

Hi, Ich fänd es ja wesentlich interessanter, wenn bei identischen _IP-Adressen_ ein Zugriff noch möglich wäre... :rolleyes: Vermutlich meinst Du, dass Clients und Server in verschiedenen Netzen liegen. Das funktioniert dann natürlich nur, wenn sich (mind.) ein Router zwischen diesen Hosts befindet. Ob Clients und Server allerdings wirklich in unterschiedlichen Netzen liegen, lässt sich nicht sagen, weil Du uns die Subnetmask nicht verraten hast! Die Nennung einer IP-Adresse ohne verwendete SM ist spätestens seit CIDR völlig sinnlos! Die von Dir genannten IP-Adressen stammen (eigentlich) aus einem öffentlichen Class-B-Netz. Die damit standardmäßig assoziierte Subnetmask wäre 16 Bit lang - die Hosts wären also im gleichen Netz. Lange Rede - kurzer Sinn: vervollständige Deine Angaben! Neben den Subnetmasken werden auch Angaben zu Gateway-/Routingseinträgen sowie eine Beschreibung des Netzwerkaufbaus benötigt. Gruß Steffen

Es gibt sehrwohl XPpro Upgrades als Boxprodukt. Ob diese Lizensierungsform hier allerdings sinnvoll ist, ist eine ganz andere Frage. Die Box-Upgrades kosten fast das Doppelte einer OSB Vollversion und aktiviert werden müssten sie dann auch noch. :shock: Gruß Steffen

- Fortsetzung - Host B empfängt den Traffic und stellt fest, dass die Ziel-IP im Layer 3-Header seine eigene ist. Er inspiziert daraufhin auch Layer 4 und übergibt die Nutzdaten an das Janaserver-Extragateway, welches auf Port 8001 lauscht. Anders als ein HTTP-Proxy interpretiert dieses die Nutzdaten jedoch nicht! Völlig unabhängig vom Inhalt verpackt es die Daten nun (entsprechend den Vorgaben in der Extragateway-Definition) in ein neues IP-Paket und dann in einen neuen Ethernet-Frame. Das sieht dann (vereinfacht) so aus: ______________________________________________ | Ziel-Hardwareadresse = Hardwareadresse von Host C | Quell-Hardwareadresse = Hardwareadresse von Host B ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Ziel-IP-Adresse = vordefinierte Ziel-IP-Adresse (hier von Host C) | Quell-IP-Adresse = IP-Adresse von Host B ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Transport-Protokoll: TCP | Quellport = dynamisch, > 1024 | Zielport = vorgebener Port des Zieles (hier: 8000) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Anwendungsprotokoll: ESTP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fassen wir also zusammen: 1. Das Extragateway arbeitet _nicht_ auf Anwendungsprotokollebene. Was an Nutzdaten übermittelt wird, ist ihm egal. Die Nutzdaten werden durch das Extragategateway lediglich "umverpackt"/neu adressiert und zwar nach einem zuvor definierten Regelwerk. Auch die Absender-IP-Adresse wird dabei geändert. Aus Sicht des empfangenden Servers scheint der Janaserver der Client zu sein. 2. Das Ziel eines Extragateways steht fest (IP-Adresse oder DNS-Name). Für jedes unterschiedliche Ziel muss ein separates Extragateway definiert werden! Deshalb kann man in Agenda auch mehrere Ports angeben --> für jeden möglichen Elsterserver muss ein gesondertes Extragateway auf einem anderen "lokalen Port" angelegt werden. 3. Anders als bei Verwendung eines Routers muss der Client das Extragateway mit dessen IP-Adresse und Port als Ziel ansprechen. Dies kann erreicht werden, indem in der Anwendung der Janaserver explizit als Ziel angegeben wird. Wenn dies nicht möglich ist, die Anwendung jedoch vor der Kontaktaufnahme mit dem Server eine DNS-Auflösung startet, kann man sich behelfen, indem man die Namensauflösung manipuliert (Umbiegen auf die IP-Adresse des Janaservers). Ich hoffe, die Unterschiede zu einem Router und einem ALG (insbesondere einem HTTP-Proxy) sind durch meine Ausführungen verständlich geworden. Weshalb ist dies nun eine meiner Lieblingsfunktionen in Jana? Schlicht deshalb, weil man damit sehr einfach Traffic umbiegen kann. Das kann man z.B. vorübergehend bei der Migration von Serverdiensten auf andere Hardware gebrauchen (um den Produktivbetrieb so kurz wie möglich zu stören). Sicherlich gibt es dafür bessere Tools. Janaserver beinhaltet aber eben auch noch andere Dienste, die man ab und an nur vorübergehend benötigt (z.B. einen FTP-Server um Dateien zu übertragen, wenn kein SMB zur Verfügung steht oder einen IMAP-Server um Mails "zwischenzulagern"). Nicht zuletzt enthält Jana viele Schnittstellen, in die man z.B. Skripte einbinden kann. So gesehen ist der Janaserver also u.a. _auch_ eine nützliche Toolbox für (vorübergehende) Spezialaufgaben. Gruß Steffen

Hallo, sorry, dass ich erst jetzt antworte – ich war die letzten Tage sehr beschäftigt. :( Nachfolgend mein Erklärungsversuch. Angenommen wir haben folgende Umgebung: | --- Subnet 1 ---- | ---- Subnet 2 ---| | Host A | --- | Host B | --- | Host C | Bei Host A handelt es sich um einen Client, auf dem die Elster-Anwendung läuft. Er muss mit Host C (Elster-Server) kommunizieren. Die Kenntnis darüber, wie die Kommunikation abläuft, wenn es sich bei Host B um einen Router handelt, setze ich mal voraus. Hier soll Host B ein Janaserver mit 2 Ethernet-Interfaces sein. Zwischen den angeschlossenen Subnetzen wird nicht geroutet (Jana selbst kann diese Funktionalität auch nicht bereitstellen). Janaserver bietet neben Serverdiensten wie Webserver, Mailserver usw. u.a. mehrere sog. Application-Level-Gateways. Hier sind insbesondere zu nennen: HTTP/S-Proxy, FTP-Proxy, FTP-Gateway und Realplayer-Proxy, DNS-Proxy. Diese arbeiten auf Anwendungsprotokollebene, d.h. sie "verstehen" (zumindest teilweise) das verwendete Anwendungsprotokoll. Aufgrund dessen ist es bspw. möglich, mit einem HTTP-Proxy den Aufruf bestimmter Seiten zu sperren. Nachteil (bzw. je nach Sichtweise ein Vorteil) eines ALG ist, dass es spezifisch auf das jeweilige Anwendungsprotokoll zugeschnitten ist. Andere Protokolle kann es (bzw. sollte es eigentlich) nicht übertragen. So sollte beispielsweise über einen HTTP-Proxy kein SMTP-Verkehr möglich sein (es gibt jedoch Techniken, mit denen dies dennoch möglich ist --> HTTPS-Connect-Methode, Tunneling). Elster verwendet ein propritäres Protokoll namens ESTP. Hierfür gibt es in Janaserver kein spezielles ALG. Man hätte hier also ein massives Problem! Aufgrund des Drucks der Anwender haben die Elster-Entwickler mittlerweile die Möglichkeit geschaffen, ESTP in HTTP zu "verpacken" und so durch einen HTTP-Proxy zu tunneln. In ElsterFT ist dies mit implementiert. Viele Programme von Drittanbietern unterstützen dies selbst jedoch nicht (so scheinbar auch Agenda). Hierfür gibt es dann das Programm ElsterHTTPTunnel (https://www.elster.de/elfo_tunnel.php). Agenda bietet dafür aber eine andere Möglichkeit und zwar eine Art "generisches Gateway" anzusprechen, wie es u.a. in Janaserver (und scheinbar auch in AVM KEN) definiert werden kann. Bei Janaserver heisst diese Funktion "Extragateway". Man definiert ein solches durch Festlegen des Transportprotokolls (TCP oder UDP) und eines "lokalen Ports" sowie des Zielservers (DNS-Name oder IP-Adresse) und des Ziel-Ports. Nach der Aktivierung dieses Extragateways lauscht der Janaservice auf dem eingestellten lokalen Port. Alles was dort ankommt, wird an das eingestellte Ziel weitergereicht. Nehmen wir mal an, das Extragateway würde folgendermaßen definiert: Protokoll: TCP lokaler Port: beliebiger freier Port (hier beispielsweise 8001) Ziel-IP: IP-Adresse von Host C (Elsterserver) Ziel-Port: 8000 (Elster-Port) Damit in unserem Beispiel Host A mit Host C "elstern" könnte, darf Host A nicht Host C auf Port 8000, sondern muss Host B (Janaserver) auf Port 8001 ansprechen. Der Traffic von Client zum Janaserver sieht also (vereinfacht) so aus: ______________________________________________ | Ziel-Hardwareadresse = Hardwareadresse von Host B | Quell-Hardwareadresse = Hardwareadresse von Host A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Ziel-IP-Adresse = IP-Adresse von Host B | Quell-IP-Adresse = IP-Adresse von Host A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Transport-Protokoll: TCP | Quellport = dynamisch, > 1024 | Zielport = der Port des Extragateways (hier: 8001) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Anwendungsprotokoll: ESTP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Um dies zu erreichen, muss der Admin in der Elster-Anwendung IP-Adresse und Port des Extragateways angeben können. In Agenda kann man nur Ports angeben. Die IP-Adresse setzt Agenda scheinbar als mit der des Proxys identisch voraus. - Fortsetzung siehe nächstes Posting -

Hmm. Scheinbar benennt G-DATA jetzt seine Produktlinien etwas anders (war gerade auf deren HP). Jetzt heisst es nur noch AVK Client/Server oder AVK 2006. Letztere ist eine Einzelplatzinstallation. Als ich damals kaufte, hieß das - soweit ich mich erinnere - noch AVK 11 Client/Server und AVK Professional 2002 (Einzelplatz). Oder war es vielleicht doch AVK 11 Professional für die Einzelplatz-Version? Ich weiss es nicht mehr. Na jedenfalls dachte ich, Dein Hinweis bezog sich auf die C/S-Variante und man würde von G-DATA die Einzelplatzversion als "Problemlöser" erhalten (was ja wohl ein schlechter Scherz wäre). Gruß Steffen

Hast Recht. Habs gerade nochmal gestestet. ;) Der Proxy-Dienst selbst benötigt natürlich keine Paketfilter-Regel. Der fehlende Gateway-Eintrag erklärt, weshalb es am Client ohne Proxyeintrag in Agenda nicht funktionierte. Bei Vornahme der Proxyeinstellungen im Programm hätte der Verbindungstest über HTTP auch am Server funktionieren müssen (siehe oben). Ohne Proxyeintrag hättest Du eine Paketfilterregel benötigt. Für Elster am Server kommst Du um eine Paketfilterregel nicht herum, weil kein Webproxy-fähiges Protokoll verwendet wird (und auch kein Proxytunneling). Agenda schreibt zwar in der Anleitung, dass der Proxy benutzt würde, dies ist aber Quatsch. Es werden sog. Extragateways am Janaserver angesprochen (bzw. die vergleichbare Funktionaliät in KEN). Wenns interessiert, mach ich morgen ein paar Ausführungen dazu, was ein Extragateway beim Janaserver technisch ist (übrigens meine Lieblingsfunktion in Jana :cool: ). Für heute soll's erst mal genug sein. Bin jetzt offline... :wink2: Gruß Steffen