Wie The Social Dork eine OPNsense-Firewall für zu Hause baut

Eva Wong ist die technische Redakteurin und begeisterte Tüftlerin bei ZimaSpace. Als lebenslanger Geek mit einer Leidenschaft für Homelabs und Open-Source-Softwarehat sie sich darauf spezialisiert, komplexe technische Konzepte in verständliche, praxisnahe Anleitungenzu übersetzen. Eva ist überzeugt, dass Self-Hosting Spaß machen sollte und nicht einschüchternd sein darf. Mit ihren Tutorials hilft sie der Community dabei, Hardware-Setups zu durchschauen, vom Bau des ersten NAS bis zum sicheren Umgang mit Docker-Containern.

Vielen Dank an The Social Dork | Cybersicherheit für die Vorstellung eines OPNsense-Heimfirewall-Aufbaus mit ZimaBoard 2. Eine virtuelle Maschine übernimmt Routing und Firewall-Richtlinien, ein Access Point stellt WLAN bereit und Pi-hole filtert DNS-Anfragen für verbundene Clients. Sieh dir die Original-YouTube-Anleitung für die vollständige Demonstration an.

Vor dem Lesen ansehen: Dieses etwa zehnminütige Video ist hilfreich, wenn du dein Netzwerk-Gateway von deinem WLAN-Access-Point trennen möchtest. Der Creator erklärt die Topologie, startet OPNsense in Zima Virtual Machine, weist Schnittstellen und DHCP zu und überprüft anschließend einen WLAN-Laptop und dessen DNS-Filterung.

Der gezeigte Meilenstein ist, dass ein Laptop über die neue Firewall das Netzwerk erreicht und den ausgewählten DNS-Filter nutzt. Das Video zeigt den Ablauf für den ersten Client. Die einleitende Sorge um anfällige IoT-Geräte würde eine zusätzliche Netzwerktrennung und Zugriffsrichtlinien erfordern. Geräte in ein neues WLAN zu bringen, isoliert sie nicht automatisch voneinander.

Lege fest, welche Funktionen das vorhandene Gateway weiterhin übernehmen muss

Die Topologie unterscheidet drei Funktionen, die ein All-in-one-Router verbergen kann: die Providerverbindung, die geroutete Firewall-Grenze und den WLAN-Zugang. Eine Ethernet-Übergabe kann die neue Firewall versorgen, während bei DSL- oder Kabelanschlüssen weiterhin das passende Modem oder Providergerät benötigt wird. Der Austausch der Routing-Funktion hebt diese physische Verbindungsvoraussetzung nicht auf.

Im funktionierenden Aufbau des Creators ist der vorhandene Heimrouter mit der WAN-Seite der Firewall verbunden, während ein Access Point an deren LAN-Seite angeschlossen ist. Wenn das vorgeschaltete Gateway ebenfalls Netzwerkadressübersetzung durchführt, entsteht doppeltes NAT. Für einen ersten Test ist das akzeptabel, kann aber eingehende Dienste und die Fehlersuche erschweren. Ob der Bridge- oder Passthrough-Modus verfügbar ist, hängt von den Geräten und dem Dienst des Providers ab. Kläre das, bevor du die produktive Verbindung änderst.

Aufgabe Komponente im dargestellten Aufbau Frage, die vor dem Umzug der Clients beantwortet werden muss
Übergabepunkt des Providers Ethernet-Dienst oder das erforderliche Modem/Gateway. Welches Gerät muss für eine funktionierende Verbindung erhalten bleiben?
Routing und Richtlinien OPNsense-VM. Läuft der Client-Datenverkehr tatsächlich über dieses Gateway?
WLAN-Zugang Ein separater Access Point oder eine unterstützte AP-Konfiguration. Bindet es die Clients in das vorgesehene LAN ein?
Adressvergabe Ein DHCP-Dienst für das Client-Netzwerk. Welcher Server stellt Gateway- und DNS-Einstellungen bereit?
DNS-Filterung Pi-hole-Dienst. Können diese Clients den ausgewählten Resolver erreichen?

