Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Neues Netzwerkdesign mit VLAN Routing und Subnetting

Frage Netzwerke Netzwerkgrundlagen

Mitglied: panguu

panguu (Level 2) - Jetzt verbinden

31.07.2014 um 13:56 Uhr, 11331 Aufrufe, 38 Kommentare

Hallo miteinander,

ich möchte bei dem neuen Netzwerkdesign nichts falsch machen und irgendwas Wichtiges übersehen, weswegen ich euch um Hilfestellung bitte. Aktuell sieht's bei uns so (katastrophal) aus:
Ist-Stand:
- Root Bridge ist ein Cisco Catalyst 3560G-24TS, der Layer3-Routing macht. An diesem sind einige andere Cisco-Netzwerkswitche (Uplinks) angeschlossen.
- Ein riesiges flaches Subnet (172.16.0.0/16) ohne VLAN (man beachte die riesige 16er Maske ~würg~)
- DHCP/DNS-Server (172.16.1.22/16) verteilt leases in der DHCP-range 172.16.200.1-254
- DMZ (10.0.0.0/24), Workstations (172.16.200.0/24), Server (172.16.100.0/24), usw...

Das Internet stellt ein Linksys WRT54GL (172.16.110.5/16) bereit, welches mit dem Kabelmodem verbunden ist. Hier ist jedoch per iptables eine rule definiert, die nur dem squid-Proxy (172.16.101.254/16) erlaubt, darüber in Internet zu gehen. Die Clients/Workstations verwenden also diesen Proxy (=172.16.101.254/16) in ihren Browsern, um im Internet surfen zu können.

Nachher soll es so aussehen:

- auf der Root Bridge und allen anderen Netzwerkswitches, die angeschlossen sind, sollen VLANs eingerichtet werden, und zwar wie folgt:

Alle Uplinks (=Verbindungen zu anderen Cisco-Netzwerkswitches) sollen 801.1q Trunkingprotocol verwenden, worüber die getaggten Pakete übertragen werden.

VLAN1 soll von Grund auf deaktiviert werden, so daß "undefinierte" Hosts keinen Zugriff irgendwohin haben. Das soll einfach eine Art Schutzmaßnahme sein, dass nicht versehentlich irgendwas vergessen wird, und Clients über das normalerweise default VLAN1 miteinander kommunizieren können (Layer2). Ich möchte also einem Host, Port, oder sonstigem Gerät direkt vorher sagen welchem VLAN er zugewiesen sein soll. Falls man das vergisst und einen Host einfach so ins Netzwerk hängt, soll der einfach keine physikalische Verbindung (auf L2-Ebene) erhalten, da er ja keinem VLAN zugeordnet wurde und VLAN1 nicht vorhanden ist. Geht das überhaupt so, würde das funktionieren?

Bereich / Funktion VLAN L2 Subnet L3
WLAN-Intra (kein Internet erlaubt, nur ServerX) VLAN 2 172.19.2.0/24
DMZ (Mailserver,Webserver,EDI,usw...) VLAN 10 172.19.10.0/24
Workstations (Windows-Clients/Arbeitsplätze) VLAN 20 172.19.20.0/24
WLAN-Gäste (nur Internet zum Surfen erlaubt) VLAN 30 172.19.30.0/24
Backup-Komponenten (Library,TapeDrives,BackupPC,...) VLAN 35 172.19.35.0/24
VoIP-Geräte alle Art (für Zukunft betrachtet) VLAN 40 172.19.40.0/24
Serverlandschaft (bare-metal + VMs) VLAN 100 172.19.100.0/24
Produktionsmaschinen (CNC,Fräs,Verpack,Labeldruck,...) VLAN 102 172.19.102.0/24
Drucker Büros (sowohl Tisch- als auch Standdrucker) VLAN 103 172.19.103.0/24
Testbereich1 VLAN 123 172.19.123.0/24
Testbereich2 VLAN 124 172.19.124.0/24
Testbereich3 VLAN 125 172.19.125.0/24
VPN-site1 per OpenVPN angebunden VLAN 131 172.19.131.0/24
VPN-Site2 per OpenVPN angebunden VLAN 132 172.19.132.0/24
Reserve1 VLAN 151 172.19.151.0/24
Reserve2 VLAN 152 172.19.152.0/24
Reserve3 VLAN 153 172.19.153.0/24
Reserve4 VLAN 154 172.19.154.0/24
Reserve5 VLAN 155 172.19.155.0/24
Admins only VLAN 200 172.19.200.0/24
Managementinterfaces (Bladecenter Module,USVs, Klimaanl.,... VLAN 253 172.19.253.0/24
Switches,Router VLAN 254 172.19.254.0/24
Klimaanl.,AccessPoints,BMC,Stempeluhren,...)


Die Idee und Ziele sind:

  • das Broadcasting durch die Horror-Maske (/16) eliminieren und durch die einzelnen VLANs die Bereiche trennen (auch zwecks Sicherheit)
  • auf der root bridge (=Cisco) soll jedem einzelnen VLAN welches oben gelistet ist, eine VLAN-IP zugeordnet werden. Das VLAN2 erhält die 172.19.254.2, VLAN100 die 172.19.254.100, VLAN250 die 172.19.254.250, usw...)
  • anschließend auf Layer3 wieder zusammenführen (auf der root bridge = Cisco Catalyst 3560G-24TS "ip routing" aktivieren). Alle in der Tabelle gezeigten L3-Subnets können nun untereinander kommunizieren.
  • Jetzt muss abgeriegelt werden, also konfiguriert werden, wer mit wem sprechen darf. Das plane ich mit den extendes ACLs zu tun. Dazu habe ich mir folgendes überlegt:
        • Die Admins aus dem VLAN200(172.19.200.0/24) sollen überall hin dürfen, für die ist alles erlaubt ohne Einschränkungen.
        • Alle Switches (inkl. dem root switch 172.19.254.254) müssen ja von jedem erreichbar sein, damit sie durch das Netzwerk geroutet werden können. Ich möchte aber den Telnet-Bereich für die Admin-/Konfiguration nur für Admins (=172.19.200.0/24) erlauben, sonst keinem. Dazu hat mir aqui bereits folgende Konfiguration gezeigt (mein Switch kann kein SSH, weil es dieses Image nicht hat, nur Telnet. Wird das trotzdem so funktionieren, hab einfach das ssh weggelassen?)

01.
line vty 0 4 
02.
access-class 23 in 
03.
privilege level 15 
04.
login local 
05.
transport input telnet 
06.
access-list 23 permit 172.19.200.0 0.0.0.255
        • Die WLAN-Gäste (=VLAN30, 172.19.30.0/24) sollen nur im Internet surfen können. Da hier auch smartphones verwendet werden, würde das über den Proxy nicht funktionieren. Viele Apps oder Programme auf Android,iPhone, usw... benötigen eine "richtige" Verbindung ins Internet (also auch pings zu www.google.de müssen positive Resultate liefern können). Über Proxy wäre das käse, weil an vielen WLAN-Geräten (smartphones,Tablets) kann man nicht explizit für eine bestimmte ESSID den Proxy jeweils getrennt ein-/ausschalten. Das heißt, wenn an einem smartphone der Proxy 1.2.3.4 eingetragen wird, dann ist das bezogen auf die Wireless-NIC im Gerät und nicht pro Verbindung. Wenn derjenige dann zuhause ist und sein priates Internet nutzen möchte, müsste er manuell jedesmal den zu verwendeten Proxy wieder deaktivieren. Und in der Firma jeweils wieder aktivieren. Deshalb wäre die bessere/elegantere Möglichkeit, dass die WLAN-Clients direkt ins Internet gelangen dürfen. Dann wird auch das WLAN-Symbol an den smartphones "blau" oder als "aktiv" gekennzeichnet, und man kann z.B. auch über AppStore oder GooglePlayStore Apps runterladen.
        Wie müßte ich das denn einrichten, eurer Meinung nach? Ich müßte wohl auch in der Konfiguration des WRT54GL (OpenWRT WhiteRussian) definieren, dass 172.19.30.0/24 rausdarf, oder? Muss ich auf dem WRT54GL auch VLAN konfigurieren?

              • die Drucker im VLAN103 (172.19.103.0/24) sollen für die Workstations/Clients aus VLAN20 (172.19.20.0/24) erreichbar sein, und für sonst niemanden.
              • die Server im VLAN100 (172.19.100.0/24) sollen eigentlich für die Workstations/Clients aus VLAN20 erreichbar sein, manche halt nicht, die möchte ich extra sperren lassen.

        ...und so weiter und so fort ...


        Ich würde gerne wissen, nach welchem Prinzip ich vorgehen sollte, vor allem was die ACLs betrifft. Ich lese schon seit mehreren Tagen diverse Cisco-Dokumente zu den ACLs und bisher denke ich, dass ich wohl "named extended ACLs" nutzen sollte, weil:

        a.) kann granuliert festlegen wer wohin darf (source+destination sind nutzbar, wogegen bei den standard ACLs nur source nutzbar wäre).
        b.) die ACL sollte ich in meinem geplanten Fall von "extended" so nah wie möglich an die Quelle gesetzt werden.

        Bitte korrigiert mich, falls ich falsch liegen sollte. Ich hab außerdem noch Verständnisprobleme mit "in" und "out", wann setze ich eine ACL mit Gültigkeit "in" oder "out" wenn ich sie einem interface zuordne?

        Beispiel: ich möchte den WLAN-Gästen explizit NUR das Internetsurfen erlauben. Nehmen wir an, sie würden über den Internetrouter Linksys WRT54GL (172.19.254.5) ins Internet direkt gelangen können. Ich hätte das z.B. so gemacht:

        01.
        ip access-list VLAN30onlyInternet 
        02.
          remark permits WiFi guests to use only the internet gateway 
        03.
          permit ip any host 172.19.254.5 
        04.
          remark blocks access to anything else 
        05.
          deny ip any any
        und diese ACL auf das Interface VLAN30 (hat die IP 172.19.254.30) zugeordnet mit:
        01.
        int vlan30 
        02.
        description Wireless-Guests 
        03.
        ip access-group VLAN30onlyInternet out
        Wäre das richtig oder wie müßte das dann entsprechend richtigerweise ausschauen?

        Andres Beispiel. Wie müßte ich die ACL richtigerweise konfigurieren und anwenden, wenn ich das VLAN35 (=für Backups zuständig) nur mit den Admins und der Serverlandschaft kommunizieren lassen möchte? So etwa?

        01.
        ip access-list VLAN35backupsOnly 
        02.
          remark allow to be accessed from Servers and Admins 
        03.
          permit ip 172.19.100.0 0.0.0.255 any 
        04.
          permit ip 172.19.200.0 0.0.0.255 any 
        05.
          remark denying access from anyone else 
        06.
          deny ip any any
        und diese ACL auf das Interface VLAN35 (hat die IP 172.19.254.35) zuordnen mit:
        01.
        int vlan35 
        02.
        description Backups only from Servers and Admins 
        03.
        ip access-group VLAN35backupsOnly in
        Ich freue mich auf Eure Meinungen, Ratschläge, Korrekturen, Hilfestellungen und bedanke mich herzlich im voraus.
38 Antworten
Mitglied: brammer
31.07.2014 um 14:34 Uhr
Hallo,

das VLAN konzept sieht im ersten Überblick ganz gut aus, Hauptsache es passt auf eure Firma.
Nur für das WLAN Gäste VLAN 30 würde ich ein komplett anderes IP Netz nehmen (z.B.: 192.168.237.0 /24 ) das ist auffälliger, und besser identifizierbar.

Das VLAN2 erhält die 172.19.254.2, VLAN100 die 172.19.254.100, VLAN250 die 172.19.254.250, usw...)

Das Würde ich auf keinen Fall machen!
Ich würde in jedem VLAN die ersten 2 oder 3 Adressen (oder die letzen) für die Netzwerkkomponenten nehmen.
Solange du /24 Netze nimmst würde dien Konzept passen, aber spätestens beim ersten /25 oder /26 könnte das schief gehen.
Das macht die Fehlersuche einfacher, wenn du ein <sh arp> macht weisst du driekt das die ersten 3 Adressen im Netz deine Switche sind...

brammer
Bitte warten ..
Mitglied: emeriks
31.07.2014 um 14:35 Uhr
Hi,
sieht erstmal "schön" aus, aber auch "verspielt". Warum z.B. die Workstations, Drucker und Server "mit Macht" durch die VLAN trennen? Damit schön viel Routing anfällt? Oder willst Du die Server in beide (mehrere) VLAN hängen?
Gleiches für Backup. Wenn das Backup der Server nicht unnötig über den Router gehen soll, dann solltest Du entweder den Backupserver ins gleiche VLAN wie die Server hängen oder die Server zusätzlich ins Backup-VLAN.

E.
Bitte warten ..
Mitglied: aqui
31.07.2014 um 15:57 Uhr
Das VLAN Konzept ist bei diesem 16 Bit Missdesign und alles flach in der Tat richtig und überfällig und sieht auch soweit gut aus. Kollege emeriks hat aber Recht das man ggf. ein, zwei VLANs zusammenfassen kann je nachdem wieviel Komponenten insgesamt in diesen Segmenten sind.
Server bzw. RZ solltest du aber schon immer abtrennen, da muss man schon widersprechen, denn oft sind dort Keepalives oder Hearbeats sei es als Broad- oder Multicasts im Einsatz die sonst gesamte Client- oder Druckernetz fluten. Auch in puncto Server Sicherheit macht das Sinn.
Ob man dann aber Tape Libraries oder andere Geräte auf denen diese Server direkt sichern abtrennt ist doch fraglich. Die solltest du lieber mit den Servern in einem Segment belassen.
Drucker kann man auch in Client VLANs integrieren...je nach finaler Anzahl and Endgeräten.
Auf den ersten Blick fehlt ein Management VLAN in dem alle Mangement IPs vereint sind um sie vor Client Zugriffen zu schützen aber vermutlich meinst du damit das VLAN 254 "Switches,Router" ?!

Thema WLAN hat Kollege brammer schon richtig angesprochen. Hier IP seitig trennen.
Das VLAN 2 und 100 Problem kannst du einfach mit einer neuen Subnetzmaske lösen ! Trenne das Netz mit einer 25 Bit Maske 255.255.255.128 dann hast du 2 IP Bereiche 172.19.254.1-.126 und 172.19.254.129-.254 für die beiden VLANs und das Problem sauber gelöst.
mein Switch kann kein SSH, weil es dieses Image nicht hat
Das kann bei einem Cat 3560 definitiv nicht sein ! SSH zur CLI Konsole gehört zum Basis Featureset. Für den SSH Zugang musst du einen Domain Namen eintragen, mit username admin password geheim einen Username und mit crypto key generate rsa einen Schlüssel generieren. Dann klappt auch der SSH Zugang auf dem 3560 problemlos !

Der Einwand mit dem Proxy ist so auch nicht ganz richtig, denn du kannst ja einen transparenten Proxy installieren. Der Catalyst kann z.B. mit dem wccp Kommando diesen Traffic automatisch an einen proxy redirecten ohne das User überhaupt irgendwas eintragen müssten.
Abgesehen davon können gute Proxys wie z.B. der Klassiker Squid auch transparent konfiguriert werden.
Aber auch ohne Proxy ist das NUR Surfen mit einer entsprechenden ACL am L3 Switch im Handumdrehen gelöst.
Mit einem Gäste_Hotspot hast du mit Voucher und Regeln auf der WLAN Seite ja auch noch weitergehende Optionen je nachdem wie du das Gastnetz customized.
Die Gäste Zugangsregeln definierst du nicht auf dem Gastrouter oder AP sondern immer am L3 Switch da du dort ja auch den gesamten L3 Traffic kontrollierst. Mit der o.a. Hotspot Lösung für Gäste würde man über die FW nch weitere Sicherheit reinbekommen wenn du sowas planst zu nutzen.
Drucker und Server Erreichbarkeit dann ganz einfach wie oben schon angesprochen über zentrale ACLs am Switch VLAN Interface.

