Så bygger The Social Dork en OPNsense-brandvägg för hemmet

Tack till The Social Dork | Cybersäkerhet för att de delade en uppbyggnad av en OPNsense-hembrandvägg på ZimaBoard 2. En virtuell maskin hanterar routing och brandväggspolicy, en åtkomstpunkt tillhandahåller Wi-Fi och Pi-hole står för DNS-filtrering för anslutna klienter. Se den ursprungliga YouTube-genomgången för hela demonstrationen.

Titta innan du läser: Den här videon på ungefär tio minuter är användbar om du vill separera nätverkets gateway från den trådlösa åtkomstpunkten. Innehållsskaparen förklarar topologin, startar OPNsense i Zima Virtual Machine, tilldelar gränssnitt och DHCP och kontrollerar sedan en bärbar dator med trådlös anslutning och dess DNS-filtrering.

Det demonstrerade delmålet är att en bärbar dator ansluter till nätverket via den nya brandväggen och använder det valda DNS-filtret. Videon visar hur man ansluter den första klienten. Den inledande frågan om sårbara IoT-enheter skulle kräva ytterligare nätverksseparering och åtkomstpolicy. Att placera enheter på ett nytt SSID isolerar dem inte i sig från varandra.

Bestäm vilka uppgifter den befintliga gatewayen måste behålla

Genomgången av topologin skiljer mellan tre uppgifter som en allt-i-ett-router kan dölja: anslutningen till internetleverantören, den routade brandväggsgränsen och trådlös åtkomst. En Ethernetanslutning kan mata den nya brandväggen, medan en DSL- eller kabelanslutning fortfarande kräver rätt modem eller leverantörsutrustning. Att ersätta routingfunktionen tar inte bort kravet på den fysiska anslutningen.

I innehållsskaparens fungerande konfiguration är den befintliga hemroutern ansluten till brandväggens WAN-sida och en åtkomstpunkt sitter på dess LAN-sida. Om den uppströms gatewayen också utför nätverksadressöversättning skapas dubbel NAT. Det kan fungera för ett första test, men kan försvåra inkommande tjänster och felsökning. Om bryggläge eller passthrough-läge är tillgängligt beror på leverantörens utrustning och tjänst; kontrollera det innan du ändrar den aktiva anslutningen.

Anteckna de aktuella inställningarna mot internetleverantören innan du gör ett byte. En video som visar en Ethernet-anslutning fastställer inte din internetleverantörs krav på autentisering, VLAN eller modem. Ha den gamla gatewaykonfigurationen tillgänglig medan du testar den nya anslutningen med en klient. Då blir det möjligt att skilja ett problem med uppströmsanslutningen från ett misstag i det nya LAN-nätverket.

Dubbel NAT beskriver två routade översättningsgränser; det är inte samma sak som att bara ha en åtkomstpunkt nedströms. Om den trådlösa enheten också fortsätter att routa kan den lägga till ytterligare en gräns och en DHCP-tjänst. Bekräfta enhetens faktiska driftläge och kabelanslutning i stället för att avgöra dess funktion utifrån produktetiketten på höljet.

Koppla de virtuella gränssnitten till en verklig WAN- och LAN-gräns

The Social Dork laddar ner en installationsavbildning av OPNsense och startar den i Zima Virtual Machine på ZimaBoard 2. Det här är en demonstration av en virtualiserad brandvägg. Värden kör fortfarande ZimaOS, så dess nätverkskonfiguration är också en del av utformningen, liksom OPNsense-inställningarna i gästen.

Vid en liknande driftsättning ska varje virtuellt gränssnitt uttryckligen kopplas till avsedd fysisk port eller isolerat värdnätverk. Två nätverksuttag innebär inte att kopplingen görs automatiskt. Håll WAN-vägen åtskild från vanliga värdtjänster och se till att LAN-klienternas trafik måste passera genom brandväggen för att nå uppströmsanslutningen. Om en klient har en annan väg förbi den virtuella maskinen kan brandväggen inte tillämpa regler på den trafiken.

Följ aktuella installationsanvisningar för OPNsense och aktuell vägledning för virtuella maskiner för den valda avbildningen och plattformen. Anteckna hur du får åtkomst till värden och VM-konsolen innan du ändrar gränssnitten. En omstart av värden, lagringsproblem eller avstängning av den virtuella maskinen kan avbryta den här gatewayen, så planera underhållet med hänsyn till hushållets internetanslutning.

Gör gränssnittsplanen tydlig

