(W)LAN absichern/separieren

darkness · 08 April 2019, 08:24:14

In der "Vor-switchzeit" hatte der Zugriff auf dem Pi geklappt.

Ich vermute das Problem in der Fritzbox.

Für den Pi (172.16.1.1) versuche ich das Fowarding einzurichten. Dabei meckert die Fritzbox, dass der Eintrag bereits vorhanden ist.
In der Geräteübersicht ist der Pi mit der IP 192.168.178.2 (an LAN4 der Box) vorhanden.

Ich vermute es liegt am Routingeintrag auf der Fritzbox (172.16.0.0/24 an 192.168.178.2). Routing von der Fritzbox auf den GI10 am Switch.
Den Ping usw. werde ich später mal Testen. Aber da die Namensauflösung aus dem 192.168.178er Netzt klappt (Pi-Hole), gehe ich davon aus das es läuft.

Edit:
Ansonsten werde ich mal schauen dem PI auch eine Adresse aus dem 192.168.178er Netzt zu geben.

darkness · 09 April 2019, 14:22:07

Hey,

Macht es einen Unterschied mit 172.16.0.0/16 oder mit 172.16.X.0/24 ein Routing zu machen?

Bisher dachte ich, das sei egal, da ja alles was 172.16 ist zum Switch geroutet werden soll.
Oder muss ich für jedes VLAN-Subnetz eine eigene Route erstellen?

Zweite Frage.

Bisher habe ich ja den WLAN-Teil noch über die Fritzbox laufen, was zu den Problem mit der Portweiterleitung führt.
Wenn ich ein VLAN-Fähigen AP habe, kann ich da darüber die WLAN-Geräte trennen (entsprechende VLANS). Die Fritzbox kommt auch in ein eigenes VLAN.

Am Ende hätte ich meine VLANs 172.16.[1-5].0/24
Fritzbox VLAN 172.16.6.1

Ist das so richtig?

Wuppi68 · 09 April 2019, 16:03:18

am einfachsten ist das Routing folgendermassen:

Fritte:
172.16/12 --> Switch IP (alles aus dem 172.16er Netz werden zum Cisco geschickt)
192.168/16 --> Switch IP (alle 192.168er netze werden auch zum Cisco geschickt - sollte funktionieren)
10/8 --> Switch IP (optional, dann werden quasi alle privaten Netze an den Switch geschickt)

Cisco Interfaces:
172.16.1.1/24 VLAN1
172.16.2.1/24 VLAN2
172.16.3.1/24 VLAN3
...
172.16.255.1/24 VLAN254

192.168.1.1/24 VLAN512
...
192.168.255.1/24 VLAN786

wenn Du auch ein "Gastnetz" hast, dann kannst Du auch LAN-4 von der Fritte auf den Switch stecken und den Port dann Access Untagged GastVLAN einstellen

Die Fritzbox würde ich ganz normal im VLAN1 belassen - mach die Sache nur komplizierter

Eher macht es Sinn, den Zugriff auf den Switch via ACL einzuschränken ...

Vorschlag:
Management IP 172.16.1.1
Allow from VLAN1 443,22 Destination 172.16.1.1
Deny * Destination 172.16.1.1

Damit wäre NUR HTTPS (443)und SSH (22) via Netz auf den Switch möglich

Wenn Du das einstellst, solltest Du notfalls via Konsolenkabel Zugriff haben

Tante Edit hat die Subnet Masken korrigiert

helmut · 09 April 2019, 19:44:57

Zitat von: Wuppi68 am 09 April 2019, 16:03:18
am einfachsten ist das Routing folgendermassen:

Fritte:
172.16/24 --> Switch IP (alles aus dem 172.16er Netz werden zum Cisco geschickt)
192.168/24 --> Switch IP (alle 192.168er netze werden auch zum Cisco geschickt - sollte funktionieren)