Notieren Sie vor der Umstellung die aktuellen, vom Anbieter vorgegebenen Einstellungen. Ein Video, das eine Ethernet-Übergabe zeigt, belegt nicht, welche Authentifizierung, VLAN-Konfiguration oder Modemvoraussetzungen Ihr Internetanbieter verlangt. Halten Sie die Konfiguration des alten Gateways während der Tests des neuen Pfads mit einem Client bereit. So können Sie ein Problem mit dem vorgelagerten Dienst von einem Fehler im neuen LAN unterscheiden.

Double NAT bezeichnet zwei geroutete Übersetzungsgrenzen. Das ist etwas anderes als ein nachgelagerter Access Point. Wenn das WLAN-Gerät weiterhin als Router arbeitet, kann es eine zusätzliche Grenze und einen weiteren DHCP-Dienst einführen. Prüfen Sie die tatsächliche Betriebsart und die Kabelverbindungen, statt seine Funktion anhand der Produktbezeichnung auf dem Gehäuse zu bestimmen.

Ordnen Sie die virtuellen Schnittstellen einer echten WAN- und LAN-Grenze zu

The Social Dork lädt ein OPNsense-Installationsimage herunter und startet es in Zima Virtual Machine auf dem ZimaBoard 2. Dies ist eine Demonstration einer virtualisierten Firewall. Auf dem Host läuft weiterhin ZimaOS. Daher gehört auch dessen Netzwerkkonfiguration zum Gesamtkonzept, ebenso wie die OPNsense-Einstellungen innerhalb des Gasts.

Ordnen Sie bei einer ähnlichen Einrichtung jede virtuelle Schnittstelle ausdrücklich dem vorgesehenen physischen Anschluss oder isolierten Hostnetzwerk zu. Ein Paar Netzwerkbuchsen stellt diese Zuordnung nicht automatisch her. Trennen Sie den WAN-seitigen Pfad von gewöhnlichen Hostdiensten und stellen Sie sicher, dass der Datenverkehr der LAN-Clients die Firewall passieren muss, um die vorgelagerte Verbindung zu erreichen. Verfügt ein Client über einen anderen Weg an der VM vorbei, kann die Firewall für diesen Datenverkehr keine Richtlinien durchsetzen.

Konfiguration der WAN- und LAN-Schnittstellen von OPNsense innerhalb der Gateway-VM
Der Ersteller weist die WAN- und LAN-Schnittstellen innerhalb von OPNsense zu. Ordnen Sie diese Gastschnittstellen den vorgesehenen physischen Netzwerkpfaden zu und prüfen Sie ihre Adressen. Videobild bei 5:25, mit freundlicher Genehmigung von The Social Dork.

Verwenden Sie die aktuelle Installationsanleitung für OPNsense und die Anleitung für virtuelle Maschinen für das ausgewählte Image und die Plattform. Halten Sie fest, wie Sie den Host und die VM-Konsole erreichen, bevor Sie Schnittstellen ändern. Ein Neustart des Hosts, ein Speicherproblem oder das Herunterfahren der VM kann dieses Gateway unterbrechen. Planen Sie Wartungsarbeiten daher mit Blick auf die Internetverbindung im Haushalt.

Machen Sie den Schnittstellenplan eindeutig

  1. Identifizieren Sie die physischen Anschlüsse des Hosts und halten Sie fest, welches Kabel zur vorgelagerten Verbindung führt.
  2. Ordnen Sie die WAN-seitige Schnittstelle des Gasts dem vorgesehenen vorgelagerten Netzwerk zu.
  3. Ordnen Sie die LAN-seitige Schnittstelle einem separaten nachgelagerten Netzwerk zu.
  4. Vergewissern Sie sich, dass der Verwaltungszugang und gewöhnliche Hostdienste nicht unbeabsichtigt über die WAN-Seite erreichbar sind.
  5. Schließen Sie einen Test-Client an das nachgelagerte Netzwerk an und prüfen Sie dessen tatsächliches Standardgateway, bevor Sie weitere Geräte hinzufügen.