1. Identifiera värdens fysiska portar och anteckna vilken kabel som går till uppströmsanslutningen.
2. Koppla gästens WAN-gränssnitt till det avsedda uppströmsnätverket.
3. Koppla dess LAN-gränssnitt till ett separat nedströmsnätverk.
4. Bekräfta att administrationsåtkomst och vanliga värdtjänster inte oavsiktligt exponeras via WAN-sidan.
5. Anslut en testklient nedströms och kontrollera dess faktiska standardgateway innan du lägger till fler enheter.

Ett gränssnittsnamn i den virtuella maskinen kanske inte stämmer överens med märkningen bredvid en fysisk port. Använd hypervisorns nätverksmappning och den virtuella maskinens konsol för att fastställa sambandet. Kontrollera det igen efter att du har ändrat virtuella nätverkskort. Videon visar en fungerande konfiguration på skaparens maskin, men den är inte en fullständig förteckning över alla värdbryggor eller adapterinställningar som du kan stöta på.

Tilldela resurser till brandväggen samtidigt som du lämnar kapacitet åt ZimaOS och värdens övriga tjänster. Den aktuella OPNsense-guiden för virtualisering anger 3 GB RAM som minimum, en rekommenderad minsta virtuell disk på 8 GB och vägledning om nätverkskompatibilitet. Det här är utgångspunkter, inte ett löfte om dataflöde. Loggar, VPN, inspektionsfunktioner och andra arbetsbelastningar kan påverka hur mycket extra kapacitet som behövs.

Det här är en driftsmässig kompromiss med att dela en maskin: en uppdatering eller omstart av värden kan också slå ut den virtuella gateway-maskinen. Bestäm hur den virtuella maskinen ska starta efter uppstart och hur du ska återställa den om den inte startar. En stabil konsolanslutning är särskilt användbar när en felaktig nätverksinställning gör webbgränssnittet oåtkomligt.

Låt en DHCP-tjänst hantera varje klientnätverk

Skaparen använder olika IPv4-nätverk uppströms och nedströms: uppströmssidan använder adresserna 192.168.0.x och klienternas LAN-nätverk använder adresserna 192.168.1.x. Det här är exempel från videon. Välj icke överlappande subnät som passar ditt eget nätverk i stället för att kopiera adresser som kanske redan används.

Åtkomstpunkten tillhandahåller radioanslutningen, medan OPNsense hanterar DHCP-tilldelningarna till klienterna i det nedströms nätverket. Genomgången tar upp AP-läge och att inaktivera DHCP-tjänsten på den gamla trådlösa routern. På utrustning utan ett särskilt AP-läge garanterar inte enbart inaktiverad DHCP ett transparent åtkomstpunktsbeteende: kontrollera tillverkarens krav på LAN-till-LAN-koppling och routning/NAT. Se till att administrationsadressen förblir åtkomlig utan att hamna i konflikt med DHCP-poolen.

Testa den resulterande DHCP-tilldelningen på en bärbar dator. Den ska få en adress i det avsedda LAN-nätverket, brandväggens LAN-adress som standard-gateway och den avsedda DNS-servern. Att Wi-Fi-anslutningen fungerar visar bara att radioanslutningen fungerar. Adressen, gatewayen och DNS-resolvern visar om klienten faktiskt har anslutit till den nya nätverksvägen.

Planera fasta adresser och lånepoolen separat

Följande är en illustrativ /24-plan för LAN, inte en avskrift av skaparens exakta adresser. Anpassa den efter dina befintliga nätverk. Reservera fasta adresser för infrastrukturen utanför det dynamiskt tilldelade intervallet och se till att uppströmsnätverket skiljer sig från det nedströms LAN-nätverket.

Om Pi-hole faktiskt finns på ett annat subnät eller i ett virtuellt nätverk på värddatorn använder du dess verkliga, nåbara slutpunkt samt nödvändig routning och policy. Exempeladressen gör inte att tjänsten blir tillgänglig på LAN av sig själv. En DHCP-post anger för klienterna vart de ska skicka en begäran; den upprättar inte routen eller startar servern.

När du har ändrat DHCP-inställningarna kontrollerar du lånet på den bärbara datorn i stället för att bara titta på serverns konfigurationssida. Bekräfta den tilldelade adressen, nätmasken, gatewayen och DNS-posterna. En klient som fortfarande har ett gammalt lån kan få en korrekt ny konfiguration att verka felaktig. En oväntad adress eller gateway är också ett tecken på att en annan DHCP-server fortfarande är aktiv.

Behandla den första tillåtande regeln som ett anslutningstest

