s.k.
-
Gesamte Inhalte
399 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von s.k.
-
-
@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:Wenn ich localhost hier veröffentliche läufts. Kann ich das problemlios machen?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,
Es gibt im Isa eine aktivierte Zulassungsregel mit alle Ziele, immer zugriff zulassen, alle Anfragen und alle Inhaltstypengruppen.Eingetragen unter Server>Zugriffsrichtlinie>site- und Inhaltsregeln.[/Quote]Eine Site- und Inhaltsregel genügt in diesem Fall nicht. Wie sieht die Protokollregel für HTTP aus? Wurde dort vielleicht eine Einschränkung auf bestimmte Clientadresssätze gemacht, zu denen der Server nicht gehört?
Des Weiteren stellt sich für mich die Frage, weshalb Du überhaupt den lokalen Traffic über die Proxy-Komponente des ISA laufen lässt. Deaktiviere doch einfach die Proxynutzung oder definiere eine Ausnahme für die lokalen Ziele. Rein lokaler Traffic (localhost nach localhost) wird m.W. vom ISA2000 nicht beregelt (zumindest wenn man die Proxykomponente nicht anspricht).
Gruß
Steffen
-
Wir implementieren gerade für solche und ähnliche Informationen eine (für Unbefugte selbstverständlich unzugängliche!) Wissendatenbank auf Basis der Mediawiki.das Visio haben wir ja auch im Einsatz aber ich brauche ein Verwaltungstool wo ich z.Bps den Server eintrage die Funktion des Server Verwantwortlichkeit Verfügbarkeit also ziemlich viele Informationen und für das eigenet sich Visio eben nicht. Auch nicht zum Abfragen von InformationenGruß
Steffen
-
Dann pack den Gameserver doch auf den vServer oder besorg Dir zu Hause eine fixe IP...Hi,weil ich für den Gameserver gerne eine feste IP hätte und keinen DynDNS Namen.
Wo bekomme ich das Programm ?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
-
-
Funktioniert natürlich auch nur dann, wenn der Browser für die Suche konfiguriert ist. :( Beim IE ist das allerdings die Standardeinstellung.1) Das mit der automatischen Konfiguration habe ich auch schon gelesen und werde das demächst auch mal ausprobieren, das erscheint mir eine der erfolgsversprechendsten Varianten zu sein.
Dachte ich mir schon. Beim ISA2000 hätte es vermutlich funktioniert. Da wird der lokale Webtraffic nicht über das Proxymodul geleitet.2) Habe ich bereits probiert. Scheitert aber daran, dass ISA und TfK auf der selben Maschine laufen - sprich die Regel leitet den Traffic an Port 8080 weiter, der TfK filtert und will seinerseits als Upstream Proxy den ISA an Port 3128 verwenden, der das dann aber als Anfrage sieht und dank Webverkettung wieder an Port 8080 weiterleitet... --> Endlosschleife
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:Es soll wohl im Mai eine neue Version 1.7 des Filters rauskommen die dann auch ISA 2004 mit dem PlugIn unterstützt.
Gruß
Steffen
-
Das erfordert allerdings, dass die User den Proxy selbst eintragen. Gerade dies scheint mir hier aber nicht gewollt zu sein.Wenn du dann die Firewallregeln entsprechend einrichtest dürfte keiner mehr am Proxy "vorbei surfen".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?1Mbit DSL sind die Anschlüsse in den Schulen.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,
Default Gateway =! ProxyServer... Hab schon mal versucht einen Proxy per DHCP bzw. als Standard-Gateway zu verteilen, geht nicht.Deshalb:
Der Proxy müsste ... als transparanter Proxy konfiguriert sein.
;)Des Weiteren müsste der Proxy (zumindest auch) als transparenter Proxy laufen.
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.Bei den Außenstellen handelt es sich um Schulen, die Real, Gesamt & Gymnasien haben einen Server mit 2003 wo man einfach dann halt per Policy das festlegt, aber die kleinen Grundschulen haben keine Server. Den Proxy kann dann jeder 4. Klässler ausschalten, ist nicht Sinn un Zweck.
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.Für 20 Schulen haben wir derzeit Lizenzen, wenn man das auf eine Lizenz nun runterfahren kann mit einem zentralen Server wären die Kosten natürlich schnell wieder drin...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.Einige Außenstellen haben einen eigenen 2003 Server wo der Proxy per Policy verteilt werden könne, andere haben diesen nicht. Dort würde ich im Router gerne direkt eine feste Route eintragen, so dass jede http Anfrage auf den Webfilter geht.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:Lompulu:das interessante ist ja, das die Arbeitsplätze auf den Server zugreifen können, obwohl dieser eine andere IP hat.
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
-
Wenn du einen Volumenlizenzvertrag (Open, Selecct EA) hast kannst du Upgrades kaufen, sonst nicht.
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.Ich verstehe deine Frage nicht so recht Die genannten Versionen gibt es als sowohl als auch ;) AVK 11 (2002), 12 (2003), 2004, 2005, 2006. Hilft dir das weiter?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.Gestern hatte ich am Server nur Protokollregeln für FTP, und HTTP gesetzt. ... Er hat nur mit lokalem Proxyeintrag 8080 funktioniert.
Der fehlende Gateway-Eintrag erklärt, weshalb es am Client ohne Proxyeintrag in Agenda nicht funktionierte.Gestern hatte ich am Client noch keinen Standardgateway. Der IE funktionierte nur über WPAD.
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:Probiert hatte ich es aber auch am Server. Gestern hatte ich am Server nur Protokollregeln für FTP, und HTTP gesetzt.Gruß
Steffen
W2k3 - dynamische routingtabelle enthält falsche Einträge ...
in Windows Forum — LAN & WAN
Geschrieben
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