Ein Schnittstellenname innerhalb des Gasts stimmt möglicherweise nicht mit der Beschriftung neben einem physischen Anschluss überein. Nutze die Netzwerkzuordnung des Hypervisors und die Gastkonsole, um den Zusammenhang zu ermitteln. Überprüfe ihn erneut, wenn du virtuelle Adapter änderst. Das Video zeigt eine funktionierende Konfiguration auf dem Rechner des Erstellers, bietet aber keine vollständige Übersicht über alle Host-Bridges oder Adaptereinstellungen, auf die du möglicherweise stößt.

Weise der Firewall genügend Ressourcen zu und lasse zugleich Kapazität für ZimaOS und die anderen Dienste auf dem Host übrig. Die aktuelle OPNsense-Virtualisierungsanleitung nennt 3 GB RAM als Mindestwert, eine virtuelle Festplatte mit mindestens 8 GB sowie Hinweise zur Netzwerkkompatibilität. Das sind Ausgangswerte, keine Garantie für einen bestimmten Durchsatz. Protokolle, VPNs, Inspektionsfunktionen und andere Workloads können den erforderlichen Spielraum verändern.

Das ist ein betrieblicher Kompromiss, wenn ein Gerät gemeinsam genutzt wird: Ein Update oder Neustart des Hosts kann auch die Gateway-VM außer Betrieb setzen. Lege fest, wie die VM nach dem Booten gestartet wird und wie du sie wiederherstellst, falls sie nicht startet. Ein zuverlässiger Konsolenzugriff ist besonders hilfreich, wenn eine fehlerhafte Netzwerkeinstellung die Weboberfläche unerreichbar macht.

Lass für jedes Client-Netzwerk einen DHCP-Dienst zuständig sein

Der Ersteller verwendet unterschiedliche IPv4-Netze für die Upstream- und Downstream-Seite: Auf der Upstream-Seite kommen 192.168.0.x-Adressen zum Einsatz, im Client-LAN 192.168.1.x-Adressen. Dies sind Beispiele aus dem Video. Wähle nicht überlappende Subnetze, die zu deinem Netzwerk passen, statt Adressen zu übernehmen, die möglicherweise bereits verwendet werden.

Der Access Point stellt die Funkverbindung her, während OPNsense die DHCP-Zuweisungen für die nachgelagerten Clients bereitstellt. In der Anleitung werden der AP-Modus und das Deaktivieren des DHCP-Dienstes des alten WLAN-Routers erläutert. Bei Geräten ohne dedizierten AP-Modus garantiert das alleinige Deaktivieren von DHCP kein transparentes Access-Point-Verhalten: Prüfe die Anforderungen des Herstellers an die LAN-zu-LAN-Verkabelung sowie an Routing und NAT. Stelle sicher, dass die Verwaltungsadresse erreichbar bleibt und nicht mit dem DHCP-Adresspool kollidiert.

OPNsense-Dnsmasq-DNS- und DHCP-Konfiguration im Video
Der Ersteller konfiguriert DHCP für das nachgelagerte Netzwerk. Vergewissere dich, dass ein Dienst die vorgesehene Client-Adresse, das Gateway und den DNS-Resolver bereitstellt. Videobild bei 6:25, mit freundlicher Genehmigung von The Social Dork.

Teste die resultierende DHCP-Zuweisung mit einem Laptop. Er sollte eine Adresse im vorgesehenen LAN, die LAN-Adresse der Firewall als Standardgateway und den vorgesehenen DNS-Server erhalten. Eine erfolgreiche WLAN-Verbindung beweist lediglich, dass die Funkverbindung funktioniert. Anhand der Adresse, des Gateways und des DNS-Resolvers erkennst du, ob der Client tatsächlich in das neue Netzwerk eingebunden wurde.