Named extended ACLs ist der richtige Weg. Prinzipiell sind sie funktional völlig identisch zu "normalen" ACLs aber die haben immer eine doch etwas nichtssagende Nummer. Bei extended kannst du der ACL Namen vergeben und das ist dann für die Managebarkeit erheblich besser und einfacher.
Ist so wie IP Adressen die sich niemand merken kann, DNS Namen hingegen schon
Du liegst hier also genau richtig !
Was deine Frage zu in und out anbetrifft ist das kinderleicht. Das Statement "in" an der ACL bedeutet immer das das ausschliesslich für "inbound" Traffic gilt also Traffic der vom LAN Draht IN das Interface reinfliesst.
Analog kannst du dir dann denken was "out" dann bedeutet. Traffic der AUS dem Switch/Router auf den LAN Draht geht...ist ganz einfach.

Deine Bespiel Accesliste ist natürlich komplett falsch weil du hier mehrere massive Denkfehler machst.
Die Zieladresse im IP Paket wenn du von einem Gastclient zu z.B. www.administrator.de willst ist ja niemals der Router sondern die IP Adresse von administrator.de also 82.149.225.18 !!
Besser ist hier immer mit einer IN ACL zu arbeiten denn OUT hat den Nachteil das "böse" Pakete der Clients schon in deinen L3 Router "reinfliessen" und das will man möglichst immer vermeiten wenn fremde Endgeräte im Spiel sind.
Folglich müsste die ACL also richtig lauten:
ip access-list VLAN30onlyInternet
remark permits WiFi guests to use only the internet gateway
deny ip any 172.19.0.0 0.0.255.255
remark blocks access to anything else
permit ip any any

Diese ACL blockiert den Zugriff auf alle internen IP Netze mit einem 172.19er Prefix 172.19.0.0 /16 und erlaubt den ganzen (Internet) Rest.
Zusätzlich kannst du noch an den anderen VLAN Interfaces das Gastnetz mit 172.19.30.0 0.0.0.255 auf deny setzen.
Besser ist es hier mit der o.a. Firewall Hotsport Lösung das VLAN 30 zu bedienen.
Du trägst dann einfach kein VLAN Interface für das VLAN 30 auf dem Switch ein, damit ist das VLAN 30 dann komplett isoliert und kann so physisch schon niemals auf deine anderen internen VLANs kommen.
Dann steckst du hier dann das lokale LAN Interface der Hotsport Firewall rein und dessen WAN Interface im Internet/DMZ VLAN 10.
Das erleichtert dir die Konfiguration der ACLs und trennt unsichere Gäste viel einfacher vom internen L3 Prozess !

Deine Beispiel Backup ACL ist syntaktisch wieder richtig !

Auf alle Fälle bist du auf einem richtigen und guten Weg und das Konzept macht generell Sinn wenn man die wahrlich katastrophale aktuelle Situation betrachtet !
Bitte warten ..
Mitglied: panguu
31.07.2014, aktualisiert 12.08.2014
@brammer: danke für den Tip, den ich wärmstens ans Herz nehmen werde. Ich werde für die WLAN-Gäste ein eigenes Subnet nehmen, dass sich von unseren anderen unterscheidet. Das ist eine gute Idee. Und wegen den VLAN-Interfaces, oh Gott! Natürlich hast du Recht, ich hab mich da total vertan und verschrieben. Für die jeweiligen Interfaceverwende ich hinten die .254 im jeweiligen Subnet. Also hat das VLAN2 die 172.19.2.254, das VLAN100 die 172.19.100.254, das VLAN200 die 172.19.200.254, usw... Ich wollte sagen: die anderen jeweiligen Switche im gesamten Netzwerk erhalten jeweils eine einzige IP-Adresse, und zwar auf ihr VLAN254 im 172.19.254.0 /24 subnet. Das heißt der root switch hat unter anderem (neben all den anderen VLAN IPs) die 172.19.254.254, der switch "foo" erhält das VLAN254 interface mit IP 172.19.254.2, der switch "bar" erhält das VLAN254 interface mit IP 172.19.254.3, usw...

Wenn ich also irgendwo 172.19.254.* sehe, dann weiß ich das es sich um 'nen switch handelt. Und wenn ich hinten an einer IP-Adresse *.*.*.254 sehe, dann weiß ich sofort, dass es das jeweilige VLAN254 interface an einem Switch ist. So zumindest meine Überlegung, wenn das passt, dann hak ich das so ab.

@emeriks: nunja, ich wäre nicht abgeneigt davon, weniger VLANs zu verwenden. Daher frage ich ja um Vorschläge und Meinungen, die ihr mir ja bereits zur Geltung bringt und wofür ich dankbar bin. Wie würde es denn ausschauen, wenn ich (nur mal angenommen) 230 Workstations, 200 Drucker und 180 Server hätte ? In ein und demselben VLAN (z.B. VLAN555) könnte ich sie ja problemlos konfigurieren, das ist nicht das Problem. Aber ich bräuchte ja 610 IP-Adressen, wie würde man das dann sinnvoll auf L3 konfigurieren? Würde ich ja jeweils ein eigenes Subnet nehmen (wie ich ja auch bereits so in meinem Ursprungspost geplant hatte, also die Workstations z.B. in 172.19.20.0/24, die Server in 172.19.100.0/24, und die Drucker in 172.19.103.0/24) dann hab ich ja nix anderes erreicht, denn die Netze müssten auf L3-Ebene sowieso wieder miteinander verbunden werden müssen, oder nicht? Der Vorteil wäre, ich spar mir halt 2 VLANs dadurch, aber ein wirklicher Vorteil ist das doch gar nicht, oder? Wenn ich jedoch 3 VLANs verwenden würde, dann würden z.B. Broadcasts von Druckern nicht in die andere zwei VLANs überschlagen. Bitte korrigier mich falls ich falsch liegen sollte. Oder meintest du, dass wenn diese drei Bereiche in ein einzige VLAN gedrückt werden, ich eine andere subnet-Maske nutzen sollte z.B. 172.18.100.0 /22 (subnet mask: 255.255.252.0) und die 610 Hosts dann dort reinnehme (IP-Bereich 172.18.100.1 bis 172.18.103.254) ?

@aqui:
Server bzw. RZ solltest du aber schon immer abtrennen, da muss man schon widersprechen, denn oft sind dort Keepalives oder Hearbeats sei es als Broad- oder Multicasts im Einsatz die sonst gesamte Client- oder Druckernetz fluten. Auch in puncto Server Sicherheit macht das Sinn.

Also ich sehe das genauso, diese zwei Bereiche möchte ich auf jeden Fall getrennt voneinander haben (also in VLANs). Das Backup-VLAN mit dem Server-VLAN vereinen sehe ich als akzeptabel, da habt ihr Recht. Wie bereits ein paar Sätze weiter oben gefragt, mich würde interessieren inwieweit man diese einzelne Segmente in gemeinsame VLANs packen könnte, und damit auch die IP-Adresse da alle reinpassen.

Auf den ersten Blick fehlt ein Management VLAN in dem alle Mangement IPs vereint sind um sie vor Client Zugriffen zu schützen aber vermutlich meinst du damit das VLAN 254 "Switches,Router" ?!

Dafür hatte ich ja eigentlich das VLAN253 vorgesehen. Dort möchte ich BMC-Netzwerkkarten reinnehmen, Bladecenter-Module und dessen MGMT-Interfaces, unsere ganzen USVs, Klimaanlagensteuerung im Serverraum, Heizungscontroller, und solche Sachen. Ich hab für die Switche+Router ein extra VLAN254 ausgewählt gehabt in meinem Ursprungspost, warum? Weil wenn ich dieses VLAN253 so beschränke, dass nur die Admins (=VLAN200) darauf zugreifen können, so würde ich die Kommunikation für alle restlichen Hosts lahmlegen. Eine Workstation A könnte über einen Netzwerkswitch hinweg nicht den Server erreichen, wenn er nämlich über einen Netzwerkswitch seine Route sucht, denn der Switch würde ja für Workstations im VLAN253 nicht erreichbar sein. Das war eigentlich mein Gedanke, deswegen habe ich Switches+Router in ein extra VLAN gepackt (=VLAN254). Dort hatte ich dann vor, lediglich den Admin-Zugriff (also serial line 0 4) zu beschränken, damit nur Admins draufkommen per Telnet (bzw. SSH). Ist diese Idee falsch? Wie sollte ich das deiner Meinung nach bewerkstelligen?

Das VLAN 2 und 100 Problem kannst du einfach mit einer neuen Subnetzmaske lösen ! Trenne das Netz mit einer 25 Bit Maske 255.255.255.128 dann hast du 2 IP Bereiche 172.19.254.1-.126 und 172.19.254.129-.254 für die beiden VLANs und das Problem sauber gelöst.

Das habe ich jetzt nicht verstanden, sorry. Im VLAN2 (=WLAN-INTRA) werden Handscanner im Kommissionierbereich eingesetzt. Das sind so tragbare Minicomputer (Intermec cn70) mit Barcodescanner und WindowsMobile. Die loggen sich per WLAN an der ESSID "INTRA" an, und die müssen nur einen einzigen Server (172.19.100.199) erreichen können, sonst nix. Die brauchen kein DNS, kein Gateway, kein Internet ... nur dieser Server. Erklär mir bitte wie du das genau gemeint hast mit dieser subnetmask 255.255.255.128 da ich solche Masken bisher nie eingesetzt habe. Ich verstehe die subnet mask, aber ich verstehe nicht wieso du das VLAN254 (die 172.19.254.* Addressen) erwähnst wo meine Netzwerkswitche doch drinhängen ?? Worauf wolltest du mit diesem Satz heraus, bitte erklär mir das etwas genauer. Sorry fürs momentane Nicht-Verstehen

Das kann bei einem Cat 3560 definitiv nicht sein ! SSH zur CLI Konsole gehört zum Basis Featureset. Für den SSH Zugang musst du einen Domain Namen eintragen, mit username admin password geheim einen Username und mit crypto key generate rsa einen Schlüssel generieren. Dann klappt auch der SSH Zugang auf dem 3560 problemlos !

Oh ok, das wußte ich nicht. Ich hab da auch was verwechselt. Ich spiele in letzter Zeit mit einem C3550 in einer isolierten Testdomäne herum und im irc-Channel #cisco hatte ich nachgefragt wegen SSH-Zugang. Da hatten die mir erklärt, dass es auf mein image drauf ankommt. Ich kann mich jetzt nicht mehr genau erinnern, die meinten ob ich irgendeinen bestimmten Textstring in meinem image-Namen sehen würde (Keine Ahnung, war das irgendwas mit der Zahl '8' oder so?). Wie auch immer, ich hatte das auf jeden Fall nicht in dem Imagenamen, weswegen die meinten, dass der Switch somit kein SSH bieten kann. Auf dem C3560 (unser aktuell produktiver root switch) hab ich das noch nicht durchgelesen und auch das image nicht gecheckt gehabt. "show running-config" zeigt mir zumindest am Ende der Ausgabe an, dass "line con 0", "line vty 0 4" und "line vty 5 15" vorhanden wären. Was auch immer das genau bedeutet, oder ob man daraus überhaupt erkennen kann, ob SSH unterstützt wird oder nicht. Sein image-file lautet "flash:c3560-ipbase-mz.122-25.SEB1/c3560-ipbase-mz.122-25.SEB1.bin" Noch 'ne doofe Frage: Ist das überhaupt ein Catalyst??? Ich sag immer Catalyst dazu, weil mich das C3560 dazu verleitet. Aber kann es sein, dass das gar kein Catalyst, sondern einfach nur ein C3560 ? Nicht lachen, aber ich hab keinen Schimmer. Die genaue Modellbezeichnung lautet WS-C3560G-24TS, scheinnt 12MB RAM zu haben. SW-Version ist 12.2(25)SEB1. Aber gut, ich werde das im Hinterkopf behalten und wenn's soweit ist, die Kommandos checken und ggf. SSH aktivieren. Danke für die Erklärung.