Skaparen börjar med en tillåtande regel för utgående trafik för den enda testdatorn och diskuterar hur oombedda anslutningar från WAN till LAN kan förhindras. OPNsense använder tillståndsbaserad filtrering, så svar på en tillåten anslutning hanteras med hjälp av anslutningstillståndet. Dokumentationen om brandväggsregler i OPNsense förklarar hur gränssnitt, riktning och regelordning påverkar detta beteende.

Videon öppnar också webbgränssnittet från sitt privata uppströmsnätverk. I din egen installation bör du begränsa administratörsåtkomsten till en betrodd hanteringsväg och behålla ett återställningsalternativ via konsolen. WAN-etiketten beskriver en roll i förhållande till den här brandväggen; ett privat uppströmssegment i ett labb och det offentliga internet innebär olika exponeringsförhållanden.

För att hantera IoT-problemet som togs upp i början skapar du separata nätverk med utrustning som stöder dem och definierar sedan vilken trafik som tillåts mellan dem. Enheter som utbyter trafik inom samma lokala segment kan kommunicera utan att passera den routade brandväggen. För ett annat praktiskt perspektiv på beslut om gateway och integritet, se cachito labs OPNsense-brandväggsbygge.

Skilj mellan anslutning och isolering

Definiera källa, destination, protokoll och avsett syfte innan du lägger till en regel. En regel som visar att en bärbar dator kan nå internet är inte en policy för alla enheter i ett hushåll. För nätverkssegmentering använder du separata nätverk och en brandväggsväg mellan dem. Trafik som utbyts lokalt inom samma segment kanske inte når gatewayen alls.

När en regeländring verkar sakna effekt kan du testa en ny anslutning och ta hänsyn till anslutningstillståndet. Guiden till OPNsense-regler förklarar tillståndsbaserad hantering. Befintliga tillstånd kan påverka ett nytt test, medan en återställning av alla tillstånd skulle avbryta andra aktiva anslutningar. Identifiera det specifika testflödet innan du gör en omfattande diagnostisk ändring.

Anslut Pi-hole via DHCP utan att skapa en DNS-loop

Mot slutet ställer The Social Dork in den DNS-server som tillhandahålls via DHCP på Pi-holes adress. Då förs det tidigare annonsblockeringsprojektet med Pi-hole och Tailscale över till det nya trådlösa nätverket. OPNsense styr den routade trafikvägen; Pi-hole hanterar DNS-namn som efterfrågas via dess tjänst. De två komponenterna har olika ansvarsområden.

Pi-holes integreringsguide för OPNsense beskriver direkt distribution via DHCP och vidarebefordring via brandväggen som alternativa lösningar. Välj en konsekvent väg och se till att resolvrarna inte vidarebefordrar förfrågningar till varandra i en loop. Kontrollera också att klienterna får ansluta till Pi-hole-adressen om den finns i ett annat nätverk.

Välj en resolverväg och rita upp den från början till slut

Videon använder Pi-hole-adressen som tilldelas klienterna via DHCP. Vidarebefordringslösningen i den länkade officiella guiden är ett alternativ. Om du väljer den bör du se till att Pi-holes uppströmsserver inte skickar förfrågan direkt tillbaka in i samma vidarebefordringskedja. Med en tydlig sökväg blir det mycket lättare att felsöka om svar uteblir.

DNS är också beroende av transport och routning. Om klienten och resolvern finns i olika nätverk bör du kontrollera sökvägen och reglerna för relevanta TCP/UDP-portar, port 53. Granska DNS-annonseringar för IPv6 och klienternas separata DNS-inställningar om resultatet avviker från DHCP-konfigurationen. Att Pi-hole-webbgränssnittet går att nå är inte tillräckligt som bevis.

För filtrering när du inte är hemma kan du läsa den kompletterande genomgången av Pi-hole och Tailscale igen. Fjärråtkomst till DNS, lokal gateway-policy och all utgående internettrafik via VPN är separata val. Testa vart och ett på den anslutning där det faktiskt ska användas.

Verifiera hela sökvägen innan du flyttar varje enhet

I den avslutande demonstrationen byter man Wi-Fi-nätverk på den bärbara datorn och jämför samma webbplats med och utan filtreringskonfigurationen. Den visar den valda klientvägen, men bevisar inte att alla webbplatser är reklamfria eller att alla enheter är isolerade. Kontrollera först internetåtkomst och DNS, och granska sedan relevanta brandväggs- och Pi-hole-loggar för att koppla varje resultat till den avsedda klienten.

