s.k.

Janaserver Extragateway oder AnalogX Portmapper Gruß Steffen

Hallo Johannes, ich hab durchaus Sympathien für Deine Ansichten hinsichtlich des ISA-Servers bzw. zum zu Grunde liegenden OS. Je weniger Zeilen Code, desto weniger Fehler können drin sein. Mit steigender Komplexität eines Produktes steigt die Wahrscheinlichkeit, dass Entwickler und/oder Admin Fehler machen. Umso mehr amüsiert und verwundert es mich, dass Du gleich im Anschluss die Astaro lobpreist. Sie ist unzweifelhaft gut gemacht, jedoch ein klarer Verstoß gegen den vorgenannten Grundsatz! Hauptsache viele Features aus verschiedenen Quellen in einer Box zusammengefrickelt.... :rolleyes: Ich sehe den Trend zu All-In-One UTM-Boxen - so charmant sie auf den ersten Blick auch sein mögen - jedenfalls sehr kritisch! Wie oft hat man beispielsweise schon lesen müssen, dass Antivirus-/Antispam-Gateways durch entsprechend präparierte Mails attackiert werden konnten (Symantec, F-Secure, Trend Micro...)? Jede (Sicherheits-)Lösung schafft halt neue (Sicherheits-)Probleme - das ist normal. Ist es nicht allein deshalb schon sinnvoller, Teilaufgaben auf spezialisierte Systeme aufzuteilen, damit die Kompromittierung eines Teilsystems nicht sofort zum Flächenbrand wird? Ich plädiere jedenfalls sehr dafür, die "klassische" Firewallfunktionaliät bis Layer 4 von den Application-Level-Gateways und sonstigen auf höheren Schichten arbeitenden Diensten zu trennen. Gruß Steffen

Wie kann ich die Bremsscheiben an meinem Benz wechseln? Das Ding springt nicht an! Oder anders gesagt: wonach er explizit fragt, ich nicht das, was er benötigt. :rolleyes: Siehe 2K3 - Root-Server mit mehreren IPs (WAN IPs auf LAN IPs umleiten) Gruß Steffen

Hat halt alles seine zwei Seiten. :p Ich mail Dich dann an. Gruß Steffen

@Retro: Alles Phantasiewerte der Marketingabteilungen. Nimm 3 Prospekte aus unterschiedlichen Auflagen und die wirst mindestens 5 verschiedene Durchsatzangaben finden. Teilweise wiedersprechen sie sich noch auf der selben Seite. ;) Hier etwas realistisches: KB-2187 @il_principe: Leider nein. Ich hatte mich schon für den 9. in Würselen angemeldet, aber die bekamen die Boxen ja nicht rechtzeitig rangeschafft und haben den Termin in meine Urlaubszeit verschoben. Nun kann ich das Teil erst im November begutachten. :( Bekommen wir das hin, uns bei der nächsten Workshopreihe mal gemeinsam für einen Termin in Süddeutschland anzumelden? Nach einer Dienstreise nach Österreich brauche ich meinen Chef leider nicht fragen... Gruß Steffen

@Reto64: Nimm die 2Plus wenn Dir die Features ausreichen (Anzahl VPN-Tunnel, fehlende UTM-Funktionalitäten). Benötigt man das "Mehr" an Funktion nicht, wäre die 5er rausgeworfenes Geld. Zumal die 5er nächstes Jahr durch die USG100 ersetzt wird. Die 2Plus bleibt vermutlich noch etwas länger im Programm (und damit auch im Support). Die 2Plus hat sogar ein Feature, welches die 5er nicht hat und wohl auch nicht mehr bekommen wird: NAToverIPSec. Ich denke, die 2Plus ist vom Preis/Leistungsverhältnis her ein sehr attraktives Angebot. Über die billige Plastikbox muss man halt hinwegsehen. Und last but not least: Der wesentlich geringere Kaufpreis macht es einem auch leichter, die Boxen in 2 Jahren wegzuwerfen, wenn sich die Anforderungen weiterentwickelt haben... ;-) Gruß Steffen Nachtrag: Wo hast Du eigentlich die 65MBit Datendurchsatz für die 5er her? Davon träumen die Vertriebler vielleicht nachts, aber mit der Realistät dürfte das wenig gemein haben.