Der Einwand mit dem Proxy ist so auch nicht ganz richtig, denn du kannst ja einen transparenten Proxy installieren. Der Catalyst kann z.B. mit dem wccp Kommando diesen Traffic automatisch an einen proxy redirecten ohne das User überhaupt irgendwas eintragen müssten.
Interessant. Ich hab nicht gewußt was ein transparenter Proxy ist und wie der arbeitet. Laut der Wikipedia-Erklärung Transparenter Proxy scheint es ja eigentlich genau DAS zu sein, wonach ich gesucht hatte und womit das Problem gelöst wäre. (Übrigens: auf dem C3560 habe ich nach dem Kommando "wccp" vergebens gesucht, das gibt's wohl nicht?). Seh ich das richtig, dass ich quasi in meiner squid.conf den Eintrag hier einfach um das Wort "transparent" erweitern müßte? http_port 3128 transparent. Dann muss ich noch die iptable hier verwenden, richtig? iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3128 Aber auf welchem Host??? Wenn ich diese rule auf dem squid Host ausführe, dann müssten die Clients ja die IP des squid-hosts als Gateway eingeben, das wiederum wäre ja blöd, weil die als default gateway eigentlich den 172.19.254.254 erhalten sollten. Wenn ich also auf meinem 172.19.254.254 das einrichten könnte, dass sämtliche Anfragen auf Port 80 an den Squid-Host (=172.19.100.101) weitergeschickt werden könnten, dann würde das ja passen, richtig?

Abgesehen davon können gute Proxys wie z.B. der Klassiker Squid auch transparent konfiguriert werden.
Ich möchte jetzt nicht die einzelne Squid-Konfiguration vorgelegt bekommen, danach werde ich sicherlich noch googeln. Aber kannst du mir das Grundprinzip erläutern, wie das funktionieren soll? Laut Wikipedia muss am Client KEIN Proxy eingetragen werden. Wie findet denn also der Client den Weg zum Proxy? Muss man im Client statt dem Gateway (172.19.254.254) die IP-Adresse vom SquidProxy eintragen (das wäre dann die 172.19.100.101)?

Mit einem Gäste_Hotspot hast du mit Voucher und Regeln auf der WLAN Seite ja auch noch weitergehende Optionen je nachdem wie du das Gastnetz customized. Die Gäste Zugangsregeln definierst du nicht auf dem Gastrouter oder AP sondern immer am L3 Switch da du dort ja auch den gesamten L3 Traffic kontrollierst.

Das wäre meine nächste Frage gewesen, ich hatte sie bewußt noch zurückgehalten, weil hier wieder mehr Details einfließen. Aber da du das ja bereits angesprochen hast ... Nunja, es sieht so aus: wir haben ca. 20 UbiQuiti Unifi AccessPoints im Einsatz mit der Software-Controller Version 3.1.9. Der software-controller kann auch das von dir angesprochene vouchet-basierte Hotspotzeugs liefern. Dazu kann man folgende Funktionen konfigurieren:

... jetzt muss ich mal nach der Möglichkeit suchen, Bilder hier einzufügen... irgendwie fehlt mir oben der Button, den ich erwarten würde.... meld mich gleich, werde gleich weiterschreiben...
EDIT:also vorab sorry, aber ich finde DEFINITIV keinen Link bei mir, wo ich Bilder hochladen könnte in meinem Beitrag. Die Hilfe-Seite habe ich natürlich bemüht, und auch eine Anleitung gefunden, die erklärt, wie man Bilder hochlädt. Bei mir sieht das jedoch ganz anders aus und von diesem Button weit und breit keine Spur daher poste ich jetzt mal die zwei Pics einfach so rein, damit ich den Beitrag fertig kriege...


c63200186ead0a32e2bbdb62fcbf662a - Klicke auf das Bild, um es zu vergrößern
d6bc324774a4e810df19cab78786107c - Klicke auf das Bild, um es zu vergrößern

Ich könnte hier also eintragen und konfigurieren, dass sämtliche WLAN-Clients, die sich unter der ESSID namens "FOOBAR-GUESTS" anmelden, automatisch dem VLAN 30 zugeordnet werden.

Die Gäste Zugangsregeln definierst du nicht auf dem Gastrouter oder AP sondern immer am L3 Switch da du dort ja auch den gesamten L3 Traffic kontrollierst.
Aber die oben gezeigten Settings behalte ich doch bei, oder nicht? Sonst gelangen die Gäste ja nicht ins VLAN30 wie gewünscht? Auf meinem root switch (der via L3 alle VLANs wieder zusammenverbindet) muss ich dann halt die besagte ACL definieren, so daß VLAN30 exklusiv ins Internet gelangen darf. Am besten halt durch diesen transparenten Proxy, aber dazu muss ich mich noch schlauer machen wie das funktionieren würde (siehe Fragen oben)

Mit der o.a. Hotspot Lösung für Gäste würde man über die FW nch weitere Sicherheit reinbekommen wenn du sowas planst zu nutzen.
Als Firewall setze ich IPFIRE ein, ich denke da kann man noch nach gusto weiter zudrehen, bzw. feinjustieren.

Drucker und Server Erreichbarkeit dann ganz einfach wie oben schon angesprochen über zentrale ACLs am Switch VLAN Interface.
Ich dachte mir, dass ich über den cisco Switch die Basics via ACL definieren, also grad solche Sachen, dass die WLAN_Gäste nur ins INternet dürfen sollen und sonst nirgendswo, usw... alle weiteren Feinjustierungen würde ich dann über die IPFIRE regeln können, so denke ich hast du das gemeint, oder?

Named extended ACLs ist der richtige Weg. Prinzipiell sind sie funktional völlig identisch zu "normalen" ACLs aber die haben immer eine doch etwas nichtssagende Nummer. Bei extended kannst du der ACL Namen vergeben und das ist dann für die Managebarkeit erheblich besser und einfacher.
Jup Mit dem Zusatzfeauture, dass man die ACEs nachträglich verarbeiten kann, ohne die gesamte ACL löschen zu müssen. Zumindest hab ich das noch so in Erinerung aus den letzten Tagen beim zig Seiten lesen.

Deine Bespiel Accesliste ist natürlich komplett falsch weil du hier mehrere massive Denkfehler machst. Die Zieladresse im IP Paket wenn du von einem Gastclient zu z.B. www.administrator.de willst ist ja niemals der Router sondern die IP Adresse von administrator.de also 82.149.225.18 !! Besser ist hier immer mit einer IN ACL zu arbeiten denn OUT hat den Nachteil das "böse" Pakete der Clients schon in deinen L3 Router "reinfliessen" und das will man möglichst immer vermeiten wenn fremde Endgeräte im Spiel sind.
Das Prinzip habe ich jetzt begriffen, danke.

Folglich müsste die ACL also richtig lauten:
01.
ip access-list VLAN30onlyInternet 
02.
remark permits WiFi guests to use only the internet gateway 
03.
deny ip any 172.19.0.0 0.0.255.255 
04.
remark blocks access to anything else 
05.
permit ip any any
Du sagst quasi Verbiete Pakete mit der Quelle=ALLE und die als Ziel=172.19.0.0/16 haben. Diese ACL wendest du dann anschließend als IN auf dem Interface VLAN30 an, also so?
01.
int vlan30 
02.
description Wireless-Guests 
03.
ip access-group VLAN30onlyInternet in
?

Zusätzlich kannst du noch an den anderen VLAN Interfaces das Gastnetz mit 172.19.30.0 0.0.0.255 auf deny setzen.
Macht das denn Sinn? Ich verstehe zwar den Hintergedanke, aber bei einem cisco-switch würde man ja keine Ausfälle erwarten oder Fehlfunktionen. Bringt mir also diese Aktion (außer den drastischen Mehraufwand, da ich in jedem anderen VLAN explizit VLAN30 blocke) wirklich Vorteile? Bitte mit Erklärung, damit ich das richtig verstehe.

Besser ist es hier mit der o.a. Firewall Hotsport Lösung das VLAN 30 zu bedienen.
HIer steig ich nicht richtig durch. Welche Firewall Hotspotlösung meinst du denn nun? Also meine Hotspot-Lösung hat keine Firewall, ich nutze eine extra Firewall in meinem Netzwerk.

Du trägst dann einfach kein VLAN Interface für das VLAN 30 auf dem Switch ein, damit ist das VLAN 30 dann komplett isoliert und kann so physisch schon niemals auf deine anderen internen VLANs kommen. Dann steckst du hier dann das lokale LAN Interface der Hotsport Firewall rein und dessen WAN Interface im Internet/DMZ VLAN 10. Das erleichtert dir die Konfiguration der ACLs und trennt unsichere Gäste viel einfacher vom internen L3 Prozess !
Ich glaub ich verstehe was du meinst, aber ich verstehe noch nicht um welche Hotspot-Lösung es sich handelt Ich hab nämlich kein extra Gerät (=Hotspot) mit Firewallfunktion, denn meine Hotspot-Funktionalität würde der Software-Controller (=Software, keine Hardware!) von Ubiquiti übernehmen. Bitte klär mich diesbezüglich auf.

EIN DICKES DANKESCHÖN
Bitte warten ..
Mitglied: brammer
01.08.2014 um 08:23 Uhr
Hallo,

Sein image-file lautet "flash:c3560-ipbase-mz.122-25.SEB1/c3560-ipbase-mz.122-25.SEB1.bin" Noch 'ne doofe Frage: Ist das überhaupt ein Catalyst???
Ich sag immer Catalyst dazu, weil mich das C3560 dazu verleitet. Aber kann es sein, dass das gar kein Catalyst, sondern einfach nur ein C3560 ?

Ja es ist ein Catalytst....
Cisco hat vor Jahren die Firma Catalyst übernommen und lange den Namen für die Switche beibehalten.

brammer
Bitte warten ..
Mitglied: emeriks
01.08.2014 um 08:43 Uhr
Zitat von panguu:
(nur mal angenommen) 230 Workstations, 200 Drucker und 180 Server hätte ? In ein und demselben VLAN (z.B. VLAN555)
könnte ich sie ja problemlos konfigurieren, das ist nicht das Problem. Aber ich bräuchte ja 610 IP-Adressen, wie
würde man das dann sinnvoll auf L3 konfigurieren?
Was hat das jetzt miteinander zu tun? Wenn Du ein Netz mit min. 610 Adressen brauchst, dann musst Du halt eine Maske wählen, die das hergibt. Also z.B. 22 Bit (255.255.252.0) = (1024-2) Adressen.

Übrigends bedeutet ein Netz mit kleiner Maske (=viele mögliche Adressen) nicht automatisch viel Broadcast. Das hängt ja immer von der Anzahl und Art der Geräte in diesem Netz ab. Du kannst ne 8-Bit-Maske nehmen, nur 10 Geräte drin haben und hast genausoviel Broadcast, wie mit einer 24-Bit-Maske bei 10 Geräten. Drucker z.B. werden m.E. kaum Broadcast verursachen, weil diese selbst ja nicht im Netz aktiv sind. Die warten nur auf Ansprache, z.B. Druckjob oder Abfrage des Status über SMNP. Eigene Aktivitäten, wie SMNP Traps oder SMTP Mails sind zielgerichtet. Im übrigen gilt das für alle Geräte, egal ob Server, Client oder "dummes" Gerät. Wenn ich dessen Kommunikation nicht sauber und schlank konfiguriere, dann verursacht es u.U. eben mehr Broadcast, als andere. Dieser ganze Client-Mist um irgendwelchen Geräte im Netzwerk automatisch zu finden, Geräte ohne DNS- und/oder WINS-Sever Eintrag und Verwendung usw.
Management Softwares z.B., die wild "durch Netz jagen", werden Dir in vielen kleinen Subnetzen fast genausoviel Lärm verursachen wie in wenigen großen Netzen, bei gleicher Geräteanzahl. Mal abgesehen vom totalen Nettzwerkscan.

Also ja, halte die Netze so klein wie möglich, aber in jedem Fall auch so groß wie nötig. Geräte, die permanent miteinander kommunizieren, oder viel Daten untereinander verschiffen, am selben Standort sind und sich im selben Sicherheitskontext befinden (rein intern / Zugriffe von Extern / Gastnetze / Administration) sollten unter dem Aspekt der möglichst schnellen und direkten Kommunikation möglichs im selben Netz sein.
Aber das wil und kann ich nicht total verallgemeinern. Hier muss man immer zwischen Geschwindigkeit und Sicherheit abwägen.

Nun mag man sagen, alles eine Frage der Leistungsfähigkeit des Routers. Ja, mag sein. Das hat sicher Auswirkung. Aber de facto bedeuted jeder unnötige Hop auch unnötigen Zeitverlust und Datenverkehr im Netz.

E.
Bitte warten ..
Mitglied: panguu
01.08.2014, aktualisiert um 09:35 Uhr
@emeriks: danke für diese Info, werde ich beherzigen.

@all:

"sh ru" meines root switches zeigt mir:

Model: WS-C3560G-24TS
SW-Version: 12.2(25)SEB1
SW-Image: C3560-IPBASE-M

Wenn ich die cisco-Seite nach diesem Model durchsuche, dann gibt es folgende Downloads. Macht es Sinn meinen Switch upzugraden? Mich verwirren all diese vielen Images und Bezeichnungen

http://abload.de/img/clipboard011bkjd.jpg

Es wird mir 12.2.55-SE9(ED) vorgeschlagen. Das müßte schonmal aktueller sein wie mein jetziges 12.2.(25)SEB1 nehme ich an. Aber was bedeutet denn SE9, ED, bzw. SEB1 bei meinem aktuellen image? Und was wenn ich die "latest" version = 15.0.2-SE6(ED) downloaden und installieren würde, geht das oder ist das inkompatibel?

EDIT: Ahja. Ich hab etwas weiter recherchiert. Und laut diesem Tool müßte mein derzeit eingesetztes Image demnach OHNE Crypto sein, denn der Dateiname des Images wäre exakt derselbe wie bei mir auch aktuell im Einsatz. Heißt das also, ohne Crypto doch kein SSH möglich?

http://abload.de/img/clipboard0296uii.jpg

Ich hab hier mal mein aktuelles image (=linke Seite) und das von Cisco-Download empfohlene image (=rechte Seite) als Vergleich darstellen lassen. Da gibt's halt doch viele Punkte, die sich unterscheiden. Die unique-Ausgabe zeigt quasi die Leistungen an, die das jeweilige Image beinhalten. Weiter unten stehen dann alle "gemeinsamen" Funktionen, die von beiden images geleistet werden.

http://abload.de/img/clipboard027br73.jpg
http://abload.de/img/clipboard034up02.jpg
Bitte warten ..
Mitglied: aqui
01.08.2014, aktualisiert um 09:53 Uhr
Die Version Release 12.2.55-SE9 (ED) ist richtig und die solltest du auch verwenden !
Du hast ein IP-Base Featureset auf dem Switch folglich ist also das Image:
IP BASE
c3560-ipbasek9-mz.122-55.SE9.bin

Das richtige für dich !
Die kannst du downloaden und dann ganz normal mit copy tftp flash... updaten. Da ist dann auch SSH enthalten
Bitte warten ..
Mitglied: panguu
01.08.2014, aktualisiert um 09:41 Uhr
Ah, du hast schon geantwortet, während ich meinen Beitrag editierte Also hab ich momentan kein Crypto und demnach kein SSH, richtig? Mit dem 12.2.55-SE9 (ED) hätte ich dann also crypto und kann SSH verwenden.

EDIT: Lese gerade. Wenn im image filename K9 auftaucht, dann heißt es dass es crypto unterstützt. Wenn nicht, dann eben wird kein crypto und ergo SSH geboten.

Werde ich mit diesem neueren image dann irgendwas vermissen? Was passiert eigentlich mit der Konfiguration bei solch einem update? Ich muss das halt schon planen, da es sich um einen produktiven root switch handelt. Wenn da irgendwas schief läuft hätte ich ein massives Problem und Zeitdruck. Kann ich notfalls zurück auf das alte image gehen, falls irgendwas schief läuft?
Bitte warten ..
Mitglied: aqui
01.08.2014 um 09:57 Uhr
Nein mit dem Image wirst du nichts vermissen im Gegenteil ! IP Base Feature ist IP Base Feature !! Warum meinst du müsstest du auf was verzichten ?!
Lies dir die Release Notes durch zu dem Image, dann weisst du was dort verbessert wurde und neu drin ist. Das ist ein "recommended Image" von Cisco...was dein altes nicht ist !

Was die VLAN Frage 2 und 100 anbetraf hattest du da ein IP Netz auf beide VLANs verteilt was generell nicht gut ist da du Schwierigkeiten hast die VLANs dann wieder zu koppeln. Generell sind die physisch getrennt.
Deshalb der Vorschlag das vorhandene IP Netz mit einer 25er Maske zu splitten.

Deine ACL Logik ist soweit OK und jetzt richtig. Du hast recht die 2te Anweisung zum Blocken des Gast VLANs an allen VLAN Interfaces ist nicht zwingend nötig. Kann man machen wenn man zum Gürtel auch noch den Hosenträger wünscht

Mit der Hotspot Lösung war diese hier gemeint:
http://www.administrator.de/wissen/wlan-oder-lan-gastnetz-einrichten-mi ...
bzw.
http://www.administrator.de/wissen/preiswerte-vpn-fähige-firewall- ...
Die hat erheblich mehr Möglichkeiten als die IPFire und hat eben auch die Captive Portal Funktion für Gäste. So hast du eben alles konzentriert in einem Gerät !
Bitte warten ..
Mitglied: brammer
01.08.2014 um 13:14 Uhr
Hallo,

Was passiert eigentlich mit der Konfiguration bei solch einem update? Ich muss das halt schon planen, da es sich um einen
produktiven root switch handelt

Da geht nichts schief....

Der Upload des neuen IOS dauert 15 min per tftp, beim neustart entpacjt er das aktuell Image und gut ist die Aktion ist alsp bequem in 30 min erledigt.
Ist halt eher was für ausserhalb der Kernzeit, da der Switch einmal gebootet werden muss.

hier die Syntax:

01.
Switch#archive download-sw /leave-old-sw /allow-feature-upgrade tftp://IP ADRESSE DES TFTP/c3560-ipbasek9-mz.122-55.SE9.tar
01.
boot system flash:/c3560-ipbasek9-mz.122-55.SE9/c3560-ipbasek9-mz.122-55.SE9.bin
brammer
Bitte warten ..
Mitglied: panguu
02.08.2014, aktualisiert um 01:04 Uhr
Hallo brammer,

danke für's feedback. Ich hatte leider früher Feierabend gemacht und vergessen, das zu posten. Ich hab das Image-Update an meinem Testswitch, dem C3550 durchgeführt. Dabei bin ich genauso vorgegangen, bis auf den Unterschied, dass ich eben /overwrite nehmen mußte, weil nicht genug Platz da war. Den "boot ..." Befehl mußte ich auch nicht machen, das hat der Upgradeprozess automatisch durchgeführt, ich hab mich mit "show boot" vergewissert. Nach einem reboot war das neue image aktiv, und meine ganzen Settings waren genauso wie vorher. Also alles bestens, war zufriedne mit der Aktion. Und das ging echt schnell.

@aqui: danke für den Hinweis. Ich werd leider die IPFire nicht abschaffen können und durch eine neue Lösung ersetzen können. Trotzdem werd ich mir das zu Gemüte führen und bei einem passenden Zeitpunkt in Erwägung ziehen und planen. Ich denke daher, momentan muss ich mit den Gegebenheiten klarkommen.

Was die VLAN Frage 2 und 100 anbetraf hattest du da ein IP Netz auf beide VLANs verteilt was generell nicht gut ist da du Schwierigkeiten hast die VLANs dann wieder zu koppeln. Generell sind die physisch getrennt. Deshalb der Vorschlag das vorhandene IP Netz mit einer 25er Maske zu splitten.

Ich versteh nicht worauf das jetz bezogen ist. Ich hab meinen eigenen Beitrag wieder durchgelesen, aber worum geht's denn überhaupt? Du sagst, ich hab VLAN2 und VLAN100 auf ein gemeinsames IP-Netz verteilt. Wo? Seh ich grad den Wald vor lauter Bäumen nicht? Zu VLAN2<-->VLAN100 Thematik hatte ich eigentlich in meiner Tabelle erwähnt, dass VLAN2 diese WLAN-INTRA Handscanner reinkommen sollen. Die wiederum sollen nur Kontakt zu einem einzigen Server aus VLAN100 haben. Also alle WLAN-Clients aus dem 192.168.2.0/24 Netzwerk dürfen lediglich den Server 192.168.100.199 erreichen dürfen und sonst gar nix. Daher war doch meine Idee, dies einfach durch eine extended ACL zu bewerkstelligen. Lieg ich damit komplett falsch? Wieso hast du mir hier vorgeschlagen ein IP-Netz zu splitten durch eine 25er Maske, ich versteh das nicht. Bitte erklär mir das genauer.

Ich würde gerne mal testweise anfangen ein VLAN in dem produktiv Netzwerk zu implementieren. Dazu würde ich gerne das WLAN-GUEST Netz aufbauen und hab hier und dort noch meine Hürden. Folgendes Szenario dazu:

WLAN-Clients (=smartphones, Tablets, Besucher, usw...) loggen sich auf das offene Netzwerk mit der ESSID "GUESTS" ein. Dazu müssen Sie einen Voucher-Einmalcode verwenden, den Sie von uns Admins ausgehändigt bekommen. Der gilt dann für 8h beispielsweise. Das ganze wird im software-Controller Ubiquiti geregelt (Ubiquiti UniFi UAP sind unsere AccessPoints). Dieses WLAN-Gastnetz hat die VLAN-ID 30 und läuft also unter VLAN30. Da weder der Ubiquiti-Softwarecontroller, noch die UAPs selbst DHCP-Leases verteilen können, brauche ich einen DHCP-Server für die WLAN-Gäste. Ich würde gerne meinen vorhandenen DHCP-Cluster nutzen, der auf zwei Debian-Hosts arbeitet und momentan Leases verteilt. Ich möchte diesen DHCP-Server um einen Poolbereich erweitern, und zwar für Leasevergabe im Bereich 192.168.30.10-250. Ich hatte mir überlegt auf dem Debian-Host einfach ein zusätzliches virtuelles Interface eth0.30 zu erstellen und diesem das VLAN30 zuzuordnen. So gesehen würde ich durch diesen Schritt eine Verbindung auf L2-Ebene zwischen den sozusagen authentisierten WLAN-Gästen und dem DHCP-Server erreichen, oder nicht? der WLAN-Gast sollte dann hoffentlich eine IP aus dem 192.168.30.10-250 Bereich erhalten. Allerdings ist mein DHCP-Server eine VM, die auf einem Blade (innerhalb eines Bladecenters H) werkelt. Müsste ich dazu die Network I/O Module entsprechend auch mit VLAN konfigurieren oder ist das nicht erforderlich, da ich ja lediglich dem virtuellen interface eth0.30 auf meinem Debian-Host (=DHCP-Server) das VLAN30 zuordne? Würde das genügen und ich kann mir Konfiguration auf Bladecenter-Ebene ersparen?
Bitte warten ..
Mitglied: aqui
02.08.2014, aktualisiert um 13:30 Uhr
Was die VLAN 2 und 100 Thematik anbetrifft hattest du selber geschrieben.. Zitat:
Das VLAN2 erhält die 172.19.254.2, VLAN100 die 172.19.254.100, VLAN250 die 172.19.254.250, usw...
OK, da stehen jetzt keine expliziten Subnetzmasken zu den IPs lies aber vermuten das du ein IP Netzwerk in 2 unterschiedlichen VLANs betreibst...mag aber auch ein Missverständnis sein ?!

Ich würde gerne mal testweise anfangen ein VLAN in dem produktiv Netzwerk zu implementieren.
Das ist generell kein Problem und du kannst das immer parallel zum Produktivbetrieb machen und schon mal alle deine VLANs einrichten und das Routing dazu. Ist das erledigt kannst du langsam VLAN für VLAN auf die neue Infrastruktur migrieren.
brauche ich einen DHCP-Server für die WLAN-Gäste. Ich würde gerne meinen vorhandenen DHCP-Cluster nutzen
Das wäre auch der technsich richtige Weg !
Allerdings ist es natürlich Blödsinn ein zusätzliches VLAN Interface auf die Server zu tunnelen. Kein Netzwerker würde sowas machen, denn damit schleifst du quasi das gastnetz auf deine Serverinfrastruktur. Das ist netzwerktechnischer Unsinn, da du so deine Security Policy mit dem Hotspot Gästenetz quasi konterkarierst !
Die Lösung ist viel einfacher und mit einem einzigen Kommando in 1 Minute erledigt....
Auf deinem VLAN Router, was ja vermutlich dein Cat 3560er Switch ist, konfigurierst du einen DHCP Relay sprich ein UDP Broadcast Forwarding. Das macht man mit dem IOS Kommando ip helper-address <ip_dhcp_server>
Der VLAN Router nimmt dann die DHCP Broadcasts aus dem Gast VLAN 30 und forwardet sie dediziert an deinen zentralen DHCP Server. Der hat das entsprechende Scope für VLAN 30 und antwortet mit einer entsprechenden DHCP IP für VLAN 30 bzw. die Clients dort ! Et voila... So einfach ist das... Und keinerlei Frikelei mit VLANs am VM Host
http://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/h ...
und
http://www.freeccnaworkbook.com/workbooks/ccna/configuring-an-ip-dhcp-h ...
Bitte warten ..
Mitglied: panguu
02.08.2014 um 14:21 Uhr
Hi aqui,

das mit dem VLAN2=172.19.254.2, VLAN100=172.19.254.100, .... war mein Ursprungspost und damit wollte ich eigentlich sagne, dass meine VLAN-Interfaces am C3560 diese IPs erhalten. Das war aber falsch geschrieben, wie brammer schon richtigerweise kritisiert hat. Die VLAN-interfaces am C3560 sollen erhalten:

VLAN2 interface kriegt die 172.19.2.254
VLAN30 interface kriegt die 172.19.30.254
VLAN100 interface kriegt die 172.19.100.254

..usw..

das von dir angesprochene Szenario mit dem IP Helper (das ist quasi ein DHCP-relay, und heißt auf Cisco-Ebene einfach IP Helper nehme ich an?) wäre natürlich klasse! dann kann ich mir das VLAN-Gefummle auf Serverseite echt sparen. Enthält solch ein DHCP-request Paket, welches von einem DHCP-client versendet wird, auch alle notwendigen Informationen, und werde diese auch exakt bis zu meinem DHCP-Server auf die Serverlandschaft durchgeschleift, so daß der DHCP-Server die Info entnimmt, dass Client XYZ eine DHCP-Lease angefordert hat, und dass es von VLAN30 kommt? Das wäre echt gut wenn das so easy wäre und würde echt viel Arbeit ersparen. Ich wende mich daher mal fürs Erste an dieses Cisco DHCP Dokument hier

Grob gesagt: müßte ich quasi auf meinem c3560 mit "conf t" und dann "int vlan30" den Befehl "ip helper-address 172.16.1.22" absetzen? Die IP 172.16.1.22/16 ist mein derzeitiger DHCP-Server (der master), den ich noch eben mit dem zusätzlichen Scope erweitern müsste. Kann ich denn irgendwie auch meinen slave (=172.16.1.23/16) hier ins Spiel mit reinbringen? Denn wenn ja der master ausfallen sollte, dann würde der c3560 versuchen die dhcp-request an 172.16.1.22 vergeblich weiterzuleiten was ja nicht klappen kann. Gibt's also eine Art Befehl auf dem cisco, dass ich auch ein Backup-Relay angeben könnte (in dem Fall 172.16.1.23/16) ?
Bitte warten ..
Mitglied: aqui
02.08.2014, aktualisiert um 16:35 Uhr
Das war aber falsch geschrieben
OK, dann ist alles gut
heißt auf Cisco-Ebene einfach IP Helper nehme ich an?
Ja, genau richtig, siehe zitierte URLs oben ! (lesen !)
Enthält solch ein DHCP-request Paket, welches von einem DHCP-client versendet wird, auch alle notwendigen Informationen, und werde diese auch exakt bis zu meinem DHCP-Server auf die Serverlandschaft durchgeschleift,
Ja, sicher !
OK, weil du es bist hier nochmal schnell die grobe Funktionsweise die du aber dediziert auch nachlesen kannst !!
  • Client schickt DHCP Broadcast per UDP raus in seinem VLAN Segment
  • Switch L3 Interface mit DHCP Relay Agent (Helper Adresse) empfängt diesen Broadcast, ersetzt die Absender IP mit seiner eigenen VLAN IP Adresse und forwardet das an an den in der Helper Adresse angegebenen DHCP Server.
  • Der DHCP Server "sieht" den Request mit der ensprechenden Absender IP, "weiss" dann für welchen Scope das ist und schickt einen Reply mit entsprechender Lease zurück.
  • Der landet dann wieder am Switch VLAN Interface das das Paket dann an den Client zurücksendet
  • Client hat DHCP Adresse
Fertisch !
müßte ich quasi auf meinem c3560 mit "conf t" und dann "int vlan30" den Befehl "ip helper-address 172.16.1.22" absetzen?
Yepp, genau richtig und nicht nur quasi sondern ganz konkret !!
Kann ich denn irgendwie auch meinen slave (=172.16.1.23/16) hier ins Spiel mit reinbringen?
Ja, natürlich !
Du kannst mehrere DHCP Helper definieren auf dem L3 Interface und zu jedem wird dieser Broadcast geforwardet und bei DHCP gilt: "First come, first serve !"

Bitte lies dir die IOS Command Reference durch dort sind alle diese Kommando explizit beschrieben. Das erspart das Nachfragen hier
Bitte warten ..
Mitglied: panguu
02.08.2014, aktualisiert 03.08.2014
Danke dir. Hört sich gut an... natürlich werd ich mich da weiter durchlesen.

Allerdings frage ich mich gerade, wie es der WLAN-GAST über das VLAN30 bis ins Internet dann schafft. Bis zu diesem Punkt hätte nun der WLAN-Gast eine Lease erhalten im DHCP-Bereich 172.19.30.10-250 /24. Mein Internetrouter (=Linksys WRT54GL mit OpenWRT, derzeit im produktiven Netz mit der IP 172.16.110.5/16) ist für das Internet zum Surfen verantwortlich. Die Workstations gehen nicht direkt über diesen ins Internet, sondern haben den 172.16.101.254/16 (=mein squid) als Proxy eingetragen und surfen quasi über den squid hindurch ins Internet. Nur der squid darf über 172.16.110.5 /16 ins Internet raus. Als default Gateway haben meine derzeitigen Workstations die IP-adresse des c3560 eingetragen. Der wiederum hat keine default route (0.0.0.0), sondern nur seine statischen routes, da zeigt aber keine zum Linksys WRT54GL (172.16.110.5/16).

Den produktiven Squid auf 172.16.101.254/16 kann ich ja schlecht auf "transparent" umbiegen, denn dann würden all meine aktuellen Workstations nicht mehr ins Internet gelangen, weil die haben ja überall diesen squid als Proxy in den Einstellungen eingetragen. Leider hab ich (noch) keine Möglichkeit über eine GPO das für alle Workstations gezielt abzuschalten (hab noch kein AD). Ich bin daher vorsichtig, an dem derzeitigen squid rumzudrehen. Stattdessen bin ich in diesem Zuge aber bereit einen neuen Host zu installieren mit einem neuen Squid. Der alte ist vom Vorbesitzer und sowas von verbogen und mit einem uralt Versionsstand. Ich möcht da nicht viel rumdrehen, ich wollt eh einen vollständig neuen Squid aufsetzen. Dann könnte ich ja parallel einfach 'nen neuen squid installieren und dem gleich VLAN100 (=serverLandschaft) und die IP 172.19.100.101 /24 verpassen. In dessen Konfiguration müsste ich dann eintragen, dass als Internetgateway mein OpenWRT Router genutzt werden soll. Der hat aber momentan nur die 172.16.110.5/16. Muss ich dem OpenWRT dann also noch zusätzlich das VLAN30 beibringen und eine 172.19.30.101 /24 verpassen damit das klappt?

Dieser neue zukünftige squid wird eine VM wird auf dem Blade innerhalb des Bladecenters werden. Müßte ich direkt am I/O-Ethernet-Modul des Bladecenters (das sind Nortel Layer2-3 GbE Switch Module(Copper), AlteonOS) ebenfalls ein VLAN30 definieren? Diese Switche haben Interfaces mit der Bezeichnung INT1 bis INT14, MGT1 und MGT2, und EXT1 bis EXT6. Denn wenn ich das nicht mache, und auf dieser Debian-VM einfach das dpkg-Paket "vlan" installiere und mein eth0 interface mit einem VLAN-interface namens "eth0.30" ausstatte, würde das doch nicht einfach klappen? Denn das ist ja nirgends ein 802.1q trunk aufgebaut, der alle VLAN-Pakete einschleusen würde.

Wie sähe hier die richtige Vorgehensweise aus?
Bitte warten ..
Mitglied: aqui
02.08.2014 um 18:53 Uhr
Der wiederum hat @@++keine@@ default route (0.0.0.0), sondern nur seine statischen routes, da zeigt aber keine zum Linksys WRT54GL (172.16.110.5/16).
(Da fehlt ein drittes "+" ! )
Das ist ja auch erstmal richtig so wenn du mit einem zentralen Proxy arbeitest !
Nur..... wozu hat der dann noch "seine statischen Routen" ???
Für die VLANs die direkt an ihm angeschlossen sind braucht er logischerweise keine statischen Routen !
Um das Problem für die Gäste zu lösen musst du die dann auch mit über den Proxy abfackeln und den entsprechend customizen.
Geht oder kannst du das nicht musst du nur mit dem VLAN 30 den Proxy bypassen. Entweder mit einem kleinen weiteren NAT Router was aber ungünstig ist. Besser du erlaubst dann nur das VLAN 30 in der Firewall ohne Zwangsproxy redirect.
Besser wäre natürlich den Proxy für alle bindend zu machen was du ja in den Squid Regeln auch so einstellen sehr einfach kannst.
Das musst du im Squid also anpassen. Du kannst beim Cisco mit dem wccp Kommando allen TCP 80 Traffic des VLAN 30 auf den Squid zwangredirecten !
Das wäre das eleganteste es ist aber fraglich ob dein IP Base Image im Switch WCCP supportet ??
Musst du mal im Handbuch nachlesen.
http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/g ...

Ein VLAN 30 am Squid musst du logischerweise nicht konfigurieren !
Dein Internet Router hängt ja nach der Änderung in einem separaten VLAN und sollte niemals in irgendwelchen Produktiv VLANs mit angeschlossen sein !
Bitte warten ..
Mitglied: panguu
03.08.2014 um 00:39 Uhr
Nur..... wozu hat der dann noch "seine statischen Routen" ???
Für paar VPN-Strecken, hat mit dieser Thematik nix zu tun, ist was gesondertes.

Es geht ja grad darum, dass ich diese VLAN30 Thematik in mein produktives Netz miteinbaue, parallel dazu. An der bestehenden Infrastruktur (dem popeligen 16er-Masken-Netz) kann ich auf die Schnelle nichts ändern. Ich möchte jetzt erstmal (auch zum Ausprobieren der VLAN-Thematik) die WLAN-GAST Funktion miteinbauen, parallel zum aktuellen Stand.

Ich hab zwar noch 'n altes images auf dem produktiven c3560g-24ts = 12.2(25)SEB1 laufen, aber selbst wenn ich das aktuell empfohlene 12.2(55)SE9 ED nehmen würde, dann kann es laut Dem Cisco Software Feauture Comparison Tool kein WCCP, zumindest finde ich keine Angaben über WCCP oder WebCache Services in der feauture list.

Um das Problem für die Gäste zu lösen musst du die dann auch mit über den Proxy abfackeln und den entsprechend customizen.

Ein VLAN 30 am Squid musst du logischerweise nicht konfigurieren ! Dein Internet Router hängt ja nach der Änderung in einem separaten VLAN und sollte niemals in irgendwelchen Produktiv VLANs mit angeschlossen sein !

Du meinst also, den Verkehr der VLAN30 WLAN-Gäste auch über meinen aktuell produktiven squid abzuwickeln (=172.16.101.254/16) ? Dann müsste ich aber den WLAN-Gästen den Proxy miteintragen, denn mein aktueller Squid ist ja nicht transparent konfiguriert. Und transparent konfigurieren will ich ja nicht, weil dann all meine anderen "normalen" Workstations im produktiven Firmennetz nicht mehr im Internet surfen könnten, denn die haben bei sich ja im Browser überall den Proxy eingetragen (=172.16.101.254/16). Daher war ja meine Überlegung einen zweiten Squid (ein neuer Proxy) als "transparent" zu installieren, der in Zukunft auch für meine derzeitigen workstations gelten soll, wenn ich später das gesamte Netz auf VLANs umgestellt habe. Wäre das verkehrt, hab ich hier 'nen Denkfehler? Ich möchte ja momentan erstmal "parallel" aufbauen und den aktuellen Stand nicht verändern müssen.

Geht oder kannst du das nicht musst du nur mit dem VLAN 30 den Proxy bypassen. Entweder mit einem kleinen weiteren NAT Router was aber ungünstig ist.
Bypassen wohin? Wenn ich keinen Proxy für die WLAN-Gäste verwende, dann müssten ja die WLAN-Gäste direkt über meinen Internetrouter ins Internet gelangen können (was ja auch nicht so dolle ist, aber zu verschmerzen wäre, zumindest für den Zeitabschnitt, bis ich alles komplett umgestellt habe). Den WLAN-Gästen auf VLAN30 könnte ich ja dann durch die DHCP-Optionen als default gw meinen LinksysWRT54GL Internetrouter geben. Der aber hat momentan nur die 172.16.110.5/16. Das würde nicht funktionieren, denn diese IP kann ein WLAN-Gast auf VLAN30 mit 'ner IP 172.19.30.10-250 nicht erreichen. Daher war meine Frage, ob ich am OpenWRT Internetrouter ein extra Interface einrichten könnten, das eben VLAN30 spricht, mit der IP z.B. 172.19.30.5/24. Und diese IP 172.19.30.5 übergebe ich meinen WLAN-Gästen als default gw. Würde das gehen? Falls ja, ist es kompliziert auf dem OpenWRT ein solches zusätzliches Interface einzufügen? Ich frage deshalb, weil ja bei dem LinksysWRT54GL (OpenWRT) die 6 Ports intern irgendwie verschaltet sind und eine bridge genutzt wird.

Besser du erlaubst dann nur das VLAN 30 in der Firewall ohne Zwangsproxy redirect.
sorry, muss ich passen, hab ich nicht verstanden. Oder meintest du damit, was ich im letzten Absatz meinte? Also dass die WLAN-Gäste direkt über den Internetrouter OpenWRT ins Internet gelangen?

==> EDIT: Das IPSERVICES image von 12.2(55)SE9 ED könnte WCCP v2, das könnte also was werden. Wobei ich noch nicht sicher bin, welcher Weg der "richtige" wäre.
Bitte warten ..
Mitglied: aqui
03.08.2014, aktualisiert um 14:28 Uhr
WCCP ist die einfachste Option, denn damit kannst du den Traffic "capturen" und zwangsweise über den Proxy schicken.
Du hast aber sonst recht und es ist natürlich kein Denkfehler ! Wenn du den Proxy nicht transparent setzen kannst müssten die Gäste eine entsprechende Konfig hahebn was natürlich nicht praktikabel ist.
Du musst das VLAN 30 dann bypassen.
Normal hast du ja deinen Internet Router und den Proxy in einem separaten "Internet" VLAN Segment. Hier arbeitest du nun mit einer simplen ACL am Catalyst das das Routing direkt zur IP des Internet Routers verbietet. Einzige Ausnahme hier das Gast VLAN, was direkt rausdarf. Hier kannst du die ACL noch etwas anpassen, das du den Gästen nur die klassischne Ports wie Surfen, Mail erlaubst. Damit kannst du den Gasttraffic dann halbwegs sicher kontrollieren.
So hast du die Problematik erstmal elegnat umschifft, denn deine anderen Segmente sind so gezwungen immer den Proxy zu nehmen nur das Gast VLAN kann dann direkt auf den Internet Router.
Damit kann man ja interimsmässig erstmal gut mit leben und du kannst dir ganz in Ruhe ein neues Proxy Konzept überlegen und es dann auch so unterbrechungsfrei ersetzen !
Bitte warten ..
Mitglied: panguu
03.08.2014 um 20:53 Uhr
Klingt einleuchtend das Ganze, ja. Wobei eine Frage noch ungeklärt blieb: muss ich auf dem OpenWRT Router nicht auch ein VLAN30 mit 'nem VLAN30 interface und 'ner IP einrichten (z.B. 172.19.30.5/24), und diese IP dann meinen WLAN-Gästen (per DHCP-options) als default gateway übermitteln? Soweit ich HIER gelesen habe, gibt's defaultmäßig das VLAN0 und VLAN1 auf dem OpenWRT WhiteRussian (=ältere OpenWRT Version).

eth0 ist gebridget mit
  • VLAN0 ist den externen Ports 1-4 zugewiesen (intern heißen die port0-3)
  • VLAN1 ist dem externen Port WAN zugewiesen

WiFi Interface ist eth1 zugewiesen

der interne Port 5 (CPU) ist ein Trunkport mit 802.1q worüber alle VLAN-IDs getragen werden.
siehe auch ==> hier die Skizze

Demnach dachte ich mir, dass ich einfach VLAN30 auf diesem OpenWRT Router einrichte, indem ich das VLAN30 hinzufüge mit den zwei NVRAM Variablen:

nvram set vlan30ports="5"
nvram set vlan30hwname=et0

Müsste dann nur noch schauen, wie ich gnaz einfach diesem VLAN30 dann auch eine IP-adresse zuweise (=172.19.30.5/24).

Oder brauch ich das alles gar nicht und ich übergebe den WLAN-Gästen, die eine Lease aus dem Bereich 172.19.30.10-250 erhalten werden, einfach die IP meines c3560 switch/routers (=172.19.30.254/24) als default gw, der dann wiederum mittels wwcp die Anfragen der WLAN-Gästen auf port 21,80,443 an die 172.16.110.5/16 weiterschickt? (wwcp sollte dann nur für VLAN30 aktiv sein auf dem c3560 switch, ich hoffe das geht?)
Bitte warten ..
Mitglied: aqui
04.08.2014, aktualisiert um 11:00 Uhr
muss ich auf dem OpenWRT Router nicht auch ein VLAN30 mit 'nem VLAN30 interface und 'ner IP einrichten (z.B. 172.19.30.5/24),
Nein, wozu denn ??
Wäre ja Unsinn, denn zentral routen tut doch dein Catalyst Switch und der bekommt eine Default Route auf den WRT ins Internet der im WAN VLAN hängt wo auch der Proxy ist.
Besser ist es aber dem Gast VLAN kein L3 VLAN IP Interface auf dem Catalyst zu konfigurieren, denn damit isolierst du das VLAN 30 routingtechnsich vollständig und so minimierst du die Gefahr durch ACL Fehler mit einmal Gäste in deiner internen LAN Struktur zu haben.
Das Gast VLAN hängt man dann mit einer Captive Portal Option wie du es ja schon mit dem Ubiquity hast oder ein CP wie der oben zitierten pfSense z.B. direkt ins WAN VLAN ohne Routing über den Catalyst. Das ist dann wasserdicht.
Das muss man nicht machen. Es geht auch via Cat Routing und dann mit den entsprechenden ACLs dort.
eth0 ist gebridget mit VLAN0
Das ist technischer Unsinn, denn ein VLAN mit der ID 0 gibt es technisch nicht ! Das ist das defalt VLAN 1 untagged.
Das ganze VLAN Gefrickel am OpenWRT ist in deinem neuen design so oder so völlig überflüssig und kannst du getrost ignorieren !!
Der OpenWRT Internet Router hängt untagged am Catalyst im DMZ oder Internet WAN VLAN Segment und macht kein Tagging. Wozu auch ??
Demnach dachte ich mir, dass ich einfach VLAN30 auf diesem OpenWRT Router einrichte
Das wäre dann die einzige Ausnahme und kann man so machen um das VLAN 30 (Gäste) vom Catalyst zu isolieren wie oben beschrieben.
Da du final aber so oder so auf ein zentrales Proxy Konzept aus bist wäre es dann wieder hinfällig wenn du das so einrichtest.
Besser ist das du belässt den Router wie er ist und bypasst das VLAN 30 mit dem Ubiquity CP. Das leistet das doch auch ?!
übergebe den WLAN-Gästen, einfach die IP meines c3560 switch/routers (=172.19.30.254/24) als default gw
Ja klar, das ist ja der Weg und musst du auch machen wenn du die WLAN Clients DHCP mäßig mit über deinen zentralen DHCP Server mit versorgen willst. Das erzwingt ja dann das VLAN 30 Interface mit der Helper Adresse auf dem Catalyst !
Nur wenn du das VLAN 30 isolieren willst mit dem Ubiquity CP oder einer anderen FW Lösung geht das nicht mehr ! Klar, denn dann ost das VLAN 30 vom zentralen Netz isoliert und kann nur noch direkt raus ins Internet. Folglich muss dann auch das CP Device oder eine separate FW dann die IPs vergeben.
Die Lösung mit dem Catalyst ist da natürlich eleganter, da du alles zentralisiert konfigurieren und pflegen kannst.
Bedingt aber auch das du immer ein wachsames Auge auf die Gast VLAN Accessliste haben musst.
Der Catalyst erlaubt dir aber ein ACL Logging mit dem "log" Parameter hinter der Gast ACL.
Mit einem kleinen Web basiertem Logging Server wie z.B. diesem_hier kannst du das und auch alle anderen Syslog Messages der Netzkomponenten immer zentral im Auge behalten.
Bitte warten ..
Mitglied: panguu
04.08.2014 um 17:59 Uhr
==> EDIT: Das IPSERVICES image von 12.2(55)SE9 ED könnte WCCP v2, das könnte also was werden. Wobei ich noch nicht sicher bin, welcher Weg der "richtige" wäre.

Mist!!! Ich kann IPSERVICES nicht downloaden, dafür wird ein Supportvertrag mit Cisco vorausgesetzt und jetzt rate mal: den haben wir natürlich nicht *grrr*. Ich kann das normale IPBASE Image vom 12.2(55) SE9 ED downloaden, dann kann ich aber kein WCCP einsetzen hmpf

Normal hast du ja deinen Internet Router und den Proxy in einem separaten "Internet" VLAN Segment. Hier arbeitest du nun mit einer simplen ACL am Catalyst das das Routing direkt zur IP des Internet Routers verbietet. Einzige Ausnahme hier das Gast VLAN, was direkt rausdarf. Hier kannst du die ACL noch etwas anpassen, das du den Gästen nur die klassischne Ports wie Surfen, Mail erlaubst. Damit kannst du den Gasttraffic dann halbwegs sicher kontrollieren. So hast du die Problematik erstmal elegnat umschifft, denn deine anderen Segmente sind so gezwungen immer den Proxy zu nehmen nur das Gast VLAN kann dann direkt auf den Internet Router.

Wenn ich das richtig verstanden habe: ich setze eine statische Route auf meinem Catalyst für 0.0.0.0 mit Ziel 172.16.110.5/16 (mein OpenWRT Internetrouter). Dann erstell ich folgende ACL, damit NUR VLAN30 direkt auf den Internetrouter 172.16.110.5/16 kommen darf.

01.
ip access-list extended onlyVLAN30toInternet  
02.
  remark permits only WiFi guests 
03.
  permit ip 172.19.30.0 0.0.0.255 any 
04.
  remark blocks any other hosts  
05.
  deny ip any any
und wie folgt zuordnen:
01.
int vlan16 
02.
  description Permit only VLAN30 members (WiFi-Guests) to access Internet router 
03.
  ip access-group onlyVLAN30toInternet out
In dem Beispiel bin ich von einem imaginären VLAN16 ausgegangen, welches momentan noch gar nicht auf meinem catalyst vorhanden ist. Denn der Catalyst hat momentan die IP 172.16.254.1 /16 aus der Horror-16er-Maske, und der Internetrouter hat 172.16.110.5 /16. Demnach brauch ich ja auf dem catalyst doch eigentlich nix blockieren, denn ein Client XY 172.16.*.* /16 gelangt ja auf direktem Wege auf den Internetrouter 172.16.110.5 /16, ohne durch den catalyst geroutet werden zu müssen. Auf dem Internetrouter ist dann per iptables alles gedroppt, nur dem Squid-Proxy (=172.16.101.254/16) wird erlaubt, den Internetrouter und somit das Internet zu nutzen. Ergo auch kein VLAN16 vorhanden auf dem catalyst.

Kann ich mir also die ACL-Zugriffsbeschränkung wie soeben erklärt einfach sparen? Dann müsste ich ja noch nur eine iptables Regel am Internetrouter erstellen, und Pakete erlauben die von 172.19.30.0 /24 aus kommen und ins Internet wollen.

Das Gast VLAN hängt man dann mit einer Captive Portal Option wie du es ja schon mit dem Ubiquity hast oder ein CP wie der oben zitierten pfSense z.B. direkt ins WAN VLAN ohne Routing über den Catalyst. Das ist dann wasserdicht.

Wie macht man das denn ? In meiner Ubiquiti UniFi WebGUI kann ich ja lediglich wählen, dass sämtliche WLAN-Gäste automatisch ins VLAN30 gewürfelt (getagged) werden. Das macht der Softwarecontroller von Ubiquiti, der auf einer Windows-VM werkelt als Windowsdienst. Würde ich jetzt eine direkte Verbindung zum Internetrouter aufstellen wollen (um den Catalyst zu umgehen wie von dir beschrieben), so müßte ich jetzt wohl von dieser VM ausgehend über trunks oder anderen Switch bis zum Internetrouter gelangen und dort in einen Port einstöpseln (bzw. via VLAN30-interface und dem default trunk-Kanal, der ja mit eth interface gebridget ist). Außerdem hätte ich durch diese Umgehungsmaßnahme auch das weitere Problem, dass kein DHCP-Server (mittels relay/IP helper) mehr Leases an die WLAN-Gäste verteilen könnte so wie ursprünglich geplant. Ich könnte dann aber auf dem OpenWRT-Router DHCP-Server laufen lassen, und die VLAN30-Gäste versorgen, oder nicht?

Das ist technischer Unsinn, denn ein VLAN mit der ID 0 gibt es technisch nicht !
Nunja, das ist wohl was internes und Unsinn in dem Sinne ist es ja nicht, denn das hab ich nicht frei vom Kopf erfunden. Die zwei geposteten Links in meinem letzten Beitrag (1 und 2 erklären das ja genau.

Aqui, nur um das mal zusammenzufassen ... (bitte korrigier mich entsprechend):

Ich hab folgende Möglichkeiten:

(Methode 1)
  • ich installiere die aktuelle image-Version auf meinen Catalyst c3560g-24ts und zwar IPBASE with web+crypto (IPSERVICES geht leider nicht!) und hätte dadurch leider keine Möglichkeit auf proxy zwangs redirects durch die wccp Funktion.
  • die WLAN-Gäste erhalten durch mein CP automatisch VLAN30 zugewiesen.
  • ich nutze meinen vorhandenen DHCP-Server /Cluster (Debian VM) (derzeit 172.16.0.0/16) indem ich ein weiteres scope hinzufüge für die geplanten WLAN-Gäste. Das mache ich indem ich meiner VM ein 'echtes' VLAN30-Interface (=eth1) spendiere und dieses neue zusätzliche WLAN-GAST Scope nur für dieses neue eth1-interface gültig mache. Damit erhalten die WLAN-Gäste eine Lease aus beispielsweise 172.19.30.0/24. Dazu müsste ich wohl auf Debian das Paket "isc-dhcp-relay" installieren, damit ich dem explizit sagen kann, für scope1/subnet1 soll er eth0 verwenden, und für scope2/subnet2 soll er eth1 verwenden?? Oder wie sonst soll mein DHCP-Server wissen, dass er Anfragen, die aus eth1 kommen, mit scope2 bearbeitet werden sollen und Anfragen aus eth0 mit scope1?
  • Dann aktiviere ich auf meinem Catalyst ip helper und leite BOOTP-Anfragen die aus VLAN30 kommen zu meinem DHCP-Server.
  • Der WLAN-Gast erhält somit seine Lease im VLAN30-Segment aus dem Bereich 172.19.30.0/24. Als default gateway bekommt er die 172.16.101.254 /16, die momentane IP des Catalyst C3560.
  • Auf dem Catalyst trage ich die Route 0.0.0.0 mit Ziel 172.16.110.5 /16 (=Internetrouter/OpenWRT) ein
  • Auf dem Catalyst erlaube ich durch die oben gezeigte extended ACL den Zugriff auf 172.16.110.5 /16, nur für Hosts aus 172.19.30.0 /24
  • Auf dem Internetrouter 172.16.110.5 /16 erlaube ich durch iptables den Zugriff aufs Internet für Hosts aus 172.19.30.0 /24

(Methode 2)
--> wie Methode 1, jedoch mit folgenden Unterschieden

  • auf dem Internetrouter/OpenWRT erstelle ich ein VLAN-Interface VLAN30 und weise diesem die IP 172.19.30.5 /24 zu.
  • ich erstelle irgendwie einen DHCP-Server auf dem OpenWRT Internetrouter 172.16.110.5 /16 und verteile IPs im Bereich 172.19.30.0 /24, nur gültig für VLAN30 = 172.19.30.5 /24 (muss ich mich schlau machen, wie ich das auf dem OpenWRT umsetze)
  • dieser auf dem OpenWRT/Internetrouter arbeitende DHCP-Server vergibt Leases an die WLAN-Gäste mit default gateway = 172.19.30.5 /24
  • die WLAN-Gäste kommen daher auf direktem Wege bis zum Internetrouter und somit ins Internet


Hab ich das richtig verstanden?
Bitte warten ..
Mitglied: aqui
05.08.2014, aktualisiert 06.08.2014
Wenn ich das richtig verstanden habe: ich setze eine statische Route auf meinem Catalyst für 0.0.0.0 mit Ziel 172.16.110.5/16 (mein OpenWRT Internetrouter).
Ja, richtig. Allerdings passt die IP Adresse NICHT in dein obiges neues VLAN Konzept !!!
Du solltest dieses Altnetz ja auch erstmal weiter behalten um sanft auf dein neues Design migrieren zu können.
Richte also ein vlan 16 name Altnetz ein mit der Horrormaske aber nimm den Internet Router da raus !!
Der sollte mit Proxy separat isoliert in ein WAN / Internet VLAN aber NICHT in ein Produktiv VLAN !
Da du das gateway ja via DHCP vergibst biegst du im DHCP Server die Gateway IP um auf die Switch IP im VLAN 16...oder
Du migrierst die Internet Router IP auf die VLAN 16 Switch IP und gibst dem Router eine neue IP was du ja so oder so machen musst wenn du den in einem separaten VLAN isolierst ! Das erspart dir dann das DHCP anpassen obwohl du es eh machen musst für die anderen VLANs....

denn das hab ich nicht frei vom Kopf erfunden. Die zwei geposteten Links in meinem letzten Beitrag (1 und 2 erklären das ja genau.
Trotzdem ist ein VLAN mit der ID 0 im IEEE 802.1q Standard nicht definiert und gibt es auch nicht. Kein Switch kann damit was anfangen oder forwardet das ins Defalt VLAN.
Der OpenWRT Link meint damit vermutlich das ungetaggte Default VLAN.

Ein paar Missverständnisse hast du wieder in deiner Zusammenfassing !!!
1.) Du musst auf dem DHCP Server keinerlei Relay definieren !!! Nur den Scope eintragen fertig !!
Die Relay Funktion macht die "ip-helper adrress xyz" Konfig auf deinem Catalyst Switch !!!
Vergiss also den Unsinn mit der Relay Frickelei am DHCP Server !
Außnahme: Du isolierst das VLAN 30 vom Switch (Kein L3 Interface) dann muss dein Captive Portal oder wie auch immer du dann die Kopplung VLAN 30 zum Internet Router machst das abfackeln mit einem eigenen nur für VLAN 30 DHCP Server.
Mach das aber so wie oben besprochen und zieh das mit über den Switch, Helper Adresse, Access List...fertig ! Ist am einfachsten für deine Umsetzung !

Übrigens: die Scopes musst du für ALLE deine VLANs eintragen für die du per DHCP IP Adressen zentral dynamisch vergibst ! Nicht nur fürs VLAN 30 !

2.)
Auf dem Catalyst erlaube ich durch die oben gezeigte extended ACL den Zugriff auf 172.16.110.5 /16, nur für Hosts aus 172.19.30.0 /24
Auch das ist falsch !!
Du willst doch nicht das die Gäste deinen Router selber telnetten oder die Konfig GUI aufrufen können und Zugriff auf den Router direkt bekommen, oder ??
Wozu denn also der Unsinn mit "...den Zugriff auf 172.16.110.5 /16" ??
Also richtig ist Hosts aus dem Netz 172.19.30.0 /24 denyen für alle deine VLANs aber auf any erlauben !
So wird ein Schuh draus fürs Gast Internet !!

Ansonsten hast du aber beide Methoden genau richtig verstanden und wiedergegeben !!
Bitte warten ..
Mitglied: panguu
11.08.2014, aktualisiert 12.08.2014
Hallo nochmal. Beim erneuten Durchlesen dieses Threads ist mir aufgefallen, dass ich eine ganz wichtige Information vergass, aufzulisten:

ich nutze nämlich zwei Internetleitungen. Die eine Internetleitung hat 10MBit/s down und 5MBit/s up, und die andere hat 100MBit/s down und 2,5MBit/s up. Erstere ist für unseren WWW, FTP, Mailverkehr, EDI, usw... gebraucht, während die zweite Internetleitung mit der höheren Downstream-Bandbreite (100MBit/s) exklusiv NUR für's Internetsurfen gedacht ist. Die IPfire und DMZ, die ich in meinem Beitrag erwähnte, und worauf du dich immer bezogen hattest, die ist nur im Internet1 Strang vorhanden. Fürs Internet-Surfen wird das schnellere Internet2 genutzt. Und zwar ist dort auf dem OpenWRT Router per iptables geregelt, dass NUR der Squid-Proxy rausdarf ins Internet. Und die Workstations im Netz nutzen den squid, um im Internet surfen zu können, das ist der Stand aktuell. Ich hab mal schnell per Hand 'ne Skizze gemacht, die das hoffentlich verdeutlicht:

2a0eb146b77868b5d6cc5687225668b0 - Klicke auf das Bild, um es zu vergrößern

Es geht mir jetzt ja hauptsächlich um die WLAN-Gäste und VLAN30, welches ich parallel zum produktiven Betrieb aufbauen möchte. Die WLAN-Gäste erhalten von den Ubiquiti UAPs automatisch VLAN id 30 zugewiesen. Wäre es denn verkehrt, wenn ich die WLAN-Gäste direkt über den LinksysWRT54GL ins Internet2 schicke? Dann müsste ich doch lediglich am OpenWRT-Router ein zusätzliches VLAN30 Interface erstellen mit z.B. 192.168.111.5/24 und auf dem OpenWRT-Router selbst auch mittels dnsmasq einen DHCP-Server betreiben, der nur auf VLAN30 reagiert/lauscht. Somit müssten ja dann die WLAN-Gäste, die sich authentifiziert haben und in VLAN30 utnerwegs sind, vom DHCP-Server des OpenWRT Routers eine IP erhalten. Und diese DHCP-Lease übergibt denen das Gateway 192.168.111.5 womit sie direkt ins Internet rauskönnten. Und per iptables auf dem OpenWRT könnte ich ja dann Zugriff beschränken und definieren, dass alles aus dieser DHCP-verteilenden Range (z.B. 192.168.111.10-250) nur Port 21, 80, 443 im Internet kontaktieren dürfen.

Was wäre denn falsch daran, bzw. wo sind meine Denkfehler? Worin lägen die Vor-/Nachteile dieser Variante, und der von dir beschriebenen, alles mittels dem internen Proxy und internem DHCP-Server abzuwickeln?

Freue mich auf feedback und sag schonmal danke im Voraus.
Bitte warten ..
Mitglied: aqui
12.08.2014, aktualisiert um 18:39 Uhr
Lasse bitte den Unsinn mit externen Bilderlinks oder Downloads hier !! Die Forumscommunity wird es dir danken und als alter Forumshase solltest du das auch wissen !
Beim Erstellen des Threads wird es dir sicher nicht entgangen sein das es hier eine hervorragende Bilder Upload Funktion gibt ?!
Wenn doch, dann wähle bitte deinen Ursprungsthread unter "Fragen" aus, und klicke auf Bearbeiten oben. Der Button ist nicht zu übersehen.
Mit einem Klick darauf kannst du dann dein Bild hochladen und hat das Erfolg, bekommst du einen Bilder Link den du mit einem Rechtsklick und dann Cut and Paste in JEDEN Text hier bringen kannst !! Auch Antworten !
Statt des Bilder Links wird dann ...et voila...deine Grafik embedded angezeigt und erspart uns Extraklicks, Viren und Zwangswerbung !
Kann man übrigens auch immer noch nachträglich machen....

Zurück zum eigentlichen Thema....
ich nutze nämlich zwei Internetleitungen.
OK, dann wäre ein intelligentes Link Balancing mit Failover für dich das was du als Lösung anstreben solltest. Dual WAN Balancing Router wie der Draytek 29xx oder Linksys LRT 224 usw. sind dann das Mittel der Wahl.
Oder...noch besser du machst ein Policy based Routing (PBR) mit dem Catalyst Switch, der das auch kann.
Wie man sowas elegant löst erklärt dir dieser Thread:
http://www.administrator.de/articles/detail.php?id=103423
Wäre es denn verkehrt, wenn ich die WLAN-Gäste direkt über den LinksysWRT54GL ins Internet2 schicke?
Nein, das wäre nicht verkehrt und kann man machen...für einen der Internet Router musst du dich ja entscheiden
Dann müsste ich doch lediglich am OpenWRT-Router ein zusätzliches VLAN30 Interface erstellen mit z.B. 192.168.111.5/24
Ja, richtig ! Allerdings musst du das nur und ausschliesslich machen wenn du das VLAN 30 NICHT routingtechnisch am Catalyst auflaufen lässt. Du darfst dort also kein Layer 3 Interface für das VLAN 30 erstellen !!
Wenn doch, dann entfällt wiederum das VLAN 30 Interface am Router. Dann reicht eine Accessliste wie oben beschrieben am Catalyst die das VLAN 30 fernhält von den internen VLANs.
Beide Möglichkeiten funktionieren, sind richtig und enthalten keine Denkfehler !
Vorteile Catalyst: Einfach einzurichten, kein VLAN Gefrickel auf dem Internet Router
Nachteil: Znetrale Accesliste erstellen und immer auf Plausibilität und Lücken überwachen
Vorteile WRT: Kein Routing am Catalyst und wasserdichte Trennung vom Restnetz
Nachteil: Gefrickel mit dem VLAN und Erstellung am WRT Router. ACL muss dort ebenfalls gepflegt werden.
Bitte warten ..
Mitglied: panguu
12.08.2014, aktualisiert um 22:14 Uhr
Du hast mich ja bereits schon einmal darauf hingewiesen, die interne Bildupload-Funktion zu verwenden. Ich hatte daraufhin wie ein Verrückter gesucht und auch die HIlfe durchlesen. Aber ich hatte diesen Bereich einfach nicht finden wollen. Du hast mir jetzt durch deinen letzten Kommentar endlich verständlich gemacht, wie das funktioniert. Um ehrlich zu sein finde ich das aber schon sehr unüblich wie man hier Bilder hochladen tut. Ich bin Mitglied in sehr vielen andren Foren, und da ist das deutlich einfacher, aber was solls...will ja nicht rummeckern bin froh dass es das Forum überhaupt gibt. An dieser Stelle danke für den Hinweis ==> "den gesamten "Inhalt" in der "Meine Inhalte"-Seite bearbeiten zu müssen, damit man überhaupt auch Bilder hochladen kann. Durch Editieren des Beitrags an sich, ist das nämlich nicht möglich, deswegen fand ich das bei meinem letzten Versuch nicht. Ich hab jetzt die entsprechenden Links in den Beiträgen angepasst und somit ersetzt, hoffe das passt so. :p

Back to Topic:

Freut mich das zu hören, ich denke ich hab das dann richtig verstanden. Ich werde wohl aus Gründen der "wasserdichten" Trennung die OpenWRT-Variante ausprobieren. So haben die WLAN-Gäste absolut nix im restlichen Netzwerk zu suchen, und können auch durch "falsch-geratene" oder "vergessene/fehlerhafte" ACL-Konfigurationen keine Schlupflöcher ausnutzen. Natürlich muss ich auf dem OpenWRT-Router die iptables genauso mit Sorgfalt anpassen. Jetzt müsste ich mich nur mal schlau machen, wie ich das komfortabel alles auf dem OpenWRT Router managen kann. Soweit so gut, ich meld mich wieder wenn's irgendwo klemmt

VIELEN HERZLICHEN DANK soweit.

Grüße,
Pangu
Bitte warten ..
Mitglied: aqui
13.08.2014 um 10:37 Uhr
Um ehrlich zu sein finde ich das aber schon sehr unüblich wie man hier Bilder hochladen tut
Da ist @Frank der Betreiber dieses Forums der richtige Ansprechpartner für dich !
danke für den Hinweis ==> "den gesamten "Inhalt" in der "Meine Inhalte"-Seite bearbeiten zu müssen, damit man überhaupt auch Bilder hochladen kann.
Das ist auch Unsinn, denn das muss man nicht. Erstens reicht ein einziger Thread oder wenn man allgemein Bilder hochladen will erzeugt man z.B. unter "Humor" oder einem anderen nicht wichtigen Bereich einen "Dummy Thread" den man auf "Nicht freigeben" setzt. In diesen kann man dann alle Bilder die man so zwischendurch mal hochladen will oder muss reinlegen und bekommt so mit diesem kleinen Umweg quasi einen Bilder Container....

Dann noch viel Erfolg mit deiner Netzwerk Restrukturierung. Bist damit auf alle Fälle auf dem richtigen Weg !
Bitte warten ..
Mitglied: panguu
23.09.2014, aktualisiert um 16:26 Uhr
Hallo aqui (und Rest),

zwischenzeitlich war ich noch mit einigen anderen wichtigen Arbeiten beschäftigt, deshalb hab ich mich länger nicht mehr gemeldet. Ich habe jedoch schon einige Fortschritte erzielen können, habe dennoch noch einen weiten Weg vor mir und hoffe weiterhin auf deine/eure Hilfestellung. Hier mal der aktuelle Stand des VLAN30, also wie ich die WLAN-Gäste abwickle:

Der WLAN-Gast (durch sein Notebook, Smartphone, Tablet, ...) verbindet sich im ersten Schritt mit der ausgestrahlten ESSID names "WLAN-GUESTS". Da es sich um ein offenes Netzwerk handelt, muss er kein Passwort eingeben. Nach erfolgreicher Verbindung wird er durch das CaptivePortal ins VLAN15 zugewiesen (VLAN30 wollte ich ja ursprünglich für die Gäste nutzen, musste aber VLAN15 nehmen, weil OpenWRT nur bis ID 15 unterstützt). Auf dem OpenWRT-Internetrouter habe ich ein VLAN15-Interface hinzugefügt mit der IP 192.168.15.254 (/24). Nur auf diesem Interface läuft ein DHCP-Server, der somit leases von 192.168.15.11-249 /24 im VLAN15 verteilt. Somit erhält jeder WLAN-Gast eine IP aus diesem Adressbereich zugeteilt. Damit er aber auch Zugriff ins Internet erhält, muss er erstmal einen gültigen Voucher-Code eingeben, sich also am CP authentifizieren. Erst nach erfoglreicher Auth erlangt er somit Zugriff auf das offene Internet, direkt durch diesen OpenWRT-Internetrouter. Hier eine kleine Skizze:

1521d80faeee1052efb2022a69a6dd9b - Klicke auf das Bild, um es zu vergrößern

Meine ganzen Ubiquiti UAP-LR Accesspoints haben außerdem ebenfalls und automatisch eine DHCP-Lease vom im VLAN15 dienenden DHCP-Server erhalten, das sieht dann im CLI bei denen ungefähr so aus:

br0.15 Link encap:Ethernet HWaddr 24:A4:3C:AA:BB:CC
inet addr:192.168.15.31 Bcast:192.168.15.255 Mask:255.255.255.0

Funktioniert bisher alles erste Sahne und genauso wie ich's mir erhofft hatte. Durch diese Konfiguration schleife ich quasi WLAN-Gäste vollständig am bestehenden Firmennetzwerk vorbei und leite sie direkt auf den Internetrouter, der nur 192.168.15.0/24 Hosts direkt ins Internet erlaubt.

==> So, nun möchte ich zum nächsten Schritt übergehen, und meine neuen firmenbezogene VLANs erstellen. Meinen core switch habe ich soweit mit dem empfohlenen aktuellen image (ipservices) ausgestattet und rebootet, so dass das neue image auch aktiv ist. Die ganzen bestehenden configs blieben dabei unverändert und somit aktiv.

Mein Plan sieht dabei so aus:

- das bestehende Netz in der Horrormaske /16 muss ja erstmal unangetastet bestehen bleiben, da es sich um das Produktivnetz handelt. Hier steckt ja einfach alles mit drin, sprich: "Server", "Clients", "Drucker", usw... damit muss man tag täglich arbeiten, und die kann ich unmöglich in einer Nacht-und-Nebel Aktion komplett umbiegen. Deshalb plane ich eine Art übergangsweise "Migrations-VLAN" namens VLAN16 auf meinen gesamten Switches im Netzwerk zu erstellen, und mittels trunk auch dafür zu sorgen, dass VLAN16 eben überall durchgeschleift wird (tagged via 802.1q). Dann erstelle ich auf meinem core switch (=Catalyst C3560G-24TS) auch ein Interface für dieses VLAN16 und verpasse ihm die IP 172.19.16.254.

- jetzt erstelle ich als nächstes auf diesem core switch auch ein VLAN100 und das Interface dazu 172.19.100.254. Das VLAN100 soll mein zukünftiges VLAN100 werden. Ich könnt jetzt z.B. hergehen und auf meiner Xenserver-Farm einen neuen Server erstellen mit der IP 172.19.100.123 /24.

Dadurch, daß auf dem core switch "ip routing" aktiviert ist, müsse demnach ein alter Client aus der bestehenden 16er-Maske (z.B. 172.16.200.11 /16) den neuen Server im VLAN19 erreichen können (172.19.100.123 /24), oder nicht? Wenn mein Gedankenansatz richtig wäre, könnte ich nämlich nun Schritt-für-Schritt und mit den Tagen/Wochen anfangen, die ganzen Hosts umzubiegen. Als Beispiel: Ich ändere die Netzwerkkonfiguration eines Servers um (natürlich ggf. Serverdienste checken und configs anpassen):

von alt:
IP: 172.16.103.50
Subnet: 255.255.0.0
Gateway: 172.16.254.1 (=das ist das vlan1 interfaces des core switch WS-C3560G-24TS)

auf neu:
IP: 172.19.100.222
Subnet: 255.255.255.0
Gateway: 172.19.100.254

Müsste hierzu aber noch eine "ip route ..." gesetzt werden, oder wird automatisch durch das globale "ip routing" Kommando geroutet und ich muss nur die ACLs anpassen, um den Gürtel enger zu schnallen?

Dann würd ich noch gerne wissen, wie das Best-Practice aussieht für die Absicherung der Management-Interfaces diverse Geräte. Aqui schrieb dazu:

Auf den ersten Blick fehlt ein Management VLAN in dem alle Mangement IPs vereint sind um sie vor Client Zugriffen zu schützen aber vermutlich meinst du damit das VLAN 254 "Switches,Router" ?!

Wie genau sollte ich das anstreben? Die Workstations/Clients + Drucker sollen ja im VLAN200 sein und somit im subnet 172.19.200.0 /24. Die Server sind VLAN100 und subnet 172.19.100.0 /24. Und meine USVs, Bladecenter-IO-Module, Klimagerätsteuerung, BMC-Adapter diverse IBM-Server, usw... sprich die ganzen Managementinterface sollen ins VLAN253 und subnet 172.19.254.0 /24. So hatte ich das zumindest verstanden. Damit dieses Modell funktioniert, müssten die Admins (Kollegen+Ich) in ein getrenntes VLAN und somit subnet rein, damit eine Unterscheidung zwischen "Normalen Clients" und "Admins" erfolgen kann? Also die Admins dem VLAN222 und 172.19.222.0 /24 zuordnen und dann eben per ACL festlegen, dass nur die Admins auf die Managementinterfaces drauf dürfen?
Bitte warten ..
Mitglied: aqui
23.09.2014 um 19:23 Uhr
und hoffe weiterhin auf deine/eure Hilfestellung.
Aber immer doch...dafür ist ein Forum ja da
Meine ganzen Ubiquiti UAP-LR Accesspoints haben außerdem ebenfalls und automatisch eine DHCP-Lease vom im VLAN15 dienenden DHCP-Server erhalten
Das ist keine gute Lösung, denn damit sind die Management IP Adressen offen in einen auch noch offenen Gäste Segment verfügbar !
Kein verantwortungsvoller Netzwerker macht sowas. Ist zudem auch noch vollkommen unverständlich denn MultiSSID APs haben die Management IP immer auf dem Default VLAN.
Es wäre hier erheblich sicherer wenn du die Management IPs in ein separates internes VLAN verlegst. Es sei denn du kannst mit dieser erheblichen Sicherheitslücke leben ?!
Zum Plan....
das bestehende Netz in der Horrormaske /16 muss ja erstmal unangetastet bestehen bleiben
Ja, das ist auch der genau richtige Weg. Du erzeugst z.B. ein VLAN 99 mit dem Namen "Altnetz" inkl. L3 Interface und hängst da das Horrornetz rein.
Die Schritte dann die weiteren VLANs einzurichten und Komponenten Stück für Stück zu migrieren ist auch hier genau richtig.
Auch die IP Konfiguration usw. alles korrekt !
Müsste hierzu aber noch eine "ip route ..." gesetzt werden,
Nein, das wäre ja Blödsinn, dein Cat 3560 ist ja der zentrale Router für alle zukünftigen VLANs und diese sind ja alle direkt an ihm angeschlossen. Folglich "kennt" der also alle lokalen IP Netze und den einzigen Routing Eintrag den du dort konfigurieren musst ist die Default Route auf den Internet Router (ip route 0.0.0.0 0.0.0.0 1.2.3.4)
Den Internet Router solltest du in ein separates VLAN legen und von den Server und anderen Produktivnetzen immer trennen. War ja oben auch schon richtigerweise dein Plan.
Mit den ACLs ist richtig wenn du den Zugriff in einzelne Segmente etwas restriktiver handhaben willst wie z.B. das 192.168.15.0er Segment komplett filtern das nicht einer der Gäste hinterrücks wieder ins Firmennetz kommt....
Best-Practice aussieht für die Absicherung der Management-Interfaces diverse Geräte.
Wie schon oben beschrieben....leg die in ein separates VLAN oder belasse sie im VLAN 1 das du dann für kein der produktiven VLANs verwendest !
Da du mit der IT Abteilung ja vermutlich auch im VLAN 200 steckst setzt du vor das Management VLAN eine ACL die nur Zugriffe eurer IP Adresse zulässt.
Alternativ hebst du die IT Abteilung komplett in ein separates VLAN und filterst das ganze Netz dann ins management VLAN. Oder legst IT und Management VLAN in ein gemeinsames VLAN 253 (Bei der IP hast du da wohl einen Fehler gemacht, oder müsste ja richtigerweise 172.19.253.0 /24 sein, oder ?) .
Das musst du entscheiden was besser in eure Arbeitsumgebung passt.
Bitte warten ..
Mitglied: panguu
24.09.2014, aktualisiert um 15:09 Uhr
Das ist keine gute Lösung, denn damit sind die Management IP Adressen offen in einen auch noch offenen Gäste Segment verfügbar !
in der Tat. Diesbezüglich habe ich bereits eine Anfrage im support-Forum Ubiquiti gestellt. Ein anderer User steht momentan vor derselben Frage. Ich vermute, dass ich entgegenwirkend per internen Firewall-Regeln den Zugriff darauf verbieten könnte, aber ich warte erstmal auf Antwort ab. Das beste wäre natürlich, dass Management lediglich auf dem default interface stattfinden kann, und sonst nirgends. Danke für den Hinweis.

Nein, das wäre ja Blödsinn, dein Cat 3560 ist ja der zentrale Router für alle zukünftigen VLANs und diese sind ja alle direkt an ihm angeschlossen. Folglich "kennt" der also alle lokalen IP Netze...
Verstanden.

Du erzeugst z.B. ein VLAN 99 mit dem Namen "Altnetz" inkl. L3 Interface und hängst da das Horrornetz rein.
Ich habe mir erstmal die running-config meines core switches angezeigt, um alle Einträge aufzulisten, die mit meinem Horrornetz 172.16.0.0/16 in Verbindung stehen. Der Output des Befehls "sh ru | i 172.16" gibt u.a. folgendes aus:

ip name-server 172.16.1.22

interface Vlan1
ip address 172.16.254.1 255.255.0.0

ip route 10.20.30.0 255.255.255.0 172.16.110.7
ip route <diverse andere statischen Routen> 172.16.foo.bar

ntp server 172.16.110.7
ntp server 172.16.254.9 key 0 prefer

Ich habe ein VLAN 16 erstellt mit Bezeichnung "Old_network", das VLAN 16 ist nun also vorhanden. Aber ich frage mich, ob es nicht "problematisch" werden könnte, wenn ich an diesem Punkt ausführen würde: "conf t" --> "int vlan 16" --> "ip address 172.16.16.16 255.255.0.0" und meinem vlan16 interface quasi die IP 172.16.16.16 /16 verpasse. Oder ist das genau der richtige Ansatz ?
Bitte warten ..
Mitglied: panguu
25.09.2014 um 17:20 Uhr
ich denke da an einen anderen Migrationsweg... Beispiel: ich möchte Hosts aus meinem aktuellen flachen /16 old_network in die neu erstellten VLANs migrieren. Ich möchte z.B. Hosts aus meinem 172.16.0.0/16 subnet hinüber in die neuen VLANS ==> VLAN10 (172.19.10.0/24), VLAN20 (172.19.20.0/24), VLAN30(172.19.30.0/24), VLAN100 (172.19.100.0/24) und VLAN200 (172.19.200.0/24) migrieren.

Mein core switch hat aktuell lediglich ein VLAN1 interface mit der Addresse "172.16.254.1/16". Nun erstelle ich mit diesen Befehlen zusätzliche (sogenannten secondary's) auf diesem VLAN1 interface:

conf t
int vlan1
ip address 172.19.10.1 255.255.255.0 secondary
ip address 172.19.20.1 255.255.255.0 secondary
ip address 172.19.30.1 255.255.255.0 secondary
ip address 172.19.100.1 255.255.255.0 secondary
ip address 172.19.200.1 255.255.255.0 secondary

Durch diese übergangsweise Konfiguration könnte ich somit meine Hosts in die neuen subnets rüberziehen, so daß eine Kommunikation untereinander stattfinden kann. Wenn ich beispielsweise alle Hosts aus dem bestehenden flachen old_network in einem VLAN-Segment rübermigriert habe und somit fertig bin mit diesem jeweiligen VLAN (nehmen wir als Beispiel an, ich habe alle Hosts in VLAN20 und bin damit fertig), so gehe ich nun her und lösche diese secondary ip address vom vlan1 interface und erstelle nun mit

conf t
int vlan20
ip address 172.19.20.1 255.255.255.0

das endgültige VLAN interface für dieses jeweilige VLAN.

Sollte doch eigentlich so funktionieren, was denkt ihr?
Bitte warten ..
Mitglied: aqui
25.09.2014 um 20:22 Uhr
Ich vermute, dass ich entgegenwirkend per internen Firewall-Regeln den Zugriff darauf verbieten könnte, aber ich warte erstmal auf Antwort ab.
Nöö, viel einfacher: Einfach auf das Default VLAN keine SSID legen sondern nur auf die tagged VLANs
Cisco Catalyst Config:
ip name-server 172.16.1.22 = Nicht Konfig relevant, sorgt dafür das auf dem CLI Hostnamen in IPs aufgelöst werden können (kosmetisch)
interface Vlan1
ip address 172.16.254.1 255.255.0.0 = Ist das Layer 3 Routing Interface des "Horrornetz" im Core Switch
ip route 10.20.30.0 255.255.255.0 172.16.110.7 = Im "Horrornetz" gibt es wohl noch externen Router die andere einzelne IP Netze bedienen
ip route <diverse andere statischen Routen> 172.16.foo.bar = dito. wie oben sind weitere externen Router.
ntp server 172.16.110.7 = Nicht Konfig relevant, sorgt dafür das der Switch autom. die aktuelle Zeit bekommt im Logging (kosmetisch)

Aber ich frage mich, ob es nicht "problematisch" werden könnte, wenn ich an diesem Punkt ausführen würde: "conf t" --> "int vlan 16" --> "ip address 172.16.16.16 255.255.0.0" und meinem vlan16 interface quasi die IP 172.16.16.16 /16 verpasse.
Ja der Ansatz ist höchst problematich, denn so hättest du ja 2 mal das "Horrornetz" auf dem Catalysten. Abgesehen davon das das Unsinn ist, wird dir der Cisco das auch mit einem "Duplicate IP Address" Fehler ablehnen in der Konfig !
Klar und logisch, denn 2 identische Segmente mit der gleichen IP geht nicht !
Es gibt 2 Lösungen:
1.) Du belässt das "Horrornetz" einfach auf dem VLAN 1 Interface, denn da liegt es ja schon mit der 172.16.254.1 255.255.0.0 und kümmerst dich nur um deinen neuen Netze !
2.) Wenn die 172.16.254.1 255.255.0.0 im Horrornetz nicht aktiv genutzt wird (Routing, Gateway) dann musst du so vorgehen:
  • no interface vlan 1 (vlan 1 L3 Interface und IP entfernen)
  • interface vlan 16 (neues vlan 16 Interface einrichten)
  • ip address 172.16.254.1 255.255.0.0 oder die von dir favorisierte 172.16.16.16 255.255.0.0
  • Alle Ports die im VLAN 1 sind nun in das VLAN 16 heben !