Feste Adressen und Lease-Pool getrennt planen

Das folgende /24-LAN-Schema dient nur zur Veranschaulichung und ist keine Wiedergabe der genauen Adressen des Erstellers. Passen Sie es an Ihre vorhandenen Netzwerke an. Reservieren Sie feste Infrastrukturadressen außerhalb des dynamisch zugewiesenen Pools und halten Sie das vorgelagerte Netzwerk vom nachgelagerten LAN getrennt.

Element Beispieladresse oder -bereich Grund
OPNsense-LAN-Schnittstelle 192.168.1.1/24 Clients verwenden diese Adresse als Gateway.
Verwaltung des Access Points 192.168.1.2 Ein stabiles Verwaltungsziel außerhalb des Beispielpools.
Erreichbarer Pi-hole-Endpunkt 192.168.1.10 Der in diesem Beispiel an Clients bekanntgegebene DNS-Endpunkt.
DHCP-Pool für Clients 192.168.1.100–192.168.1.199 Ein separater Pool vermeidet Konflikte mit diesen festen Adressen.

Wenn sich Pi-hole tatsächlich in einem anderen Subnetz oder in einem virtuellen Netzwerk auf der Host-Seite befindet, verwenden Sie den tatsächlich erreichbaren Endpunkt sowie das erforderliche Routing und die passenden Richtlinien. Durch die Beispieladresse wird der Dienst nicht automatisch im LAN verfügbar. Ein DHCP-Eintrag teilt Clients mit, wohin sie eine Anfrage senden sollen; er richtet weder die Route ein noch startet er den Server.

Beispiel aus der offiziellen Pi-hole-Dokumentation zu OPNsense-DHCP-Pool und DNS-Server-Feldern
Offizielles OPNsense-Integrationsbeispiel mit DHCP-Adresspool und dem an Clients verteilten DNS-Server. Die Beispieladressen dienen nur zur Veranschaulichung. Quelle: Pi-hole-Dokumentation. Klicken Sie auf das Bild, um es in Originalgröße anzuzeigen.

Prüfen Sie nach einer DHCP-Änderung die Lease auf dem Laptop, statt nur die Konfigurationsseite des Servers zu kontrollieren. Bestätigen Sie die zugewiesene Adresse, Maske, das Gateway und die DNS-Einträge. Ein Client mit einer noch gültigen alten Lease kann eine korrekte neue Einrichtung fehlerhaft erscheinen lassen. Eine unerwartete Adresse oder ein unerwartetes Gateway ist ebenfalls ein Hinweis darauf, dass möglicherweise noch ein weiterer DHCP-Server aktiv ist.

Die erste Zulassungsregel als Verbindungstest behandeln

Der Ersteller beginnt mit einer freizügigen Regel für ausgehenden Datenverkehr des einzelnen Test-Laptops und erläutert, wie unerwünschte Verbindungen vom WAN zum LAN verhindert werden. OPNsense verwendet zustandsbehaftete Filterung, sodass Antworten auf eine erlaubte Verbindung anhand des Verbindungsstatus behandelt werden. Die Dokumentation zu OPNsense-Firewall-Regeln erklärt, wie sich Schnittstelle, Richtung und Regelreihenfolge auf dieses Verhalten auswirken.

OPNsense-Firewall-Regel-Editor während des ersten Verbindungstests
Bei der Anleitung wird eine Firewall-Regel bearbeitet, um die Verbindung des Testclients herzustellen. Prüfen Sie Schnittstelle, Quelle, Ziel und Zweck, bevor Sie die Richtlinie erweitern. Videobild bei 7:40, mit freundlicher Genehmigung von The Social Dork.

