danielmayeragain
Neuling
- Mitglied seit
- 21.03.2026
- Beiträge
- 10
Tatsächlich ganz gut, um die Fragen der Nachbarn, warum man 5 WLAN-Netze hat, einzudämmen
Danke für den Tipp
Danke für den TippSetup VLANs (vor allem für 2 WLANs)?
- Ersteller besterino
- Erstellt am
underclocker2k4
Mr. Alzheimer
4k VLANs = 4k SSIDs = hochvariable Zeichen im Namen = maximal scrollen bei der WLAN-Auswahl, auch für die anderen
In diesem Fall nur WPA oder WPA2, dennoch sehr nützlich. Da kommen mehrere VLANs mit unterschiedlichen Passwörtern unter einem SSID unter.
besterino
Legende
Kommt drauf an: wenn die Separation rein "in Software" funktioniert, hättest Du evtl. weniger Probleme mit überlappenden Funkkanälen - gerade in "eng besiedelten" Gebieten? Hab aber keine Ahnung, ob das technisch so funktioniert.
Wenn Du (herkömmlich) per SSID trennst, dann erhöht das die Anzahl der Kanäle auch nicht. Du hast nur mehr SSIDs.
Die APs können je nach Ausführung 4 oder 8 SSIDs. Mit PPSK hast Du weniger SSIDs, oder kannst beim testen zwischen Netzen einfacher springen, weil weniger Angaben erforderlich sind. Oder eben auch "getarnte" Gast-WLANs: nur eine SSID sichtbar... "geb mal Dein WLAN PW" ... Client landet im (VPN) Gast WLAN.
Ich meine mit vielen virtuellen ssids bricht irgendwann die airtime zusammen. Da kommt es eigentlich ganz cool mit einer ssid und einigen vlans dahinter.
Will ich schon lange umsetzen aber die Familie denkt sich immer neues aus was mich davon abhält.
Will ich schon lange umsetzen aber die Familie denkt sich immer neues aus was mich davon abhält.
tar
Enthusiast
- Mitglied seit
- 30.11.2013
- Beiträge
- 621
Mal etwas more sophisticated mit LANCOM:
Routersettings: VLAN+IP wird mittels DHCP und MAC zugewiesen
Access Point: mittels LEPS und MAC wird das VLAN zugewiesen (IP dann mittels DHCP und MAC vom Router gezogen)
Den Multicast nicht vergessen, damit man mit manchen IoT-Geräten im anderen VLAN auch kommunizieren kann:
Tricky ist der Switch. Hier braucht es Trunk und Gedöns.
Routersettings: VLAN+IP wird mittels DHCP und MAC zugewiesen
Access Point: mittels LEPS und MAC wird das VLAN zugewiesen (IP dann mittels DHCP und MAC vom Router gezogen)
Den Multicast nicht vergessen, damit man mit manchen IoT-Geräten im anderen VLAN auch kommunizieren kann:
Tricky ist der Switch. Hier braucht es Trunk und Gedöns.
Dann bitte auch erwähnen, das sich LANcom jede Menge Features extra bezahlen lässt, wie z.B. pro VPN Client um die 100 Euro. Wenn man im Business Umfeld dann auch die Anwendung dafür hat, mag das gerechtfertigt sein, fürs HomeLab wird das keiner Ausgeben wollen.
Wenn ich dürfte, könnte ich auch unsere ISE jetzt posten, da geht noch mal 10x mehr als Lancom und Co. Da hab ich ua. KI gestützte Mikrosegmentierung per Applikation, aber für den SoHo User und Heimnetzenthusiasten sind solche Lösungen nicht zielführend.
tar
Enthusiast
- Mitglied seit
- 30.11.2013
- Beiträge
- 621
Ich nutze zwar keinen VPN, aber soweit ich weiß, muss man nicht den "LANCOM Advanced VPN Client" als Einzellizenz nutzen, sondern kann die in Windows, iOS oder Android integrierten VPN-Clients (via IKEv2/IPSec) nutzen. Wenn der LANCOM-Router auf einer aktuellen LCOS-Version (ab 10.80) läuft, unterstützt er nativ das kostenfreie Wireguard.
besterino
Legende
Bräuchte nochmal eine Hardware-Empfehlung von Euch, bevor ich den nächsten Fehlkauf zurückschicken muss.
Jetzt gehts um einen Switch, konkret als zentralen Switch im Keller.
Anforderungen:
48x 1Gbit RJ45
min 4x SFP+
min 6x POE+
Webmanaged/VLAN-fähig
Möglichst leise
Möglichst niedriger Stromverbrauch
Von den RJ45-Ports werden ca. 35 Ports belegt. Von den SFP+ alle 4.
Über POE sollen zunächst befeuert werden:
4x UAC-AP-Pro (je max 9W)
1x Mikrotik CSS610 (max 11W)
1x Mikrotik CSS326 (max 19W)
Perspektivisch vielleicht auch irgendwann mal die ein oder andere Kamera?
Ich würde wohl die eher jüngeren chinesischen Hersteller ausschließen, was dann bei Geizhals folgendes ergibt:
So Preis-Leistung find ich ja den Allnet ganz attraktiv mit seinen 6 SFP+ Ports und 800W max PoE-Power für knapp unter 600 Euro (mit Oster-Gutschein). Hatte schonmal nen unmanaged Allnet, der völlig unauffällig war. Kenne aber das Webinterface nicht. Und 800W brauch ich natürlich vorne und hinten nicht.
Der Aruba 1930 hat nur 4 SFP+, käme etwas teurer und hätte „nur“ 370W für PoE. Bei dem kenne ich aber das Webinterface.
Zyxel gäbs auch noch, genauso wie TPlink oder Edimax uvm… hat einer von Euch einen davon? Empfehlungen?
Jetzt gehts um einen Switch, konkret als zentralen Switch im Keller.
Anforderungen:
48x 1Gbit RJ45
min 4x SFP+
min 6x POE+
Webmanaged/VLAN-fähig
Möglichst leise
Möglichst niedriger Stromverbrauch
Von den RJ45-Ports werden ca. 35 Ports belegt. Von den SFP+ alle 4.
Über POE sollen zunächst befeuert werden:
4x UAC-AP-Pro (je max 9W)
1x Mikrotik CSS610 (max 11W)
1x Mikrotik CSS326 (max 19W)
Perspektivisch vielleicht auch irgendwann mal die ein oder andere Kamera?
Ich würde wohl die eher jüngeren chinesischen Hersteller ausschließen, was dann bei Geizhals folgendes ergibt:
So Preis-Leistung find ich ja den Allnet ganz attraktiv mit seinen 6 SFP+ Ports und 800W max PoE-Power für knapp unter 600 Euro (mit Oster-Gutschein). Hatte schonmal nen unmanaged Allnet, der völlig unauffällig war. Kenne aber das Webinterface nicht. Und 800W brauch ich natürlich vorne und hinten nicht.
Der Aruba 1930 hat nur 4 SFP+, käme etwas teurer und hätte „nur“ 370W für PoE. Bei dem kenne ich aber das Webinterface.
Zyxel gäbs auch noch, genauso wie TPlink oder Edimax uvm… hat einer von Euch einen davon? Empfehlungen?
besterino
Legende
@sch4kal: ist bestellt. Wehe der taugt nicht, frisst zu viel Strom oder ist zu laut. 
Ansonsten: Firewalls sind 'ne Pest. Bin gerade dabei mal vom offenen Scheunentor die Dinge zu schließen.
Auf manche Dinge kommt man dann auch erst "on the go". Zum Beispiel sich ein Alias anzulegen, dass alle Subnetz bündelt, mit dem man dann rumspielen kann. Beispiel: Ich hab nun ein alias "VLANs" in dem alle Netzwerke aller VLANs eingetragen sind, also z.B. 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 usw.
Dann hab ich in der Firewall für jedes VLAN-Interface (OPT1, OPT2, OPT3, usw.) ganz unten in den Regeln einmal eine Standardregel:
BLOCK-->Any Protocol --> Any Sources / Any Ports-->VLAN / Any Ports
Und bei denen die ins Internet dürfen noch eine weitere:
ALLOW--> Any Protocol --> VLAN Subnet / Any Ports --> Any Destination / Any Ports
Alles was davon abweicht (z.B. bestimmte Maschinen die doch in eines der VLANs dürfen), muss also da drüber stehen. Hab ich also z.B. bestimmte Clients die aus einem VLAN ins Management VLAN dürfen sollen, muss es da vorher eine Regel für geben.
Eine besondere Pest war es noch, Airplay über zwei VLANs zum Laufen zu bekommen. Erstmal also avahi aus den Packages installieren. Damit ist es aber leider nicht getan. Erstmal muss man natürlich den Haken für den Daemon setzen, die Interfaces markieren, in denen sich alle relevanten Geräte befinden (also alle "Clients" und alle "Abspielgeräte") und den Haken für "repeat mdns packets across subnets" setzen:
Soweit so gut. Dann muss man aber noch zwei manuelle Regeln setzen (so zumindest mein aktueller Stand):
1. im VLAN des Abspielgeräts (in meinem Fall OPT5):
WICHTIG: Unter Extra Options --> Advanced Options...
...den Haken bei "Allow packet with IP options to pass." setzen!
2. Im VLAN der Clients (Smartphones & Co.) muss man dann ggf. auch noch den Zugriff auf das Gerät erlauben (jedenfalls wenn man z.B. wie ich oben den Zugriff von einem VLAN ins andere standardmäßig blockiert):
Sonst klappt's nicht mit den "Nachbarn".
Teamspeak ist schon in die neue DMZ umgezogen und der Fileserver in weiteres VLAN und SMB sehr selektiv für die Maschinen, die's brauchen, freigegeben.
Ansonsten: Firewalls sind 'ne Pest.
Bin gerade dabei mal vom offenen Scheunentor die Dinge zu schließen.Auf manche Dinge kommt man dann auch erst "on the go". Zum Beispiel sich ein Alias anzulegen, dass alle Subnetz bündelt, mit dem man dann rumspielen kann. Beispiel: Ich hab nun ein alias "VLANs" in dem alle Netzwerke aller VLANs eingetragen sind, also z.B. 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 usw.
Dann hab ich in der Firewall für jedes VLAN-Interface (OPT1, OPT2, OPT3, usw.) ganz unten in den Regeln einmal eine Standardregel:
BLOCK-->Any Protocol --> Any Sources / Any Ports-->VLAN / Any Ports
Und bei denen die ins Internet dürfen noch eine weitere:
ALLOW--> Any Protocol --> VLAN Subnet / Any Ports --> Any Destination / Any Ports
Alles was davon abweicht (z.B. bestimmte Maschinen die doch in eines der VLANs dürfen), muss also da drüber stehen. Hab ich also z.B. bestimmte Clients die aus einem VLAN ins Management VLAN dürfen sollen, muss es da vorher eine Regel für geben.
Eine besondere Pest war es noch, Airplay über zwei VLANs zum Laufen zu bekommen. Erstmal also avahi aus den Packages installieren. Damit ist es aber leider nicht getan. Erstmal muss man natürlich den Haken für den Daemon setzen, die Interfaces markieren, in denen sich alle relevanten Geräte befinden (also alle "Clients" und alle "Abspielgeräte") und den Haken für "repeat mdns packets across subnets" setzen:
Soweit so gut. Dann muss man aber noch zwei manuelle Regeln setzen (so zumindest mein aktueller Stand):
1. im VLAN des Abspielgeräts (in meinem Fall OPT5):
WICHTIG: Unter Extra Options --> Advanced Options...
2. Im VLAN der Clients (Smartphones & Co.) muss man dann ggf. auch noch den Zugriff auf das Gerät erlauben (jedenfalls wenn man z.B. wie ich oben den Zugriff von einem VLAN ins andere standardmäßig blockiert):
Sonst klappt's nicht mit den "Nachbarn".
Teamspeak ist schon in die neue DMZ umgezogen und der Fileserver in weiteres VLAN und SMB sehr selektiv für die Maschinen, die's brauchen, freigegeben.
Video für die Basics.
besterino
Legende
Wieder eine Bestätigung, warum ich Videos hasse.
EDIT & Nachtrag: Nachdem mir meine (Windows) VM mit dem Unifi OS Server ohne Backup abgeraucht ist (jajaja, das Backup war zu alt und meine ganze unifi Config natürlich noch nicht drin), habe ich den Rest des Abends damit verbra(u)cht, den Unifi OS Server in einer dedizierten Linux-VM neu aufzusetzen, die APs wieder einzuhängen und die Netzkonfig (mit den VLANs) wieder aufzusetzen. Nachdem der Drecks OS Server wieder lief*, ging das sogar erstaunlich schnell.
*Ich konnte mich ums verrecken nicht mit meinem urspr. Unifi Account anmelden, sondern musste einen neuen Anlegen - erst dann ging's. Bis ich das aber heraus hatte, habe ich natürlich ewig Zeit mit der Fehlersuche in der Firewall verplempert...
EDIT & Nachtrag: Nachdem mir meine (Windows) VM mit dem Unifi OS Server ohne Backup abgeraucht ist (jajaja, das Backup war zu alt und meine ganze unifi Config natürlich noch nicht drin), habe ich den Rest des Abends damit verbra(u)cht, den Unifi OS Server in einer dedizierten Linux-VM neu aufzusetzen, die APs wieder einzuhängen und die Netzkonfig (mit den VLANs) wieder aufzusetzen. Nachdem der Drecks OS Server wieder lief*, ging das sogar erstaunlich schnell.
*Ich konnte mich ums verrecken nicht mit meinem urspr. Unifi Account anmelden, sondern musste einen neuen Anlegen - erst dann ging's. Bis ich das aber heraus hatte, habe ich natürlich ewig Zeit mit der Fehlersuche in der Firewall verplempert...
Zuletzt bearbeitet:
Zu Post #77:
Würde da eher in jedem VLAN eine Regel block !RFC_1918 setzen, die raus kommen sollen sollen, aber nicht untereinander telefonieren dürfen. Der RFC_1918 Alias sieht so aus:
Die Regeln dazu dann so:
Das ! invertiert die Regel. Per default können die VLANs ja eh nicht miteinander reden. Hier im Beispiel darf der CoPilot raus, sowie zum Dongle- und zum Trash Server telefonieren. Sonst nirgends hin. Wär ja noch schöner, wenn meine bekifften Kollegen Zugriff aufs LAN hätten. Einen "alle meine eigenen VLANs" Alias brauchte ich bislang tatsächlich noch nicht.
Die Weisheit stammt übrigens nicht von mir, das hat mir auch mal ein netter Kollege vom OPNsense Forum so vertickert.
Würde da eher in jedem VLAN eine Regel block !RFC_1918 setzen, die raus kommen sollen sollen, aber nicht untereinander telefonieren dürfen. Der RFC_1918 Alias sieht so aus:
Die Regeln dazu dann so:
Das ! invertiert die Regel. Per default können die VLANs ja eh nicht miteinander reden. Hier im Beispiel darf der CoPilot raus, sowie zum Dongle- und zum Trash Server telefonieren. Sonst nirgends hin. Wär ja noch schöner, wenn meine bekifften Kollegen Zugriff aufs LAN hätten. Einen "alle meine eigenen VLANs" Alias brauchte ich bislang tatsächlich noch nicht.
Die Weisheit stammt übrigens nicht von mir, das hat mir auch mal ein netter Kollege vom OPNsense Forum so vertickert.
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Naja, man kanns auch übertreiben.
Wenn ich nur private Class C nutze, dann brauche ich keine Regel für Class B und A.
Es tut dann auch einfach eine Class C deny Regel und gut ist.
Ansonsten ist es auch reichlich dämlich eine deny Regel via eine allow Regel mit einem reverse Netzbereich anzulegen.
Was da steht ist: "erlaube alles, was nicht IANA private ist"
Das ist also die Negation (erlauben, obwohl man ja eigentlich was verbieten will) der Negation (erlaube alle anderen Netze, obwohl man seine Netze verbieten mag).
Ich weiß daher nicht wirklich, wer da der bekiffte Kollege wirklich ist, der Pilot oder der, der das Netzwerk gemacht hat...
Normalerweise macht man das einfach so:
deny 192.168.0.0/16 (wenn man nur Class C nutzt, was die meisten machen)
Damit sieht man auf den ersten Blick, es wird etwas geblockt und es ist der eigene, komplette lokale Netzbereich, bzw. sogar Remote, wenn man S2S VPN macht.
Negation der Negation macht in ausgewählten Bereichen schon Sinn, hier aber explizit nicht.
Wenn ich nur private Class C nutze, dann brauche ich keine Regel für Class B und A.
Es tut dann auch einfach eine Class C deny Regel und gut ist.
Ansonsten ist es auch reichlich dämlich eine deny Regel via eine allow Regel mit einem reverse Netzbereich anzulegen.
Was da steht ist: "erlaube alles, was nicht IANA private ist"
Das ist also die Negation (erlauben, obwohl man ja eigentlich was verbieten will) der Negation (erlaube alle anderen Netze, obwohl man seine Netze verbieten mag).
Ich weiß daher nicht wirklich, wer da der bekiffte Kollege wirklich ist, der Pilot oder der, der das Netzwerk gemacht hat...
Normalerweise macht man das einfach so:
deny 192.168.0.0/16 (wenn man nur Class C nutzt, was die meisten machen)
Damit sieht man auf den ersten Blick, es wird etwas geblockt und es ist der eigene, komplette lokale Netzbereich, bzw. sogar Remote, wenn man S2S VPN macht.
Negation der Negation macht in ausgewählten Bereichen schon Sinn, hier aber explizit nicht.
underclocker2k4
Mr. Alzheimer
Ne Firewall verhält sich wie ne Firewall.
Da ist OPNsense nichts anderes.
Wenn das also da usus ist, dann müsste das ja woanders auch usus sein. Ist es aber nicht...
Dann gilt für dich eben nur 10er und kein 172er und kein 192er.
Und bevor dann einer kommt:
Wer 172er hat, macht dann 172er und kein 10er und kein 192er.
Ist eigentlich extrem einfach die Logik, und die lautet: Man nimmt den Netzbereich, den man hat, unabhängig von der konkreten Ausprägung.
Spannend wird es, wenn man kein RFC1918 nutzt, dann ist das plötzlich nicht mehr mit OPNsense machbar? (ich glaube nicht)
Da ist OPNsense nichts anderes.
Wenn das also da usus ist, dann müsste das ja woanders auch usus sein. Ist es aber nicht...
Beitrag automatisch zusammengeführt:
Das muss man dann natürlich anpassen. (mitdenken wird schon vorausgesetzt, hatte ich ja geschrieben, vgl. "wenn man nur Class C nutzt, was die meisten machen")
Dann gilt für dich eben nur 10er und kein 172er und kein 192er.
Und bevor dann einer kommt:
Wer 172er hat, macht dann 172er und kein 10er und kein 192er.
Ist eigentlich extrem einfach die Logik, und die lautet: Man nimmt den Netzbereich, den man hat, unabhängig von der konkreten Ausprägung.
Spannend wird es, wenn man kein RFC1918 nutzt, dann ist das plötzlich nicht mehr mit OPNsense machbar? (ich glaube nicht)
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Halte ich für extrem gefährlich, wenn man Firewallregeln macht, so zumindest meine fachliche Sicht darauf.
Das Problem ist die falsche Beschreibung der Regel!
In seinem Screenshot ist es eine Erlauben-Regel und die ist soweit ok.
Beitrag automatisch zusammengeführt:
Zu viel bla bla? Für die Basics empfehle ich trotzdem, sich mal die Zeit zu nehmen, auch wenn es manchem schwer fällt.
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Das ist das Problem, wenn man die Negation der Negation macht.
Mathematisch ist "-" * "-" halt plus. Im Sprachgebrauch nimmt man aber einfach direkt +.
Und so ist das auch hier. Man meint etwas, kann es aber nicht richtig ausdrücken, weil alles auf dem Kopf steht.
Ist bei Firewallregeln ein denkbar schlechtes Vorgehen, besonders, wenn man das kommunikativ nutzt.
Zuletzt bearbeitet:
Wenn ich die Regel ausspreche, heisst das für mich:
Sehe da beim besten Willen keine doppelte Negation.
Die Regel verbietet auch nichts, dafür ist eine andere Standardregel da. Sie schliesst halt was aus.
Das stimmt, war unglücklich ausgedrückt.
Zuletzt bearbeitet:
underclocker2k4
Mr. Alzheimer
Was willst du denn erreichen?
Doch, dass er nicht nach 192.168.0.0/16 sprechen darf, oder?
Denn du willst ihn von deinem Netz fernhalten.
Ich verbiete 192.168.0.0/16 ist die direkte Aussage.
Ich erlaube nicht 192.168.0.0/16 ist die Negation der Negation.
Die erste Negation ist "erlauben" statt "verbieten"
Die zweite Negation ist "nicht 192.168.0.0/16" statt "192.168.0.0/16".
Am Ende ist die zweite Formulierung "-"*"-"=+
Mathematisch und in der Funktion korrekt, schön ist dennoch anders.
Dein Ziel ist vorrangig nicht, dass du im Internetzugang gewähren willst.
192.168.0.0/16 als Beispiel.
EDIT:
Von erlaube alles steht da aber nichts.
Du hast:
1. Erlaube Host (vermutlich Spielserver)
2. Erlaube Dongleserver
3. Erlaube nicht RFC1918 Netze
Normal macht man das bei einer Firewall so.
Zu erst kommen die Kommunikationen, die erlaubt sind.
Dann kommen die, die verboten sind, bzw. eine alles verboten.
Alles verboten heißt in deinem Kontext deine privaten Netze.
Solange die Firewall nicht invers arbeitet und das tut keine, ist immer alles erlaubt und man stellt eigentlich nur Verbote ein.
Eine Firewall ist ohne Regeln erstmal ein Router/Switch und sonst nichts. Per default ist da alles erlaubt,bzw. nichts verboten.
Du hast aber kein verboten bei dir, sondern nur erlauben.
Und das letzte Erlauben (obwohl verboten gemeint ist) ist dann die negierten eigenen Netze.
Richtig wäre:
1. Erlaube Host (vermutlich Spielserver)
2. Erlaube Dongleserver
3. Verbiete RFC1918 Netze
Die Firewall arbeitet so, dass sie sich das Paket anschaut, was gerade reinkommt und dann der Reihe der Einträge folgend entscheidend.
1. passt? OK, dann erlauben; passt nicht? dann weiter
2. passt? OK, dann erlauben; passt nicht? dann weiter
3. passt? nein, drop
Die letzte Regel ist die, wo alles reinpasst, was vorher nicht gepasst hat.
Wenn man es dann ganz richtig machen will, macht man nach der 3. Regel ein:
allow 0.0.0.0/0
Dann darf er
1. erlaube Spieleserver
2. erlaube Dongleserver
3. nicht zu den (anderen) internen Systemen
4. erlaube Internet
Dann darf er aber eben auch ins Internet und kann dort auch p*rn laden.
Das letzte ist dann in dem Fall redundant (das darf er dann eh immer), sorgt aber dafür, dass die Kommunikation wenigstens auftaucht, im Firewalllog.
Ob du also alles erlauben willst, müsste man sich nochmal fragen. Also auch Internet?
Aktuell sehe ich das so.
Du willst aktuell haben
1. Spieleserver
2. Dongleserver
3. keine anderen eigenen Systeme
Doch, dass er nicht nach 192.168.0.0/16 sprechen darf, oder?
Denn du willst ihn von deinem Netz fernhalten.
Ich verbiete 192.168.0.0/16 ist die direkte Aussage.
Ich erlaube nicht 192.168.0.0/16 ist die Negation der Negation.
Die erste Negation ist "erlauben" statt "verbieten"
Die zweite Negation ist "nicht 192.168.0.0/16" statt "192.168.0.0/16".
Am Ende ist die zweite Formulierung "-"*"-"=+
Mathematisch und in der Funktion korrekt, schön ist dennoch anders.
Dein Ziel ist vorrangig nicht, dass du im Internetzugang gewähren willst.
192.168.0.0/16 als Beispiel.
EDIT:
Das ist das, was erreichen willst.
Von erlaube alles steht da aber nichts.
Du hast:
1. Erlaube Host (vermutlich Spielserver)
2. Erlaube Dongleserver
3. Erlaube nicht RFC1918 Netze
Normal macht man das bei einer Firewall so.
Zu erst kommen die Kommunikationen, die erlaubt sind.
Dann kommen die, die verboten sind, bzw. eine alles verboten.
Alles verboten heißt in deinem Kontext deine privaten Netze.
Solange die Firewall nicht invers arbeitet und das tut keine, ist immer alles erlaubt und man stellt eigentlich nur Verbote ein.
Eine Firewall ist ohne Regeln erstmal ein Router/Switch und sonst nichts. Per default ist da alles erlaubt,bzw. nichts verboten.
Du hast aber kein verboten bei dir, sondern nur erlauben.
Und das letzte Erlauben (obwohl verboten gemeint ist) ist dann die negierten eigenen Netze.
Richtig wäre:
1. Erlaube Host (vermutlich Spielserver)
2. Erlaube Dongleserver
3. Verbiete RFC1918 Netze
Die Firewall arbeitet so, dass sie sich das Paket anschaut, was gerade reinkommt und dann der Reihe der Einträge folgend entscheidend.
1. passt? OK, dann erlauben; passt nicht? dann weiter
2. passt? OK, dann erlauben; passt nicht? dann weiter
3. passt? nein, drop
Die letzte Regel ist die, wo alles reinpasst, was vorher nicht gepasst hat.
Wenn man es dann ganz richtig machen will, macht man nach der 3. Regel ein:
allow 0.0.0.0/0
Dann darf er
1. erlaube Spieleserver
2. erlaube Dongleserver
3. nicht zu den (anderen) internen Systemen
4. erlaube Internet
Dann darf er aber eben auch ins Internet und kann dort auch p*rn laden.
Das letzte ist dann in dem Fall redundant (das darf er dann eh immer), sorgt aber dafür, dass die Kommunikation wenigstens auftaucht, im Firewalllog.
Ob du also alles erlauben willst, müsste man sich nochmal fragen. Also auch Internet?
Aktuell sehe ich das so.
Du willst aktuell haben
1. Spieleserver
2. Dongleserver
3. keine anderen eigenen Systeme
Zuletzt bearbeitet:
Das erlauben (die allow Regel) bezieht sich auf "nach draussen telefonieren", wo ich eben explizit nach RFC_1918 ausschliesse.
Nach RFC_1918, bzw. überall hin blocken ist eine andere (Standard-) Regel. Wenn ich jetzt noch eine separate Regel machen würde, "Block alles nach RFC_1918" wäre das eine "doppelte Negation", wie Du sie hier ausdenkst. Glaube aber kaum, dass die Sense daraus ein "ist zweimal geblockt, ich lass das jetzt durch" machen würde.
Und wer sagt Dir, dass jemand nicht Ranges aus 192.168.0.0/16 und 10.0.0.0/8 zusammen nutzt? Macht das nicht auch eine Fritzbox für Gäste WLAN? Finde die Idee nicht mal so abwegig.
Und wie gesagt, die Notation stammt nicht von mir. Aber ich finde das ganz schlüssig so.
Und ja, dass hier der Pilot manchmal bekiffter ist als die Co-Piloten, das mag durchaus sein. Meist übernehme ich deren Job gleich auch noch.
Zuletzt bearbeitet:
