Gasten-Wi-Fi blijft de hoofdroute gebruiken: geef het een eigen uitgang

Je hebt een gastnetwerk gemaakt, er een route voor toegevoegd, en de gasten gaan nog steeds via je normale internetverbinding naar buiten. De tunnel is actief, het hoofd-LAN werkt, en de gastapparaten melden een adres in het bereik dat je hebt toegewezen, dus niets lijkt kapot. Wat meestal ontbreekt is geen route maar een selector: de router bepaalt het pad voordat hij bekijkt via welke interface het pakket binnenkwam, en tenzij iets expliciet overeenkomt met gastverkeer, erft dat verkeer de standaardwaarde. De oplossing is een segment, een beleidsregel en een retourpad, in die volgorde.

Het symptoom: gasten gaan nog steeds via de WAN naar buiten

De aanwijzing is het uitgangsadres. Een gastapparaat dat via de tunnel internet bereikt, meldt het adres van de tunnelprovider, en een dat de standaardwaarde heeft geërfd meldt je normale verbinding. Vergelijk een gastapparaat en een hoofd-LAN-apparaat naast elkaar, want het interessante geval is wanneer ze afwijken van wat je hebt geconfigureerd en met elkaar overeenkomen.

De tweede aanwijzing is de afwezigheid van al het verkeer op de tunnelinterface terwijl gasten browsen. Als de tellers niet bewegen, is het beleid nooit toegepast, en het aanpassen van de tunnel zelf kan niet helpen.

Stap 1: een echt segment, niet alleen een naam

Een SSID-naam creëert geen isolatie. Controleer of het gastnetwerk op zijn eigen interface, VLAN of bridge eindigt, en of het adresbereik verschilt van het vertrouwde LAN. Op veel consumentenaccesspoints wordt de gast-SSID in hetzelfde segment als al het andere gebrugd, waardoor de rest van dit werk onmogelijk is totdat dat is gecorrigeerd.

Bevestig daarna het gastbereik en de DHCP-server, en houd de resolverinstellingen gekoppeld aan dat segment in plaats van aan de hele router. Een gastsubnet dat alleen als opmerking in een firewallregel bestaat is geen segment, en de router heeft geen interface om mee te matchen.

Brug gasten niet in het hoofd-LAN om de VPN gemakkelijker te configureren. Dat ruilt de isolatie die je wilde tegen een routingkortere weg, en dat is de gebruikelijke reden waarom een gastnetwerk uiteindelijk toegang krijgt tot de printer en de NAS.

Stap 2: selecteer de tunnel op bron

Routingtabellen worden op bestemming gekozen, dus een regel die zegt «stuur 0.0.0.0/0 naar de tunnel» geldt voor iedereen. Beleidsroutering voegt een tweede dimensie toe: selecteer de tabel op bronadres. Op een Linux-gebaseerde router is dat een extra regel plus een speciale tabel, en de volgorde is belangrijk omdat de eerste overeenkomende regel wint:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Dat laatste commando beantwoordt de vraag direct: welke interface deze bron voor deze bestemming zal gebruiken. Voer het voor en na de wijziging uit en je weet of het beleid effect heeft gehad zonder een browser aan te raken.

De meeste routerfirmware drukt hetzelfde uit als een interfaceregel of een op bron gebaseerde gatewaykeuze. Welke syntaxis je platform ook gebruikt, het principe is identiek: match op de inkomende interface of het bronprefix, en overschrijf dan de route alleen voor die match. Een regel die op bestemming matcht kan een gast niet van een huishoudapparaat onderscheiden.

Stap 3: het retourpad en de vertaling

Een pakket dat via de tunnel naar buiten gaat, moet terugkomen. Ofwel kent de tunnelpartner een route terug naar het gastprefix, ofwel vertaalt de router de gastbron naar het tunneladres. Kies er één en schrijf het op, want de faalmodi zien er anders uit: een ontbrekend retourpad geeft een verbinding die tot stand komt en nooit antwoordt, terwijl een ontbrekende vertaling vaak helemaal niets oplevert.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Als je voor vertaling kiest, onthoud dan dat de partner nu één adres voor elke gast ziet, dus elk beleid per client aan de verre kant verdwijnt. Als je de adressen behoudt, hebben beide uiteinden het gastprefix nodig in hun routering en beleid, wat meer werk is en voorspelbaarder.

IPv6 heeft zijn eigen regel nodig. Een beleid dat voor IPv4 is geschreven, dekt de andere familie niet, en een gastapparaat met werkende IPv6 zal het graag gebruiken terwijl je zorgvuldig gerouteerde IPv4-pad ongebruikt blijft. Route beide families of schakel IPv6 uit op het gastsegment, maar ga er niet van uit dat de gecombineerde regel die je hebt geschreven dekt wat het apparaat werkelijk doet. Test met een client die beide families heeft ingeschakeld, want dat is het geval dat het ontwerp moet overleven. Een laptop die IPv6 verkiest, lijkt correct in een test met alleen IPv4 en lekt in de echte.

Test isolatie, niet alleen browsen

Browsen bewijst dat de uitgang is veranderd. Het bewijst niet dat het segment geïsoleerd is, en isolatie is de reden dat het gastnetwerk bestaat. Probeer vanaf een gastapparaat de beheerinterface van de router, een host in het vertrouwde LAN en een dienst die geweigerd zou moeten worden te bereiken; alle drie moeten mislukken, en de mislukking moet een beleidsbeslissing zijn in plaats van een time-out die niemand kan verklaren.

Test daarna een hoofd-LAN-apparaat en bevestig dat de uitgang niet is veranderd. Dat is de regressie die dit ontwerp het vaakst veroorzaakt: een brede regel bedoeld voor gasten, toegepast op elke interface omdat de match op bestemming is geschreven.

Bepaal ten slotte wat er gebeurt als de tunnel uitvalt. Gasten krijgen ofwel geen internet of vallen terug op een pad dat je goedkeurt, en dat onbeslist laten betekent een stille terugval naar de normale verbinding, wat precies het lek is dat het gastbeleid moest voorkomen. Het recept voor het routeren van internetverkeer doorloopt dezelfde padselectie voor een op pfSense gebaseerde router.

DNS die van de router afkomstig is, is het geval dat mensen het laatst verrast. Als gasten de router als resolver gebruiken, volgen de eigen query's van de router de route van de router in plaats van de gastregel, dus opzoekingen kunnen via de normale verbinding naar buiten gaan terwijl het applicatieverkeer dat niet doet. Houd het segment, de resolver en het faalbeleid in één notitie, en de volgende persoon kan alle drie controleren zonder het ontwerp opnieuw af te leiden.