Im Video wird außerdem die Weboberfläche aus dem privaten vorgelagerten Netzwerk geöffnet. Beschränke in deiner eigenen Bereitstellung den administrativen Zugriff auf einen vertrauenswürdigen Verwaltungsweg und behalte eine Möglichkeit zur Wiederherstellung über die Konsole bei. Die Bezeichnung WAN beschreibt eine Rolle relativ zu dieser Firewall; ein vorgelagertes privates Labornetzwerk und das öffentliche Internet sind unterschiedliche Bedingungen hinsichtlich der Erreichbarkeit.

Um auf die zu Beginn angesprochene IoT-Frage einzugehen, erstellst du mit geeigneter Ausrüstung separate Netzwerke und legst anschließend fest, welcher Datenverkehr zwischen ihnen zulässig ist. Geräte, die Datenverkehr innerhalb desselben lokalen Segments austauschen, können möglicherweise kommunizieren, ohne die geroutete Firewall zu passieren. Eine weitere praktische Perspektive auf Entscheidungen zu Gateway und Datenschutz bietet der OPNsense-Firewall-Aufbau von cachito labs.

Konnektivität und Isolation getrennt betrachten

Ziel der Richtlinie Was zuerst gegeben sein muss So überprüfst du die Konfiguration
Ein Test-Laptop kann im Internet surfen. Es verwendet das vorgesehene Gateway und den vorgesehenen Resolver. Öffne ein zulässiges Ziel und prüfe den zugehörigen Datenverkehr.
Ein IoT-Netzwerk kann nicht auf ein vertrauenswürdiges LAN zugreifen. Die Geräte befinden sich in separaten gerouteten Netzwerken. Versuche die ausgewählte Verbindung zwischen Netzwerken und prüfe die Richtlinie.
Die Clients verwenden den vorgesehenen DNS-Dienst. Der Resolver ist erreichbar und wird korrekt bekannt gegeben. Gleiche die Anfragen der Clients mit dem Pi-hole-Abfrageprotokoll ab.
Die Administration erfolgt über einen vertrauenswürdigen Zugriffsweg. Der Verwaltungszugriff ist auf die vorgesehenen Quellen beschränkt. Prüfe einen autorisierten Zugriffsweg und behalte die Möglichkeit zur Wiederherstellung über die Konsole bei.

Lege Quelle, Ziel, Protokoll und Zweck fest, bevor du eine Regel hinzufügst. Eine Regel, die belegt, dass ein Laptop auf das Internet zugreifen kann, ist keine Richtlinie für alle Geräte im Haushalt. Für die Segmentierung verwendest du separate Netzwerke und eine Firewall-Verbindung zwischen ihnen. Datenverkehr, der lokal im selben Segment ausgetauscht wird, erreicht möglicherweise gar nicht das Gateway.

Wenn eine Regeländerung scheinbar keine Wirkung zeigt, teste eine neue Verbindung und berücksichtige den Verbindungsstatus. Die Anleitung zu OPNsense-Regeln erklärt die zustandsbehaftete Verarbeitung. Bestehende Verbindungszustände können einen erneuten Test beeinflussen, während das Zurücksetzen aller Zustände andere aktive Verbindungen unterbrechen würde. Ermittle den konkreten Test-Datenverkehr, bevor du eine umfassende Diagnoseänderung vornimmst.

Pi-hole über DHCP einbinden, ohne eine DNS-Schleife zu erzeugen

Gegen Ende stellt The Social Dork den über DHCP bereitgestellten DNS-Server auf die Adresse von Pi-hole ein. Dadurch wird das zuvor erwähnte Pi-hole- und Tailscale-Projekt zur Werbeblockierung in das neue WLAN eingebunden. OPNsense steuert den gerouteten Datenverkehr; Pi-hole wertet die über seinen Dienst angefragten DNS-Namen aus. Die beiden Komponenten haben unterschiedliche Aufgaben.