Fertig.
Um das einzurichten mit den 2 Kommandos brauchst du ca. 20 Sekunden. Wenn du übst auch 10 ! Für diese Zeit ist das L3 Routing Interface auf dem Catalysten mal kurzzeitig nicht erreichbar, was aber jedes LAN verschmerzen kann wenn du es nicht gerade mitten in der Arbeitszeit machst außer natürlich diese IP wird gar nicht benutzt, dann ist es eh egal !
Achtung hier: Sollte die 172.16.254.1 irgendwie benutzt werden musst du mit einer Änderung auf die 172.16.16.16 /16 aufpassen, denn der Catalyst hat ja statische Routen. Ggf. sind diese dann nicht mehr zu erreichen wenn du die Interface IP änderst, das musst du wasserdicht klären VORHER.
Im Zweifel belässt du es bei der alten IP im VLAN 16 !
Option 2 ist also mehr Arbeit und hat nur kosmetischen Effekt, denn ob das nun in VLAN 16 hängt oder VLAN 1 ist ja erstmal nur kosmetisch wenn es für dich keinen Nachteil hat das das das Default VLAN ist !?
ich denke da an einen anderen Migrationsweg... Beispiel: ich möchte Hosts aus meinem aktuellen flachen /16 old_network in die neu erstellten VLANs migrieren.
Oooops nun wieder alles anders ?? Aber genau den Weg hatten wir doch nun all diesen zahllosen Threads als richtig und sinnvoll besprochen...
Was denn nun ???

Secondary IPs:
Uuuhhhh...keine gute Idee !! Ja, machbar aaaber.
Damit fährst du quasi mit mehreren IPs auf einem Draht. Kann man nur dringenst von abraten, denn TCP/IP ist dafür nicht gemacht. Das Kardinalsproblem sind ICMP Pakete, denn der Router "weis" jetzt nicht für welches Netzwerk er die senden soll und sendet die ausschliesslich nur von der Primary Adresse.
Die Secondary IP Variante solltest du nur in betracht ziehen wenn du an dem Tag wo du das umstellst damit arbeitest das aber dann wieder entfernst. Also machen...alle Hosts auf neue IP migrieren, Connectivity testen... Secondary entfernen und Hosts ins neue VLAN umziehen.
In längere Produktion solltest du damit nicht gehen !
Und im Ernst: Was hättest du damit gewonnen im Vergleich zur sukzessiven Migration Host für Host die dann sauber vonstatten geht...eigentlich nix. Besser also Finger wech von Secondaries oder nur wirklich wenn du das in zeitlich überschaubarem Rahmen machst ! Generell sind die Secondaries ja auch dafür da.
Bitte warten ..
Mitglied: panguu
25.09.2014, aktualisiert 26.09.2014
Nöö, viel einfacher: Einfach auf das Default VLAN keine SSID legen sondern nur auf die tagged VLANs