Wenn sich das Notebook am Heimarbeitsplatz befindet, müssen IP-Adresse, Subnetzmaske und Standardgateway logischerweise zum dortigen Netz passen - der einfachste Weg wäre DHCP. Als DNS-Server jedoch nicht den Router verwenden, sondern den oder die DNS-Server aus dem Firmennetz. Das kann man fest einstellen, auch wenn die übrigen Einstellungen per DHCP bezogen werden. Was sagt das Ereignisprotokoll mit diesen Settings? Gruß Steffen

Die Integration von OpenVPN in die Astaro finde ich auch recht gelungen. Allerdings bringt der ganze Thread so rein gar nichts. "SSL-VPN" sagt - vom eingesetzten Protokoll abgesehen - nichts über die tatsächlichen Features aus. Was wird denn benötigt? Nur ein IPSec-ähnlicher Full-Tunnel? Oder z.B. ein personalisiertes Portal, ggf. mit Reverse-Proxys? Sollen RDP- und VPN-Clients integriert sein? Soll die Zugriffssteuerung Benutzer- und Gruppenbasiert möglich sein? Ist Endpointcontrol gewünscht? Die Liste ließe sich noch unendlich fortsetzen... Gruß Steffen

Hallo, wird der VPN-Tunnel am Heimarbeitsplatz auf dem Router terminiert (also Site-to-Site) oder ist auf dem Notebook ein IPSec-Client installiert? Gruß Steffen

kostenloser IPSec-Client: Shrew Soft Inc. Alternative: SSL-VPN (z.B. mit OpenVPN) Gruß Steffen

Wenn es nur wenig kosten darf, wäre mein Vorschlag, den Netgear durch eine Zywall 2 Plus zu ersetzen. Deren 4 "inside"-Ports kann man flexibel auf die Zonen "LAN", "DMZ" und "WLAN" aufteilen. Das ist dann eine Trennung auf Layer 2. Den Traffic zwischen den Zonen kann man per Firewall beregeln. Allerdings bietet die 2er nur 5 IPSec-Tunnel. Wenn mehr Tunnel benötigt werden, stellt man den Netgear (50 Tunnel) einfach vor die Zywall (Frontend/Backend-Firewall-Konstellation). Gruß Steffen

Reines IP-Forwarding ohne NAT (könnte man mit RRAS machen) nützt Dir in diesem Fall aber nichts. Gruß Steffen

Man könnte den Janaserver nutzen, um per sog. Extragateway TCP- oder UDP-Traffic durchzureichen. Allerdings ist damit nur die Weiterleitung einzelner Ports möglich - keine Ranges oder gar ein 1:1-NAT. Auch muss der stattfindene Traffic vorher bekannt sein, um für ihn ein Extragateway definieren zu können. Nachgelagerte Verbindungen mit dynamischen Ports kann man damit nicht verarbeiten. Aktives FTP oder P2P-Dienste funktionieren darüber z.B. nicht. Wenn die VMs aber nur eine begrenzte Anzahl von Diensten mit statischen oder vorhersagbaren/vordefinierbaren Ports bereitstellen, lässt sich dies mit Jana umsetzen. Passive FTP-Server und Webserver sind bspw. kein Problem. Wobei sich letzteres auch mit einem Reverseproxy realisieren lässt (ebenfalls in Jana enthalten). Gruß Steffen

Hallo, wenn der RAS-Server nicht nattet, dann muss dem DSL-Router die Route in das Netz 192.168.82.0/24 bekannt gemacht werden, sonst schickt er die Antworten an sein Defaultgateway (also wiederum ins Internet). Entweder werden DSL-Router und RAS-Server so konfiguriert, dass sie sich per Routingsprotokoll über die ihnen bekannten Routen und Netze austauschen (z.B. per RIP) oder man trägt auf dem DSL-Router eine statische Route ein. Gruß Steffen