Dialogfeld für OPNsense-DHCP-Optionen während der Pi-hole-DNS-Konfiguration
Der Schritt mit der DHCP-Option weist die Clients auf den ausgewählten DNS-Dienst hin. Erneuern Sie die Client-Lease und überprüfen Sie den Resolver, statt sich allein auf das gespeicherte Formular zu verlassen. Videobild bei etwa 8:15, mit freundlicher Genehmigung von The Social Dork.

Pi-holes OPNsense-Integrationsleitfaden beschreibt die direkte Verteilung per DHCP und die Weiterleitung über die Firewall als alternative Konfigurationen. Wählen Sie einen einheitlichen Pfad und stellen Sie sicher, dass die Resolver Anfragen nicht in einer Schleife aneinander zurückleiten. Prüfen Sie außerdem, ob die Clients die Pi-hole-Adresse erreichen dürfen, wenn sie sich in einem anderen Netzwerk befindet.

Offizielles Pi-hole-Integrationsbeispiel für Upstream-DNS-Einstellungen in OPNsense
Offizielles Beispiel für OPNsense-DNS-Einstellungen für die hier beschriebene Weiterleitungskonfiguration. Quelle: Pi-hole-Dokumentation. Klicken Sie auf das Bild, um es in Originalgröße anzuzeigen.

Wählen Sie einen Resolver-Pfad und zeichnen Sie ihn vollständig auf

Konfiguration Abfragepfad Was die Protokolle zeigen können
Clients fragen Pi-hole direkt ab. Client → erreichbarer Pi-hole-Endpunkt → ausgewählter Upstream-Resolver. Pi-hole kann Anfragen den Quelladressen zuordnen, von denen sie tatsächlich empfangen werden.
Clients fragen einen weiterleitenden Firewall-Resolver ab. Client → Firewall-Resolver → Pi-hole → unabhängiger Upstream-Pfad. Pi-hole sieht möglicherweise hauptsächlich die weiterleitende Firewall als Quelle.

Im Video wird für die Clients die von DHCP bereitgestellte Pi-hole-Adresse verwendet. Die Weiterleitungskonfiguration im verlinkten offiziellen Leitfaden ist eine Alternative. Wenn Sie diese wählen, stellen Sie sicher, dass Pi-holes Upstream den Request nicht direkt in dieselbe Weiterleitungskette zurücksendet. Ein klarer Pfad erleichtert die Diagnose, wenn keine Antwort eingeht.

DNS hängt auch von Transport und Routing ab. Wenn sich Client und Resolver in verschiedenen Netzwerken befinden, prüfen Sie den Pfad und die entsprechenden TCP-/UDP-Richtlinien für Port 53. Kontrollieren Sie IPv6-DNS-Ankündigungen und unabhängige DNS-Einstellungen des Clients, wenn das beobachtete Ergebnis von der DHCP-Konfiguration abweicht. Der Zugriff auf die Pi-hole-Weboberfläche allein ist kein ausreichender Nachweis.

Für Filterung außerhalb des Heimnetzwerks lesen Sie erneut die begleitende Pi-hole- und Tailscale-Anleitung. Remote-DNS-Zugriff, lokale Gateway-Richtlinien und der gesamte Internetverkehr über ein VPN sind getrennte Entscheidungen. Testen Sie jede davon über die Verbindung, auf der sie tatsächlich verwendet wird.

Überprüfen Sie den gesamten Pfad, bevor Sie alle Geräte umstellen

In der abschließenden Demonstration wird das WLAN des Laptops gewechselt und dieselbe Website mit und ohne Filterkonfiguration verglichen. Sie veranschaulicht den ausgewählten Client-Pfad, beweist aber nicht, dass alle Websites werbefrei sind oder alle Geräte voneinander isoliert sind. Prüfen Sie zuerst den Internetzugang und DNS und sehen Sie sich anschließend die relevanten Firewall- und Pi-hole-Protokolle an, um jedes Ergebnis dem vorgesehenen Client zuzuordnen.