oh, ich vergass hierzu Stellung zu nehmen. Das Problem ist gelöst mit Hilfe von Ubiquiti. Leider kann ich nicht explizit Mgmt-Interfaces auswählen, aber es gibt eine Lösung hierzu. Dazu wird für meine Guest-WLAN ESSID einfach folgendes genutzt:

Restricted Subnets = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Allowed Subnets = 192.168.2.250/32, 192.168.15.254/32

wobei 192.168.2.250 erreicht werden muss, weil es der Ubiquiti Softwraecontroller ist und für ein funktionierendes CP erreichbar sein muss, und...
die 192.168.15.254 ist das VLAN15 interface auf dem Internetrouter, worüber die WLAN-guest direkt raus in die weite Welt dürfen

So haben die WLAN-Gäste nirgends Zugriff, keine Pings, kein gar nix, außer eben auf diese zwei genannten Hosts. Passt soweit

2.) Wenn die 172.16.254.1 255.255.0.0 im Horrornetz nicht aktiv genutzt wird (Routing, Gateway) dann musst du so vorgehen:
no interface vlan 1 (vlan 1 L3 Interface und IP entfernen)
Was genau heißt "aktiv genutzt" ? Meine Clients und 99% all meiner andren Hosts (Server, ...) haben ja die 172.16.254.1 als Default-Gateway stehen, das heißt sie müssen diese IP-adresse ja erreichen können, sonst kommen sie auf die anderen gerouteten Netze nicht mehr rüber, die auf diesem core switch geroutet werden (VPN-Strecken).