Im Prinzip geht das mit selbst erstellten Zertifikaten für lau. Für kleine Umgebungen muss noch nicht mal eine PKI aufgebaut werden. Die Zywalls bingen die nötige Funktionalität von Haus aus mit. Du kannst auf der Zywall nur eine sog. Gatewaypolicy (=Phase 1) anlegen, wo die Gegenstelle unbekannt ist. Hierüber werden dann alle VPN-Clients und Remote-Gateways abgehandelt, die Du nicht über eine öffentliche IP-Adresse oder einen DNS-Namen (=propritär) "greifen" kannst (Client-to-Site oder Site-to-Site mit Client-to-Site-Charakter). Arbeitest Du hier mit PSKs, haben alle diese Clients und Gateways zwingend den gleichen PSK. Stell Dir die Konsequenzen für die Sicherheit der übrigen Verbindungen und den Änderungssaufwand für Dich vor, wenn Du 50 solcher Clients hast und einer davon in falsche Hände fällt... Bei Verwendung von Zertifikaten hat jede Gegenstelle ein eigenes Zertifikat. Geht eines dieser Geräte verloren, wird das entsprechende Zertifikat einfach zurückgezogen. Gruß Steffen

Weil es nur limited broadcasts erzeugen kann. Darauf weist der Hersteller auch hin: Quelle: Wake On LAN - Reviews and free downloads at Download.com Erklärung limited vs. directed broadcasts: siehe Wikipedia-Artikel Gruß Steffen

kostenlose Alternative: ZyXEL-Forum - kostenloser VPN-Client für Windows Gruß Steffen

Du benötigst ein WOL-Tool, welches sog. directed broadcasts unterstützt. Ich nehme hierfür das Kommandozeilentool, welches bei AdminsPowerswitch dabei ist. Gruß Steffen

http://www.mcseboard.de/windows-forum-ms-backoffice-31/reverse-proxy-116134.html Gruß Steffen

Was spricht gegen IMAP oder Webmail? Gruß Steffen

Hallo, Kann man so konfigurieren. Auslieferungszustand ist es hingegen nicht. Also von intern auf einen externen Webserver? Sollte doch nun wirklich nicht so schwer sein! :suspect: Läuft der Webserver auf den Standard-TCP-Ports 80 bzw. 443? Gruß Steffen

@dz69: ja ein Reverseproxy wäre genau das richtige. Ein ISA wäre für mich erste Wahl. Zu Apache kann ich mangels diesbezüglicher Praxiserfahrung nichts sagen, ausser dass er wohl gdrs. auch als Reverseproxy betrieben werden kann. Für kleinere Installationen mit Mini-Budget kann man auch mal einen Blick auf den Janaserver werfen - der unterstützt das seit kurzem auch. Gruß Steffen

Der Einsatz mehrerer Homeplug-Adapter ist möglich. Ich setze zuhause 3 ein, um Router und Drucker zu sharen. Allerdings hatte ich mal irgendwo gelesen, dass der Durchsatz mit steigender Gerätezahl massiv einbrechen soll. Grund ist wohl die aufwendige Kollisionserkennung. Auch stehen die 200 MBit bei HomeplugAV (genau wie bei WLAN ja auch) nur auf dem Papier. Netto dürfte man bei ungünstigen Bedingungen schnell wieder in einem Bereich sein, mit denen z.B. cifs-Zugriffe einfach keinen Spass machen. Wie wäre es stattdessen oder ergänzend mit POF? Gruß Steffen