Testen Sie vor der Umstellung des Haushalts die Lease-Erneuerung eines Clients, eine erlaubte Verbindung und, falls die Segmentierung Teil Ihres Designs ist, eine bewusst gesperrte Verbindung zwischen getrennten Netzwerken. Exportieren Sie eine funktionierende Firewall-Konfiguration und prüfen Sie den Wiederherstellungsweg. Das Ziel ist ein Gateway, dessen Routing, DHCP, Filterung und Verwaltung Sie erklären und warten können. Im vollständigen OPNsense-Leitfaden für die Heim-Firewall von The Social Dork sehen Sie die ursprüngliche Topologie und die Einrichtungsabfolge.

Führen Sie einen schrittweisen Abnahmetest durch

  1. Verbinden Sie sich mit dem vorgesehenen WLAN und prüfen Sie die neue Client-Lease.
  2. Prüfen Sie das Standard-Gateway und testen Sie dann gegebenenfalls eine erlaubte Verbindung über eine IP-Adresse.
  3. Lösen Sie einen erlaubten Hostnamen über den ausgewählten Resolver auf und suchen Sie die zugehörige Abfrage.
  4. Testen Sie eine Domain in der aktiven Pi-hole-Richtlinie und prüfen Sie, ob die erwartete Antwort erfolgt.
  5. Wenn Sie eine Netzwerksegmentierung eingerichtet haben, testen Sie über die geroutete Grenze hinweg sowohl eine erlaubte als auch eine gesperrte Verbindung.
  6. Verbinden Sie den Client erneut oder erneuern Sie seine Lease und prüfen Sie, ob die vorgesehenen Einstellungen wiederhergestellt werden.
  7. Prüfen Sie während eines geplanten Wartungsfensters den Startpfad von Host und Gateway-VM, bevor Sie sich dauerhaft darauf verlassen.

Fehlersuche in Netzwerkreihenfolge

Symptom Wahrscheinliche zu prüfende Ebene Nützliche Nachweise
Keine erwartete Client-Adresse. AP-Bridge, Verkabelung, DHCP-Schnittstelle oder konkurrierender DHCP-Server. Die Lease und das Netzwerk, in dem sie bezogen wurde.
Der Client hat eine Adresse, aber keinen Internetzugang. Gateway, Zuordnung virtueller Schnittstellen, Upstream-Zugriff, Routing oder NAT. Status der Gast-Schnittstelle und der Testdatenfluss.
IP-Verbindungen funktionieren, Namensauflösung schlägt fehl. DNS-Endpunkt, Richtlinie, Listener oder Upstream-Resolver. Ein expliziter DNS-Test und ein passender Resolver-Protokolleintrag.
Eine gesperrte Verbindung funktioniert weiterhin. Falscher Netzwerkpfad, Regelumfang/-reihenfolge oder ein bestehender Status. Quell-/Zieladressen und der jeweilige Verbindungsstatus.
Das Netzwerk fällt nach einem Host-Update aus. Start der Gateway-VM oder Netzwerkzuordnung des Hosts. Konsolenzugriff und die zuletzt als funktionierend bekannten Host-/Gast-Einstellungen.

Beantworten Sie mithilfe der Protokolle immer nur eine Frage auf einmal. Die Dokumentation zur Firewall-Protokollierung von OPNsense erklärt, dass für einen zustandsbehafteten Datenfluss nicht unbedingt für jedes Paket eine neue Zeile im Live-Protokoll erscheint. Der Leitfaden zur Firewall-Diagnose bietet eine Zustandsübersicht. Ein ruhiges Protokoll allein beweist nicht, dass kein Datenverkehr die Firewall passiert hat.