interface vlan 16 (neues vlan 16 Interface einrichten)
ip address 172.16.254.1 255.255.0.0 oder die von dir favorisierte 172.16.16.16 255.255.0.0
Alle Ports die im VLAN 1 sind nun in das VLAN 16 heben !
achso, verstehe... du meinst also, die IP vom VLAN1 interface entfernen, und stattdessen auf das VLAN16 interface legen? Das wiederum würde aber wieder voraussetzen, dass all meine vorhandenen Hosts aus dem flachen 172.16.0.0/16 subnet ins VLAN16 bewegt werden müssen damit sie Verbindung zu 172.16.254.1 /16 haben könnten, oder nicht? Oder kann ich die einfach unverändert so bestehen lassen, wie sie grad sind (=kein VLAN zugewiesen, und somit im default VLAN1 unterwegs) ?

Die Variante mit den secondary IPs habe ich deswegen angesprochen und vorgeschlagen, weil ich in diversen Cisco-Dokumenten darübre gelesen habe. Anscheinend ist dies der richtige Ansatz für Migrationszwecke, so wie ich sie plane. Das ist natürlich nur temporär, bis eben alles umgestellt wurde. Danach muss ich die secondary IPs entfernen, und sie dem tatsächlichen VLAN zuordnen (siehe auch dazu meinen letzten Beitrag, wie ich das erklärt hatte).