Innan du flyttar hushållet testar du en klientförnyelse, en tillåten anslutning och en avsiktligt nekad anslutning mellan separata nätverk, om segmentering ingår i din design. Exportera en fungerande brandväggskonfiguration och bekräfta återställningsvägen. Målet är en gateway vars routning, DHCP, filtrering och administration du kan förklara och underhålla. Se The Social Dorks fullständiga genomgång av OPNsense-brandvägg för hemmet för den ursprungliga topologin och installationsordningen.

Använd ett stegvis acceptanstest

1. Anslut till det avsedda trådlösa nätverket och granska den nya klientleasen.
2. Bekräfta standardgatewayen och testa sedan en tillåten IP-baserad anslutning där det är lämpligt.
3. Slå upp ett tillåtet värdnamn via den valda resolvern och hitta frågan i loggen.
4. Testa en domän i den aktiva Pi-hole-policyn och bekräfta att du får det förväntade svaret.
5. Om du har konfigurerat segmentering testar du både en tillåten och en nekad anslutning över den routade gränsen.
6. Återanslut klienten eller förnya dess lease och bekräfta att de avsedda inställningarna återställs.
7. Under ett planerat underhållsfönster bör du verifiera värdens och gateway-VM:ens startförlopp innan du förlitar dig på att det fungerar kontinuerligt.

Felsök i nätverksordning

Använd loggar för att besvara en fråga i taget. OPNsense dokumentation om brandväggsloggning förklarar att ett tillståndsbaserat flöde inte nödvändigtvis ger en ny rad i realtidsloggen för varje paket. Guiden för brandväggsdiagnostik visar tillståndsvyn. Att loggen är tyst bevisar inte i sig att ingen trafik har passerat brandväggen.

Spara en fungerande konfiguration innan du gör en större ändring och behåll en tydlig återställningsplan. Under testningen ska den gamla anslutningen hållas tillgänglig separat; undvik att oavsiktligt koppla ihop uppströms- och nedströmsnätverken runt brandväggen. En bra återställningsplan återställer en känd gateway- och klientkonfiguration i stället för att lägga till två konkurrerande routrar i samma klientsegment.

Vanliga frågor

Kan ZimaBoard 2 ersätta Wi-Fi-radion på egen hand?

I den här videon tillhandahåller en separat åtkomstpunkt Wi-Fi. Kortet står värd för den virtualiserade gatewayen och relaterade tjänster. Routing och trådlös åtkomst är olika roller.

Kan jag ta bort ISP-modemet?

Bara om tjänsteöverlämningen inte längre kräver det. DSL-, kabel- och leverantörsspecifika lösningar kan fortfarande behöva sin ursprungliga termineringsutrustning. Kontrollera de fysiska kraven och tjänstekraven innan du byter ut en gateway.

Isolerar en regel som tillåter utgående trafik IoT-enheter?

Det skapar ingen nätverksseparering. Enheter på samma lokala nätverkssegment kan kommunicera utan att passera den routade brandväggen. För isolering krävs separata nätverk och en testad policy mellan dem.

Bör Pi-hole köras i OPNsense?

Det demonstrerade projektet använder en Pi-hole-tjänst tillsammans med den virtualiserade brandväggen och anger dess adress via DHCP. Det viktiga är en nåbar och konsekvent DNS-väg; utgå inte från att installation av OPNsense också installerar den tjänsten.

Varför behöver brandväggens virtuella maskin två nätverksvägar?

Den routade lösningen behöver en väg mot uppströmsnätet och en separat väg nedströms. Korrekt mappning mellan gästen och värden skapar den gränsen. Att två adapternamn visas är i sig inget bevis på att nätverken är isolerade.

Vad händer när ZimaOS-värden startas om?

Gästbrandväggen och andra värdtjänster kan bli otillgängliga. Planera för uppstart och återställning av virtuella maskiner och verifiera sedan detta under ett underhållsfönster. När hårdvaran delas blir underhåll av värdsystemet en del av gatewayens tillgänglighet.

Slutsats

The Social Dorks bygge är användbart eftersom det delar upp en allt-i-ett-gateway i begripliga uppgifter: anslutning till internetleverantören, virtualiserad routing, trådlös åtkomst, tilldelning av nätverksadresser och DNS-filtrering. Det första lyckade testet med en bärbar dator ger en utgångspunkt. En underhållen hemgateway behöver också verifierade nätverksgränser, en lämplig policy för varje klientgrupp och en återställningsplan.

Slutför kontrollerna med en enda klient innan du flyttar över hushållet, och testa sedan eventuell ytterligare segmentering eller VPN-funktion oberoende av detta. Ha den ursprungliga videogenomgången av OPNsense till hands tillsammans med din egen gränssnittsplan och den aktuella officiella dokumentationen. Målet är ett nätverk vars funktion du kan förklara, testa och återställa.