Jump to content

s.k.

Members
  • Gesamte Inhalte

    399
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von s.k.

  1. :D

     

    Hups, da sollte eigentlich Layer 3 stehen... ;-)
    Ich nehme an, Du suchst einen Switch, der IP-Forwarding beherrscht, also im Grunde (auch) als Router fungieren kann. Jedenfalls wird dies gemeinhin unter einem Layer3-Switch verstanden (Ich mag diesen Begriff nicht sonderlich, denn er ist ungenau. Dies sieht man bereits daran, dass es durchaus Switches gibt, die Funktionalitäten höher Layer2 bieten, jedoch nicht routen können [z.B. Priorisierung anhand Layer4 oder gar Layer7-Infos; Protokollbasierte dynamische VLAN-Zuordnung usw.]).

    Wenn Du also einen Switch mit Routingfunktionalität suchst, dann ist der 2810-48G nicht das richtige Produkt, denn davon finde ich im Datenblatt nichts. Siehe ProCurve Switch 2810 Serie (Data sheet/4AA1-6014DEE.pdf)

    Aber auch unter den "routenden Switches" gibt es riesige Funktionsunterschiede (z.B. Unterstützung dynamischer Routingprotokolle, Accesslisten etc.), so dass man m.E. eigentlich an dieser Stelle noch keinen Alternativvorschlag unterbreiten kann.

    Am besten Du beschreibst erst einmal Deine Umgebung und das was Du erreichen möchtest. Möglicherweise genügt ja auch ein Layer2(+)-Switch für Deine Anforderungen.

     

    Gruß

    Steffen

  2. Jedem Port teilst Du seine jeweilige VLAN-ID mit (1, 2, 3 oder 4) und gibst dem Router für jedes VLAN eine IP-Adresse in jeweils einem unterschiedlichen Subnetz (z.B. 192.168.1.1, 192.168.2.1, usw. -> der Router hat am Ende 4 IP-Adressen).

    Um es jetzt Deinem Rechner aus VLAN1 zu ermöglichen mit dem Drucker in VLAN2 zu sprechen, musst Du auf dem Router entsprechende Routen eintragen, z.B. Ziel-Netz 192.168.2.0 | Gateway 192.168.1.1. Für Pakete, die an den Rechner ins VLAN1 zurück gehen sollen, musst Du natürlich eine entsprechende Rückroute eintragen.

    Hallo zeppoliner,

    also Du hast ja durchaus viel Richtiges geschrieben und auch Einiges, was man so durchgehen lassen kann, wenn man nicht jedes Wort "auf die Goldwage legt". Aber das, was ich gerade zitiert habe, ist einfach nur Käse!

    Der Router kennt die Netze, mit denen er direkt verbunden ist, ohnehin schon - da muss man (zumindest auf dem Router) keine Routen mehr setzen! Bestenfalls muss noch IP-Forwarding aktiviert werden und dann können die Netze wieder miteinander kommunizieren.

    Da aber gerade letzteres nach dem Willen des TO nur eingeschränkt möglich sein soll, fehlt in Deinen Ausführungen noch der Hinweis auf den Einsatz von Accesslisten bzw. Filter-/Firewallregeln.

     

     

    ich bin erstaunt dieser Aussage, habe ich das doch anders begriffen. Warum muss das Layer 3 sein, warum funktioniert es nicht auf Layer 2? Kann ein Netzwerkteilnehmer nicht mehereren VLANs abngehören, ist es da nicht möglich, Schnittmengen zu bilden? "Subnetze" müessen doch nicht unbedingt unterschiedliche IP-(Sub)Netze sein.
    Hallo Edgar,

    Dein Einwand ist absolut berechtigt. Weder müssen in VLANs zwingend unterschiedliche IP-(Sub)Netze gefahren werden, noch ist dies zwingend für eine Kommunikation über VLAN-Grenzen hinweg erforderlich. Es geht durchaus auch auf Layer 2.

    Dot1q-konform und damit Hersteller-unabhängig geht dies z.B. mittels asymmetrischem VLAN. Siehe http://www.mcseboard.de/windows-forum-lan-wan-32/vlan-d-link-dgs-1248t-155307.html

    Ansonsten gibt es natürlich auch noch proprietäre Implementierungen.

     

    In der Praxis findet man das freilich selten, allein schon weil die Skalierbarkeit dieser Lösungen schnell durch die kognitiven Fähigkeiten des Menschen eine Begrenzung findet. Will sagen: Ein Routing zwischen verschiedenen IP-Netzen unter Reglementierung per Access-Listen ist nicht nur wesentlich feiner möglich, sondern bei steigender Komplexität auch für den Admin besser überschaubar.

     

     

    Gruß

    Steffen

  3. Teamviewer und Konsorten haben natürlich den Charme des Einfachen. Allerdings wird bei größeren Kunden mit strenger Security-/Datenschutzpolicy und eigener IT-Abteilung (wenn sie kompetent ist) dem Dienstleister der Weg ins Kundennetz vorgeschrieben und nicht andersherum.

    Die Nutzung von Teamviewer&Co ist häufig aufgrund des Dreiecksverhältnisses (man muss dem Anbieter trauen) verboten und im Rahmen des Möglichen unterbunden.

    Unsere Dienstleister bekommen 2 Möglichkeiten zur Auswahl: Cisco IPSec-Client oder SSL-VPN. Zur Einwahl wird ein Einmalkennwort generiert, welches beim Admin telefonisch zu erfragen ist. Wenn der Tunnel steht, kann hierdurch nur ein Admin-PC per VNC übernommen werden und der Admin schaut dem Dienstleister auf die Finger...

     

    Was ich damit sagen will: Man müsste wissen, welche Art Kunden Braintee betreut bzw. wer die Regeln vorgibt: der Kunde oder der Dienstleister?

     

    Gruß

    Steffen

  4. Hallo,

     

    Ich habe 2 VLANs konfiguriert.

    VLAN1: Ports für Server, Clients, NW-Drucker usw. untagged, Port für DSL Router tagged.

    VLAN2: Port für WLAN AP untagged, Port für DSL Router tagged.

    Kann denn der Router überhaupt mit tagged Frames umgehen? Hierzu müsste man virtuelle Interfaces auf dem Router konfigurieren können. Wenn das nicht möglich ist, kannst Du nicht mit einem tagged Uplink zum Router arbeiten.

    Die nächste Alternative wäre, mit 2 untaggt Uplinks zum Router zu arbeiten. Dafür müsste der Router mind. zwei getrennte physische Interfaces haben (z.B. LAN- und DMZ-Port). Vermutlich wird dies der Router auch nicht können, oder?

     

    Einfach wäre es mit reinem portbasiertem VLAN, einem speziellen proprietären Betriebsmodus vieler Switches - aber das bietet der DLink nicht.

    Stattdessen unterstützt er aber sog. asymmetrisches VLAN und das wird Dir hier helfen. Für einen VLAN-Anfänger dürfte das erstmal "harter Tobak" sein, führt aber auch zu einem genauen Verständnis der Funktionsweise von 802.1Q!

    Mal in 3 Sätzen zusammengefasst: Asymmetrisch bedeutet in diesem Zusammenhang, dass die Antwortpakete über ein anderes VLAN zurückkommen, als die Anfragen gesendet wurden. Es kommt darauf an, die Richtung des Datenflusses zu berücksichtigen. An einem Switchport eingehende Frames ("ingres"), welche _nicht_ getaggt (also mit keiner VLAN-ID markiert) sind, müssen vom Switch einem VLAN zugeordnet werden. Hierzu legt man als Admin eine sog. PVID fest. Diese Zuordnung ist logischerweise eine 1:1-Beziehung. Vom Switch ausgehende Frames können jedoch sehrwohl für mehrere VLANs untaggt sein (zumindest wenn der Switch das zulässt - manche Hersteller entmündigen hier den Admin!). In Verbindung mit .1q-unaware Endgeräten ergibt sich hieraus die Möglichkeit, den Traffic je nach Richtung in unterschiedliche VLANs zu packen und dadurch eine Trennung von VLAN-Gruppen bei gleichzeitiger Nutzung gemeinsamer Ressorcen (hier der Router) zu realisieren. Hier ein Beispiel: http://www.gsi.de/documents/DOC-2006-May-71-1.ppt (Folie Nr. 20). In der Konfigurationsoberfläche des DLINK ist ebenfalls ein Beispiel hinterlegt.

     

    Gruß

    Steffen

  5. Also einige Deiner Anforderungen sind wenig rational!

     

    Das Problem ist, dass dieses Gerät laut Aussage des Netgear Routerberater kein DSL-Modem dabei hat.
    Lieber eine Box ohne integriertes DSL-Modem nehmen, denn das erleichtert die möglicherweise spätere Umstellung auf einen Internetzugang, wo der Provider Ethernet übergibt.

     

    Die Firewall ... braucht kein Gbit (DSL 1000) aber die LAN-Schnittstellen.
    Die VPN-Box würde ich nicht als Switch mißbrauchen, sondern einen (oder mehrere) dedizierte/n Switch/e für das LAN verwenden. Bei WAN-seitigem DSL1000 ist eine 10/100er LAN-Verbindung ohnehin mehr als reichlich.

     

    Ich würde den Server gerne über 2 Gbit LAN-Schnittstellen ans Netz(Lokal in der Filiale) anschließen, um den Netzwerktrafic etwas zu verteilen (Lokales Netz an eine Schnittstelle und die 2 Remotenetze an die Andere).
    Wozu? 10-15 parallele Terminalserver-Sessions machen kaum merklichen Traffic und mehr als 1 MBit/s ist aufgrund der schwachen WAN-Anbindung eh nicht drin.

    An der Internetanbindung sollte dringend etwas getan werden!

     

    Sollen sich die VPN-Tunnel per ACL beregeln lassen?
    Nein, da ich keine festen IP's für die Filialen bekomme (24h DSL-Rhythmus) soll die Kontaktaufnahme eig. über DynDNS erfolgen.
    Die Frage ist anders gemeint: Nämlich ob die Möglichkeit bestehen soll, den Traffic, der durch den Tunnel hereinkommt oder durch den Tunnel geht per Firewallregel zu reglementieren. Ich halte das für ein wichtiges Feature, welches bspw. Netgear m.W. nicht bietet. Selbst wenn man es nicht für die Durchsetzung von Securitypolicies benötigt (also keine Einschränkungen vornehmen will), ist es dennoch für die Fehlersuche sehr hilfreich (Logging auf den Regeln aktivieren).

     

     

    Also ich rate zur ZyWALL 2Plus. Kann deutlich mehr als Ihr braucht, ist dennoch sehr einfach zu konfigurieren und sehr preiswert. Nicht zuletzt gibt es im Netz deutschsprachige Konfigurationsanleitungen, Wissensdatenbanken und Foren, was den Einstieg sehr erleichtern dürfte.

     

     

    Gruß

    Steffen

  6. Netgear habe ich abgewählt, da die keinen "echten" VPN-Router haben mit Gigabit-Lan, was sicherlich bei der Anforderung nicht verkehrt wäre. Linksys fällt wegen the same reason raus

    Erkläre mir mal, wofür die Firewall mit Gigabit ans LAN angebunden werden muss!?

    Das macht nur Sinn, wenn man Subnetze im LAN zwecks Reglementierung über die Box routen will oder wenn die WAN-Anbindung mind. 1GB hat. Ich gehe doch mal schwer davon aus, dass zumindest letzteres nicht gegeben ist...

     

    Wenn es wirklich auf Performence ankommt, lohnt ein Blick auf Sonicwalls NSA-Serie.

    Bei knappem Budget - insbesondere wenn man für den Support nicht extra zur Kasse gebeten werden möchte - halte ich die ZyWALLs aus dem Hause ZyXEL für eine gute Option. Die 2Plus beispielsweise ist sehr leicht zu bedienen und dennoch für die meisten SMB-Umgebungen ausreichend leistungsfähig. Für komplexere Szenarien gibt es die Linux-basierten USGs. Da ist dann aber auch schon etwas mehr Know How bei der Konfiguration erforderlich. Und ganz frei von Kinderkrankheiten sind sie leider auch noch nicht.

     

    Definiere also bitte nochmal Deine Anforderungen:

    - Auf welchem Layer soll die Firewall arbeiten? Sind sog. UTM-Dienste gewünscht?

    - benötigt die Firewall mehrere beregelbare Zonen/Interfaces?

    - welcher Durchsatz ist gewünscht (Firewalldurchsatz und VPN-Durchsatz, ggf. UTM-Durchsatz)?

    - Sollen sich die VPN-Tunnel per ACL beregeln lassen?

    - gibt es besondere Anforderungen an die Möglichkeiten zur Adressübersetzung?

    - Policyrouting?

    - VLAN-Support?

    - Userinterface?

    - (zentrale) Verwaltbarkeit?

    - und und und...

     

    Nicht zuletzt: Was darf der Spaß kosten (Anschaffung, Support, Updates)?

     

    Gruß

    Steffen

  7. @pablovschby: Was Haliel da schreibt vergiss besser wieder.

    Das 2. Gateway ist in der Tat ein Redundanzmechanismus. Dieser greift allerdings nur unter ganz engen Voraussetzungen (z.B. nur für bestehende TCP-Verbindungen) und ist deshalb m.E. von keiner praktischen Bedeutung. Google mal nach "Dead Gateway Detection"! Auch die Boardsuche gibt einiges her...

    Wenn Du Redundanz für das Standardgateway benötigst, nimm HSRP, VRRP oder CARP.

     

    Gruß

    Steffen

  8. ZyXEL G4100v2 ist genau für solche Dinge gemacht...

     

    Wenn man dessen umfangreiche Funktionen, wie Captive Portal, Walled Garden etc. nicht benötigt, reicht natürlich auch eine SOHO-Firewall mit WLAN, welche die WLAN-Zone per Firewall beregeln kann. Z.B. eine ZyXEL ZyWALL 2WG.

     

    Was meinst Du mit 2 Ports? Benötigst Du wegen der Abdeckung 2 APs?

     

     

    Was für ein Router ist denn momentan vorhanden? Vielleicht hat der eine (echte) DMZ, in die man einfsach die Accesspoints stellen kann?

  9. ... Wenn ich jetzt einen "normalen" Router mit Loadbalancing benutze stehe mir ja für eine Verbindung nur max. 1Mbit zur Verfügung. Ok, wenn mehrere Anfragen gleichzeitig kommen wäre das nicht schlimm. Aber es soll halt möglich sein das Daten mit den vollen 3Mbit von einem Rechner verschickt werden.
    ok, darauf wollte ich hinaus. ;)

     

    Solltest Du letztendlich wirklich die Viprinet-Lösung aufsetzen, dann gib uns hier zu gegebener Zeit bitte einen kleinen Erfahrungsbericht!

     

    Gruß

    Steffen

  10. Ich habe das bei Viprinet so verstanden das ich bei uns diesen Router hinstelle und unsere DSL Leitungen dort anschliesse. Dann brauche ich natürlich noch eine Gegenstelle. Entweder stellen wir uns einen zweiten Router in ein Rechenzentrum oder mieten uns so eine Kiste von Viprinet in deren Rechenzentrum. So sollte das funktionieren.
    Ja das würde wohl funktionieren. Aber ich bezweifle, dass dies wirtschaftlich sinnvoll ist, denn den Traffic im Rechenzentrum bekommst Du auch nicht gratis.

    Selbst wenn es wirtschaftlicher als eine eigene "dicke" Leitung wäre, steht für mich dennoch der Mehrwert im Vergleich zu einer Loadbalancing-Lösung völlig außer Verhältnis. Ist Dir denn der technische und vorallem praktische Unterschied klar?

    Über wieviele Leitungen und über welche Bandbreiten sprechen wir überhaupt?

     

    Gruß

    s.k.

  11. Rein vom Durchsatz her würde sogar eine ZyWALL 2Plus ausreichen. Die kostet gerade mal ca. 130 EUR. Da tut ein Fehlgriff nicht weh. Konfigurationsbeispiele Zywall<>Checkpoint gibt es im Netz - scheint also zu funktionieren.

     

    Wieviele IP-Netze befinden sich denn hinter dem Checkpoint-Gateway? Muss nur eine Verbindung zur Zentrale hergestellt werden oder auch zu anderen Außenstellen? Wenn letzteres: vermascht oder "hub and spoke"?

     

    Gruß

    s.k.

  12. Hallo,

     

    Mit der Checkpoint UTM Appliance habe ich bisher schlechte Erfahrungen gemacht ( schlechte Performance, häufige Abstürze ).
    Welchen Durchsatz benötigst Du denn?

     

    Der Standort darf ausschließlich eine Verbindung zu unserer Firma aufbauen. Andere ein- und ausgehende Verbindungen müssen ausgeschlossen werden.
    Diese Anforderung sollte bereits jeder Billig-Firewallrouter erfüllen können.

    Problematischer sind die Hintertüren hinter der Firewall (ISDN-Karten in den Rechnern, WLAN, UTMS, Bluetooth usw.). Diesen (und andere) Kämpfe kann man am Gateway nicht gewinnen.

     

    Gruß

    s.k.

  13. Hallo Saruman,

     

    was möchstest Du denn genau erreichen? Geht es um Internet-Access oder VPN?

    Die Viprinet-Lösung teilt eine einzelne Session nur dann transparent auf mehrere WAN-Verbindungen auf, wenn sich auf der Gegenseite wiederum ein Viprinet-Router oder ein Viprinet-VPN-Client befindet. Geeignet ist das Ganze also nur für Site-to-Site oder Client-to-Site-VPNs.

    Für den Internet-Zugriff kannst Du eine echte Bündelung nur in Zusammenarbeit mit dem oder den Providern erreichen. Einseitig mit eigener Technik geht nur Lastverteilung. Letzteres bieten nahezu alle Anbieter. Da kannst Du aus dem Vollen schöpfen...

     

    Gruß

    s.k.

  14. Hallo matthe,

     

    Ich habe aber nur eine Fixe IP, jedoch in der Firewall kein NAT.
    Wenn Du an der Firewall keine Adressübersetzung machst, dann müssten doch alle Server öffentliche IP-Adressen haben und das ganze Problem würde gar nicht existieren.

    Mit "nur eine Fixe IP" meinst Du vermutlich, dass Du bisher nur eine (feste) _öffentliche_ IP-Adresse hattest. Deine Aussage bzgl. NAT scheint also nicht zu stimmen.

     

     

    Mit Hostheaderwerten funktioniert das schon, jedoch entweder oder. (Server1 oder Server2) Die Firewall hat zwar kein reines NAT, und ich kann SSL auf beide Server umleiten, die Firewall nimmt dann jedoch einfach den zuerst konfigurierten Weg.
    Wieder so eine Aussage, die die Vermutung nahe legt, dass Du weder die grundlegenden Konzepte noch die konkrete Funktionalität der USG wirklich verstanden hast.

    1) Was ist denn für Dich "reines NAT"?

    2) Ganz offenkundig hast Du auf der USG versuchsweise mehrere sich inhaltlich überschneidende sog. "virtuelle Server" angelegt. Mit vServern macht man auf der USG sog. Destination-NAT (und ggf. Porttranslation).

    Die USG macht an dieser Stelle aber keine Hostheader Inspection! Du kannst hier zwar zuvor definierte Objekte verwenden, die wie FQDNs aussehen, jedoch sind dies lediglich "Stellvertreter" für die objektorientierte Konfiguration.

    Der Umstand, dass die Firewall "einfach den zuerst konfigurierten Weg" nimmt, ist darin begründet, dass der zweite vServer nicht korrekt initialisiert werden kann, weil der zuvor angelegte vServer bereits das Socket belegt. Im Logfile der USG sollte eine entsprechende Fehlermeldung zu finden sein. Leider erfolgt keine Prüfung auf Konflikte beim Anlegen oder Modifizieren eines vServers.

     

    Gruß

    s.k.

  15. Hallo,

     

    @s.k.:

    wenn ich mich recht erinnere, landen authentifizierte user auf einem portal, wo dann die diversen applikationen veröffentlicht sind (in richtung cwi). somit kann ich viel granularer entscheiden, was wer sieht, ohne da extra firewallregeln erstellen zu müssen für die diversen pptp-user gruppen.

    Ja es gibt eine Portalseite, auf der man u.a. sog. Bookmarks anlegen kann. Diese kann der Admin vorgeben oder der User selbst anlegen, wenn er dazu berechtigt ist. Diese Bookmarks können auch auf Webserver verweisen. Dabei macht die SSL-Appliance URL-Rewriting (der User sieht immer die selbe URL, nämlich die vom Webportal). Naturgemäß funktioniert dies aber nur zuverlässig bei einfachen Webapplikationen. Je nachdem, wie (sauber) die Webapplikation programmiert ist, wird der Hostname/die URL aber auch an anderer Stelle übergeben. Dann läuft das gegen die Wand. Problematisch ist z.B. Javascript.

     

     

    generell habe ich folgendes nach aussen zu veröffentlichen:

    - owa

    - scm (ca antispam webinterface)

    - ein webinterface für unsere kunden (wird derzeit entwickelt)

    - für mich meine persöhnliche intranetseite

    ...

    da alles auf verschiedenen hosts läuft. so müsste ich alle unsere öffentlichen ip´s verwenden und die ports dann forwarden.

    Wie Lukas schon schrieb, bietet sich hierfür eine Webserververöffentlichung über den ISA-Server an.

    Die SSL-VPN 2000 bietet diesen Modus aber auch: das sog. "Application Offloading". Hier wird der jeweilige Webserver über eine/n eigene URL/Hostnamen angesprochen. Diese/r wird aber in die gleiche IP-Adresse aufgelöst. Die Appliance wertet die URL aus, lädt die passende Seite per Reverseproxy und stellt sie dem anfragenden Client dar.

     

     

    - im besten fall noch ein paar fileshares
    Geht per SSL-VPN entweder im Fulltunnel-Modus (Netextender) oder über das Portal per Java-Applet.

     

     

    - citrix webinterface
    Beachte, dass es meines Wissens nicht genügt, das Webinterface wie einen Webserver zu veröffentlichen, denn dieses dient nur der Darstellung (und ggf. Authentifizierung). Sobald die Terminalserverapplikation gestartet wird, läuft wieder eine normale ICA-Session. Auch hierfür sollte wieder ein VPN genutzt werden. Bei der Sonicwall SSL-VPN 2000 entweder der Fulltunnel-Modus oder das Java-Applet im Portal.

    Citrix bietet mit dem "Access Gateway" übrigens seine eigene spezialisierte SSL-VPN-Lösung an...

     

     

    ich hätte vor, die box einfach hinter die fw zu stellen, und dann 443 auf diese zu forwarden. oder in die dmz, das überleg ich mir dann noch.

    Auf jeden Fall in die DMZ, damit Du an der Firewall regeln kannst, was zwischen LAN und Appliance erlaubt ist. Auf diesen Traffic kann man dann auch UTM-Services (IDP, Antivirus etc.) anwenden.

     

     

    Gruß

    Steffen

×
×
  • Neu erstellen...