Nun? Was meinst du?
Bitte warten ..
Mitglied: aqui
26.09.2014 um 18:04 Uhr
Leider kann ich nicht explizit Mgmt-Interfaces auswählen,
Musst du ja auch gar nicht machen ! Das Mgmt Interface ist ja immer im Default VLAN 1 (untagged). Du legst einfach keine SSID in das Default VLAN 1 und gut iss.
Auf dem Cisco redirectest du das mit switchport trunk native vlan x in dein managemen VLAN und gut iss.
Dafür muss man eigentlich nicht extra Ubiquiti anrufen ?! Aber egal...deine mehr als umständliche Lösung macht es auch...müsste aber nicht sein.
Oder tunnelt der AP etwa alles zentral auf den Controller ??? Das wäre aus WLAN Performance Sicht übel
Was genau heißt "aktiv genutzt" ?
Das heisst das die 172.16.254.1 255.255.0.0 nirgendwo auf einer der Clients oder Router als Gateway IP genutzt wird !!
Deine statischen Routen auf dem Catalyst lassen daran zweifeln ??!
Wird sie aber nicht genutzt dann kannst du natürlich die "Horrornetz" L3 IP auf dem Catalyst auf jeden beliebigen neuen Wert setzen wie du lustig bist !
haben ja die 172.16.254.1 als Default-Gateway stehen, das heißt sie müssen diese IP-adresse ja erreichen können
Siehste !! Also doch. Du wolltest sie aber gerade auf die 172.16.16.16 /24 setzen. Da wirst du dann viel Spaß haben solltest du das wirklich machen
Das wiederum würde aber wieder voraussetzen, dass all meine vorhandenen Hosts aus dem flachen 172.16.0.0/16 subnet ins VLAN16 bewegt werden müssen
Ja, sicher. Aber DU hattest das ja selber vorgeschlagen weil du ein neues VLAN für dein Horrornetz aufsetzen wolltest obwohl es ja schon ein VLAN dafür gibt nämlich das 1 !
Du bist Schuld...
Oder kann ich die einfach unverändert so bestehen lassen, wie sie grad sind (=kein VLAN zugewiesen, und somit im default VLAN1 unterwegs) ?
Wäre wie oben schon geschrieben die stressfreieste Option...
Mit den Secondaries siehst du das genau richtig. Nur Migration, testen, wieder löschen, gut iss !
Bitte warten ..
Mitglied: panguu
28.09.2014, aktualisiert um 13:41 Uhr
Musst du ja auch gar nicht machen ! Das Mgmt Interface ist ja immer im Default VLAN 1 (untagged). Du legst einfach keine SSID in das Default VLAN 1 und gut iss.
Auf dem Cisco redirectest du das mit switchport trunk native vlan x in dein managemen VLAN und gut iss.

Das klingt interessant, könntest du das ein wenig detailliert beschreiben? Ich bin mir nicht sicher, ob ich das richtig verstanden habe. Ich achte also darauf, dass all meine ausgestrahlten ESSIDs einem VLAN !=0 zugeordnet werden? z.B. FOOBAR ist VLAN2 zugeordnet, JOHNDOE dem VLAN3 und SOMETHING dem VLAN4? Wie leg ich denn jetzt aber fest, auf welchem VLAN das Mgmt-Interface gelegt wird?

Oder tunnelt der AP etwa alles zentral auf den Controller ??? Das wäre aus WLAN Performance Sicht übel
Das kann ich dir nicht genau beantworten. Das was ich aber weiß ist, dass der Software-Controller für den eigentlich WLAN-Betrieb nicht notwendig ist und nicht kontaktiert werden muss. Der Software-Controller ist nur für das Management erforderlich ,und auch für das CP damit die Hotspot/Voucher-Geschichte funktionieren kann, und sich Gäste authentifizieren können.

Wegen dem Gateway, ja du hattest Recht. Hab mich verwurstelt Zum Glück hab ich da aber keine voreiligen Entscheidungen getroffen gehabt, sondern nochmal drüber nachgedacht. Ich hab am Freitag das Ganze bereits schon umgesetzt, oder besser ausgedrückt "ausprobiert". Dazu habe ich meinem VLAN1 interface wie gesagt eine secondary ip 172.19.100.1/24 verpasst und einen Test-Server ins VLAN100 gesetzt mit der IP 172.19.100.123/24. Ich kann dadurch vom alten und produktiven Horrornetz 172.16.0.0/16 diesen Testserver erreichen, der im VLAN100 steckt. Somit steht eine Migration nichts mehr im Wege würde ich sagen. Wenn ich mit einem VLAN komplett fertig bin, dann erst entferne ich diese secondary ip vom VLAN1 interface, und erstelle dann ein VLAN100 interface mit dieser IP 172.19.100.1/24
Bitte warten ..
Mitglied: aqui
29.09.2014 um 09:07 Uhr
Das klingt interessant, könntest du das ein wenig detailliert beschreiben?
Eigentlich ganz einfach !
Die Management IP des APs liegt in derRregel IMMER im Default VLAN und das ist so gut wie immer die 1. Meist ist das auch nicht umschaltbar und fest mit dem VLAN 1 verbunden. Jedenfalls bei Billig APs. bessere sind umkonfigurierbar. Ist also etwas hersteller abhängig.
Wenn man jetzt im SSID zu VLAN ID Mapping auf dem AP einfach keine SSID in das Default VLAN 1 mapped hat man logischerweise dort auch kein WLAN über das man auf die Mgmt IP zugreifen könnte.
Somit ist die Mgmt IP quasi nur für den LAN Zugriff des Admins verfügbar
Das was ich aber weiß ist, dass der Software-Controller für den eigentlich WLAN-Betrieb nicht notwendig ist und nicht kontaktiert werden muss.
OK, das ist dann eher ein Indiz dafür das der WLAN Traffic dann nicht zentrall zum Controller getunnelt wird. Anders sieht es ggf. mit dem Hotspot aus, denn dort MUSS ja jeder Traffic zum Controller, da dieser von TCP 80 Traffic getriggert wird. Heisst also damit auch das der Controller sich ja dann jeden Traffic ansehen muss. Jedenfalls das das CP betrifft !
Wegen dem Gateway....
Der Genetiv ist dem Dativ sein Feind...
Bitte warten ..
Mitglied: panguu
09.11.2014 um 13:10 Uhr
Hi aqui,

etwas länger her, aber zu dem angesprochenen Punkt von dir... wenn ich das richtig verstanden habe, dann mache ich also folgendes:

(als Beispiel, ich habe die User auf VLAN10 und die Gäste auf VLAN20 und das management soll auf 254 stattfinden)

- ich definiere auf meinen APs die ESSID "MGMT" und weise diesem keine VLAN id zu
- dann noch eine weitere ESSID namens "User" und weise diesem die VLAN id 10 zu
- dann noch eine weitere ESSID namens "Guests" und weise diesem die VLAN id 20 zu

Die zwanzig APs sind an Switch-Ports verbunden, die als 802.1q trunk mit "allowed vlans=10,20,254" sind und zusätzlich "trunk native vlan 254" konfiguriert sind. Die gesamten APs hängen verteilt an 5 verschiedenen Switches die ebenfalls mittels einem 802.1q trunk port miteinander verbunden sind und in dessen "allowed vlans" Liste "10,20,254" stehen haben und auch hier mit "native vlan 254" konfiguriert sind.

Damit sollte das doch eigentlich funktionieren, oder?
Bitte warten ..
Mitglied: aqui
17.11.2014, aktualisiert um 04:30 Uhr
Jau, das funktioniert so und ist geau richtig !
Achtung: Das "trunk native vlan 254" musst du nur und ausschliesslich an den AP Ports so definieren.
NICHT an den tagged Uplink Ports die die Switches untereinander verbinden !
Bitte warten ..
Neuester Wissensbeitrag
Festplatten, SSD, Raid

12TB written pro SSD in 2 Jahren mit RAID5 auf Hyper-VServer

Erfahrungsbericht von Lochkartenstanzer zum Thema Festplatten, SSD, Raid ...

Ähnliche Inhalte
Router & Routing
gelöst VLAN Routing mit Netgear GS724Tv4 (7)

Frage von stpb10 zum Thema Router & Routing ...

LAN, WAN, Wireless
gelöst VLAN Routing - L3 oder Firewall? (17)

Frage von pataya zum Thema LAN, WAN, Wireless ...

Router & Routing
gelöst HP VLAN routing (5)

Frage von homermg zum Thema Router & Routing ...

RedHat, CentOS, Fedora
LAG Bonding mit VLAN Routing Centos7 (20)

Frage von OIOOIOOIOIIOOOIIOIIOIOOO zum Thema RedHat, CentOS, Fedora ...

Heiß diskutierte Inhalte
Windows Userverwaltung
Ausgeschiedene Mitarbeiter im Unternehmen - was tun mit den AD Konten? (34)

Frage von patz223 zum Thema Windows Userverwaltung ...

LAN, WAN, Wireless
gelöst Server erkennt Client nicht wenn er ausserhalb des DHCP Pools liegt (28)

Frage von Mar-west zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
FritzBox, zwei Server, verschiedene Netze (21)

Frage von DavidGl zum Thema LAN, WAN, Wireless ...

Viren und Trojaner
Aufgepasst: Neue Ransomware Goldeneye verbreitet sich rasant (20)

Link von Penny.Cilin zum Thema Viren und Trojaner ...