Speichere eine funktionierende Konfiguration, bevor du größere Änderungen vornimmst, und halte einen klaren Rollback-Plan bereit. Halte während der Tests die alte Verbindung separat verfügbar. Vermeide es, die Netzwerke vor und hinter der Firewall versehentlich miteinander zu verbinden. Bei einem sinnvollen Rollback werden ein bekanntes Gateway und eine bekannte Client-Konfiguration wiederhergestellt, anstatt zwei konkurrierende Router in dasselbe Client-Segment einzuführen.

FAQ

Kann die ZimaBoard 2 allein das WLAN bereitstellen?

In diesem Video stellt ein separater Access Point das WLAN bereit. Das Board hostet das virtualisierte Gateway und zugehörige Dienste. Routing und WLAN-Zugang sind unterschiedliche Aufgaben.

Kann ich das ISP-Modem entfernen?

Nur, wenn deine Dienste nicht mehr darauf angewiesen sind. DSL-, Kabel- und anbieterabhängige Konfigurationen benötigen möglicherweise weiterhin ihre ursprünglichen Übergabegeräte. Prüfe die Anforderungen an Hardware und Dienste, bevor du ein Gateway ersetzt.

Isoliert eine Regel für ausgehenden Datenverkehr IoT-Geräte?

Dadurch wird keine Netzwerksegmentierung geschaffen. Geräte in einem lokalen Segment können möglicherweise miteinander kommunizieren, ohne die geroutete Firewall zu passieren. Für eine Isolierung sind getrennte Netzwerke und eine getestete Richtlinie zwischen ihnen erforderlich.

Sollte Pi-hole innerhalb von OPNsense laufen?

Das vorgestellte Projekt verwendet neben der virtualisierten Firewall einen Pi-hole-Dienst und gibt dessen Adresse über DHCP bekannt. Entscheidend ist ein erreichbarer, konsistenter DNS-Pfad. Gehe nicht davon aus, dass dieser Dienst mit der Installation von OPNsense ebenfalls installiert wird.

Warum benötigt die Firewall-VM zwei Netzwerkpfade?

Das geroutete Design benötigt einen Pfad zum vorgelagerten Netzwerk und einen separaten Pfad zum nachgelagerten Netzwerk. Durch die korrekte Zuordnung der Schnittstellen zwischen Gast und Host wird diese Grenze eingerichtet. Zwei sichtbare Adapternamen allein belegen nicht, dass die Netzwerke isoliert sind.

Was passiert beim Neustart des ZimaOS-Hosts?

Die Gast-Firewall und andere gehostete Dienste können ausfallen. Plane den Start und die Wiederherstellung der virtuellen Maschinen und überprüfe beides während eines Wartungsfensters. Bei gemeinsam genutzter Hardware gehört die Host-Wartung zur Verfügbarkeit des Gateways.

Fazit

Der Aufbau von The Social Dork ist hilfreich, weil er aus einem All-in-One-Gateway eine Reihe verständlicher Aufgaben macht: Internetanbindung, virtualisiertes Routing, WLAN-Zugang, Adresszuweisung und DNS-Filterung. Der erste erfolgreiche Laptop-Test liefert einen Ausgangspunkt. Bei einem dauerhaft betriebenen Heim-Gateway müssen außerdem die Netzwerkgrenzen überprüft, geeignete Richtlinien für die einzelnen Client-Gruppen festgelegt und ein Wiederherstellungsweg eingerichtet werden.

Führe die Prüfungen mit einem einzelnen Client vollständig durch, bevor du den Haushalt umstellst. Überprüfe zusätzliche Segmentierungen oder VPN-Verhalten anschließend unabhängig davon. Halte die OPNsense-Videoanleitung zusammen mit deinem eigenen Schnittstellenplan und der aktuellen offiziellen Dokumentation bereit. Ziel ist ein Netzwerk, dessen Verhalten du erklären, testen und wiederherstellen kannst.

Zima-Kampagnenzentrale

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.