Einspruch: Die privaten 172er und 192er Netze haben die Netzmasken 12 und 16.
In diesem speziellen Fall hiesse das 172.16.0.0/16 und 192.168.0.0/16.

Gruss Helmut

Wuppi68 · 09 April 2019, 21:48:48

Zitat von: helmut am 09 April 2019, 19:44:57
Einspruch: Die privaten 172er und 192er Netze haben die Netzmasken 12 und 16.
In diesem speziellen Fall hiesse das 172.16.0.0/16 und 192.168.0.0/16.

Gruss Helmut

hatte mich da vertippt

Die Netzmasken hatten wir ja schon weiter oben

Danke für den Hinweis - habe es korrigiert

darkness · 10 April 2019, 06:19:43

So, wieder etwas weiter

VLAN und SSH läuft jetzt. Das Problem war wirklich die Fritzbox. Da der Pi in der Geräteübersicht bereits mit der Adresse 192.168.178.2 (GI10) vorhanden war, konnte ich kein Portforwarding auf die 172.16.1.1 anlegen. Jetzthabe ich einfach ein Portforwarding auf die 172.16.1.25 angelegt und anschließend die IP dem PI zusätzlich zugewiesen. Nun läuft es.

darkness · 10 April 2019, 06:24:36

ZitatDie Fritzbox würde ich ganz normal im VLAN1 belassen - mach die Sache nur komplizierter

Eher macht es Sinn, den Zugriff auf den Switch via ACL einzuschränken ...

Vorschlag:
Management IP 172.16.1.1
Allow from VLAN1 443,22 Destination 172.16.1.1
Deny * Destination 172.16.1.1

Ok, die ACLs kommen jetzt als nächstes dran. Wenn ich das richtig sehe, können die VLAN munter untereinander kommunizieren. Also trenne ich die untereinander ab und erlaube nur den Zugriff auf den PI(DNS) und die Fritte, sowie die Dienste, welche benötigt werden?

helmut · 10 April 2019, 09:02:59

Zitat von: Wuppi68 am 09 April 2019, 21:48:48
hatte mich da vertippt

Das dachte ich mir und wollte nur den Frustfaktor bei darkness herabsetzen, besser ganz vermeiden.

Gruss Helmut

darkness · 10 April 2019, 10:25:43

Zitat von: helmut am 10 April 2019, 09:02:59

Das dachte ich mir und wollte nur den Frustfaktor bei darkness herabsetzen, besser ganz vermeiden.

Gruss Helmut

Hey hey, ganz so schlimm ist es bei mir dann doch nicht (auch wenn der Eindruck entstehen könnte)

Wuppi68 · 10 April 2019, 11:40:59

Zitat von: darkness am 10 April 2019, 06:24:36
Ok, die ACLs kommen jetzt als nächstes dran. Wenn ich das richtig sehe, können die VLAN munter untereinander kommunizieren. Also trenne ich die untereinander ab und erlaube nur den Zugriff auf den PI(DNS) und die Fritte, sowie die Dienste, welche benötigt werden?

Vergiss bitte nicht auch die DHCP Freigabe ... bei der ACL und dann auch den DHCP (IP) helper entsprechend einzurichten

darkness · 10 April 2019, 12:04:12

Du sprichst von UDP Relay/IP Helper?

Ist es eigentlich richtig, das VLANs untereinander kommunizieren können?

Also ein Client aus VLAN 10 kann einen Client aus VLAN 20 erreichen. (Der jeweilige Port ist nur einen VLAN zugeordent).
Ich hatte es so verstanden, das diese sicher per Default nicht erreichen können?

Wuppi68 · 10 April 2019, 18:03:25

Zitat von: darkness am 10 April 2019, 12:04:12
Du sprichst von UDP Relay/IP Helper?

Ist es eigentlich richtig, das VLANs untereinander kommunizieren können?

Also ein Client aus VLAN 10 kann einen Client aus VLAN 20 erreichen. (Der jeweilige Port ist nur einen VLAN zugeordent).
Ich hatte es so verstanden, das diese sicher per Default nicht erreichen können?

Yup, der UDP Relay Helper (kannst Du global für alle VLANs setzen) (bei Problemen könnte auf der Konsole ein debug ip dhcp ... helfen - zumindest auf "normalen" Routern)

Auf Layer 2 (Switching) können VL10 und VL20 sich definitiv nicht sehen, wenn dann auf Layer 3 (Routing)

Du hast bestimmt Global das Routing eingeschaltet

Also routed er alles was er kennt ... und kann dann wiederum nur mit ACLs verhindert werden

darkness · 10 April 2019, 19:50:33

Zitat von: Wuppi68 am 10 April 2019, 18:03:25
Du hast bestimmt Global das Routing eingeschaltet Also routed er alles was er kennt

So ein Lümmel...

Ok, macht Sinn.

Alternativ wäre das globale Routing aus und alles individuell machen? Dann sind die ACLs wahrscheinlich einfacher

Wuppi68 · 10 April 2019, 20:56:16

Zitat von: darkness am 10 April 2019, 19:50:33
So ein Lümmel... Ok, macht Sinn.

Alternativ wäre das globale Routing aus und alles individuell machen? Dann sind die ACLs wahrscheinlich einfacher

Naja, es geht nur mit ACL's .... VRF kann der bestimmt nicht und wenn dann eine Route bekannt ist wird diese auch genutzt ....

Wie Du siehst, es ist ein spannendes Projekt mit einer vermutlich mega Lernkurve ... jetzt brauchst Du den Switch eigentlich nicht mehr zu booten - wenn Du ACLs einstellst, solltest Du "immer" einen Konsole Zugang haben, oder dieses via Konsole mache und vor dem setzen der ACL einen reload in 00:10 (10 Minuten machen) .... hat es funktioniert reload cancel ansonsten die Zeit abwarten

Und nicht vergessen - die Konfiguration muss explizit gespeichert werden (wr mem) sonst ist beim Neustart alles weg

Legst Du die DHCP Pools auch auf den Switch um?

darkness · 11 April 2019, 08:34:05

Zitat von: Wuppi68 am 10 April 2019, 20:56:16
Legst Du die DHCP Pools auch auf den Switch um?

Habe ich schon. DHCP macht nur noch der Switch. Hatte du mir schon mal als Tipp gegeben, da es dann etwas leichter wird.

Die Lernkurve... ja, fühlt sich manchmal eher wie eine Lernrutsche an. Immer wenn ich denke etwas im Ansatz zu verstehen, ist es wieder ganz anders. Aber es hat ja auch seinen Grund, dass es Leute gibt die sowas lange lernen...

Eine Frage zum VLAN 1 default habe ich. Das VLAN1 scheint ja ein bisschen der Buhmann zu sein

Ich habe noch Geräte im VLAN 1 (zb. der PiHole).
Wenn ich es richtig verstanden habe, sollen keine Geräte im VLAN1 sein. Außerdem verwende ich auch noch Native VLAN 1 in den Porteinstellungen.

Ich habe es jetzt so verstanden, dass das Native VLAN alles auffängt, was ohne VLAN-Tag am Port ankommt und es eben in dieses VLAN packt. Soweit richtig?

Zum testen habe ich mir mal ein SG250 dazu geholt. Am SG350 habe ich auch ein Trunk-Port eingerichtet, der VLAN 40+50 Tagged und Native VLAN1 ist. Ebenso der GI1 am SG250.

VLAN40 ist mein Zocken-LAN.

Kann ich denn jetzt das Native VLAN auch auf 40 setzen? Nur ist dann der SG250 nicht mehr erreichbar (Adminoberfläche, hat eine IP aus dem 172.16.1 Netz). Oder brauche ich das Native VLAN auch, um die Switchverwaltung durchzuführen?