Hallo Squire, die Konstruktion als solche, wäre sicher auch nicht meine Wahl gewesen - davon mal abgesehen. Der Janaserver ist klasse, wenn man etwas mehr Kontrolle über die ISDN-Verbindung benötigt, damit einem die Kosten nicht aus dem Ruder laufen. Das scheint mir aber aufgrund von ISDN-Flats nicht mehr entscheidend. Auch ist das so? Dann erkläre doch bitte mal, inwieweit der Exchange dadurch besser vor möglichen Bedrohungen aus dem externen Netz geschützt sein soll!In dem Szenario mit dem Exchangeserver auf einer eigenen Maschine hinter dem Janaserver-Host gibt es keine Möglichkeit, die Verbindung von extern zum Exchange zu initieren. Der Exchange "spricht" lediglich von intern nach extern die Providerserver an - und auch nur diese, andere sind nicht möglich. Auch die Windowskiste vermag ich nicht per se als Schwachpunkt zu erkennen. Zum einen steht sie bei einer Wählverbindung nicht ständig im Netz, zum anderen deaktiviert man auf der DFÜ-Verbindung alle Bindungen außer TCP/IP und aktiviert die Windowsfirewall. Wenn dann das System immer aktuell gepatcht wird, dürfte diese Konstruktion sogar sicherer sein, als eine Linux-Kiste, für dessen Betrieb möglicherweise nicht das nötige Know-How vorhanden ist (ich verweise nur auf die Nachfrage des TO, worin der Unterschied zwischen POP3- und SMTP-Connector bestünde :rolleyes:). Zumal der von Dir vorgeschlagene IPCop, was die Firewallfunktionalität auf Layer 3 und 4 angeht, keine professionellen Ansprüche erfüllt. Da ist bspw. ein pfSense um Welten besser. Auch und gerade was die Erschwerung ungewollten Traffics von intern nach extern angeht, ist die Janaserver-Lösung gegenüber der IPCop-Lösung für einen kleinen Laden ohne fachkundige Administration durchaus vorteilhaft. Die Windows-Kiste routet standardmäßig nicht. Alles was von intern nach extern will, muss in irgend einer Form Dienste des Janaservers nutzen (welche aber erst einzeln aktiviert werden müssen - standardmäßig läuft nur der Administrationswebserver auf localhost). Mit Ausnahme der genannten Extragateways (welche aber explizit anzulegen und auf vordefinierte Zieladressen beschränkt sind sowie mit der Benutzerverwaltung des Proxys kombiniert werden können) laufen alle Janadienste auf Layer7 - mit den entsprechenden Steuerungsmöglichkeiten einschließlich Benutzerauthentifizierung. Wo der Standardumfang des Janaservers nicht ausreicht, gibt es Erweiterungen in Form von einfach einzubindenden ISAPI-Filtern. So z.B. um das Tunneln des Proxys per HTTPS-Connect-Methode zu unterbinden oder zumindest zu erschweren. Linux ist nicht per se in allen Szenarien die Wunderwaffe, die alles besser macht. Auch nicht als vorgefertigte Firewalldistri. Man sollte immer die konkreten Anforderungen und vorallem den Kenntnisstand derer im Auge behalten, die das einsetzen und administrieren sollen. Auch wenn auf der Lösung mit dem dedizierten Janaserver-Host nicht in großen Lettern das Wischiwaschi-Marketing-Wort "Firewall" draufsteht, kann man damit sehrwohl unerwünschten Traffic wirkungsvoll unterbinden. Ich bin gespannt auf Deine Argumente. Gruß Steffen

Der Thread ist zwar schon etwas älter, der Vollständigkeit halber sei aber erwähnt, dass man auf dem Janaserver auch sog. Extragateways anlegen kann. Das sind eine Art generische Relays auf Layer 4 - so würde ich das bezeichnen. Verfügbar für TCP und UDP. Unter der Voraussetzung, dass im vorliegenden Fall für den Versand ein SMTP-Relay beim Provider benutzt wird (was in Anbetracht dessen, dass man über ISDN surft und die Mails per POP3-Connector von externen Postfächern einsammelt, wahrscheinlich ist), würde man folgendermaßen verfahren: Für den Versand: - Definition eines TCP-Extragateways auf dem Janaserver: lokaler Port=25, Zielserver=Name oder IP-Adresse des Providerrelays, Zielport=25 (oder abweichend nach Providervorgabe) - auf dem Exchange wird der Janaserver als Relay angegeben Für den Abholung per POP3-Connector: - Definition eines TCP-Extragateways auf dem Janaserver: lokaler Port=110, Zielserver=Name oder IP-Adresse des Provider-POP3-Servers, Zielport=110 (oder abweichend nach Providervorgabe) - auf dem POP3-Connector des Exchange wird der Janaserver als POP3-Server angegeben Der Vorteil gegenüber der Nutzung des Jana-Mailservers wäre, dass dies deutlich weniger Konfigurationsaufwand wäre. Der Nachteil dieser Lösung ist jedoch, dass man weniger Kontrolle über die ISDN-DFÜ-Verbindung hat. Der Janaserver würde bei Traffic die Verbindung aufmachen und erst nach einem Timeout wieder schließen. Beim Mailserver von Jana kann man hingegen einstellen, dass die Verbindung sofort nach Abholung/Versand wieder geschlossen werden soll. Auch sind Mindestzeitabstände für erneuten Verbindungsaufbau und die Zeitplanung von Verbindungsaufbauten möglich. Da es mittlerweile aber auch ISDN-Flats gibt, sollte das weniger bedeutsam sein. Gruß Steffen