Gäst-Wi-Fi fortsätter att använda huvudvägen: ge det en egen utgång

Du skapade ett gästnätverk, lade till en rutt för det, och gästerna går fortfarande ut via din vanliga internetanslutning. Tunneln är uppe, huvud-LANet fungerar, och gästenheterna rapporterar en adress i intervallet du tilldelade, så ingenting ser trasigt ut. Det som oftast saknas är inte en rutt utan en väljare: routern bestämmer vägen innan den tar hänsyn till vilket gränssnitt paketet kom in på, och om inget uttryckligen matchar gästtrafiken ärver den trafiken standardvärdet. Lösningen är ett segment, en policyregel och en returväg, i den ordningen.

Symtomet: gästerna går fortfarande ut via WAN

Ledtråden är ut adressen. En gästenhet som når internet via tunneln rapporterar tunnelleverantörens adress, och en som ärvde standardvärdet rapporterar din vanliga anslutning. Jämför en gästenhet och en huvud-LAN-enhet sida vid sida, eftersom det intressanta fallet är när de skiljer sig från det du konfigurerade och stämmer överens med varandra.

Den andra ledtråden är frånvaron av all trafik på tunnelgränssnittet medan gästerna surfar. Om räknarna inte rör sig har policyn aldrig tillämpats, och att justera själva tunneln kan inte hjälpa.

Steg 1: ett riktigt segment, inte bara ett namn

Ett SSID-namn skapar ingen isolering. Kontrollera att gästnätverket slutar på sitt eget gränssnitt, VLAN eller brygga, och att adressintervallet skiljer sig från det betrodda LANet. På många konsumentaccesspunkter bryggas gäst-SSIDet in i samma segment som allt annat, vilket gör resten av arbetet omöjligt tills det rättas.

Bekräfta sedan gästintervallet och dess DHCP-server, och håll resolverinställningarna knutna till det segmentet i stället för till hela routern. Ett gästsubnät som bara finns som en kommentar i en brandväggsregel är inte ett segment, och routern kommer inte att ha något gränssnitt att matcha mot.

Brygga inte in gästerna i huvud-LANet för att göra VPN-en lättare att konfigurera. Det byter isoleringen du ville ha mot en routinggenväg, och det är den vanliga anledningen till att ett gästnätverk till slut får åtkomst till skrivaren och NASen.

Steg 2: välj tunneln efter källa

Routtabeller väljs efter destination, så en regel som säger «skicka 0.0.0.0/0 till tunneln» gäller för alla. Policyrouting lägger till en andra dimension: välj tabellen efter källadress. På en Linux-baserad router är det en extra regel plus en dedikerad tabell, och ordningen spelar roll eftersom den första matchande regeln vinner:

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

Det sista kommandot svarar direkt på frågan: vilket gränssnitt denna källa kommer att använda för denna destination. Kör det före och efter ändringen och du vet om policyn trädde i kraft utan att röra en webbläsare.

De flesta routerfastmjukvaror uttrycker samma sak som en gränssnittsregel eller ett källbaserat gatewayval. Vilken syntax din plattform än använder är principen identisk: matcha det inkommande gränssnittet eller källprefixet och skriv sedan över rutten bara för den matchningen. En regel som matchas efter destination kan inte skilja en gäst från en hushållsenhet.

Steg 3: returvägen och översättningen

Ett paket som går ut genom tunneln måste komma tillbaka. Antingen känner tunnelpartnern en väg tillbaka till gästprefixet, eller så översätter routern gästkällan till tunneladressen. Välj en och skriv ner den, eftersom fellägena ser olika ut: en saknad returväg ger en anslutning som upprättas och aldrig svarar, medan en saknad översättning ofta inte ger något alls.

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

Om du väljer översättning, kom ihåg att partnern nu ser en enda adress för varje gäst, så all per-klient-policy i den bortre änden försvinner. Om du behåller adresserna i stället behöver båda ändarna gästprefixet i sin routing och policy, vilket är mer arbete och mer förutsägbart.

IPv6 behöver sin egen regel. En policy skriven för IPv4 täcker inte den andra familjen, och en gästenhet med fungerande IPv6 använder den gärna medan din noggrant routade IPv4-väg står oanvänd. Routa båda familjerna eller inaktivera IPv6 på gästsegmentet, men anta inte att den kombinerade regel du skrev täcker vad enheten faktiskt gör. Testa med en klient som har båda familjerna aktiverade, eftersom det är fallet designen måste klara. En bärbar dator som föredrar IPv6 ser korrekt ut i ett test med bara IPv4 och läcker i det verkliga.

Testa isolering, inte bara surfande

Surfande bevisar att utgången ändrades. Det bevisar inte att segmentet är isolerat, och isoleringen är anledningen till att gästnätverket finns. Från en gästenhet, försök nå routerns administrationsgränssnitt, en värd i det betrodda LANet och en tjänst som borde nekas; alla tre borde misslyckas, och misslyckandet borde vara ett policybeslut i stället för en tidsgräns som ingen kan förklara.

Testa sedan en huvud-LAN-enhet och bekräfta att dess utgång inte ändrades. Det är den regression som denna design oftast orsakar: en bred regel avsedd för gäster, tillämpad på varje gränssnitt eftersom matchningen skrevs på destinationen.

Bestäm till sist vad som händer när tunneln är nere. Gästerna får antingen ingen internet eller faller tillbaka till en väg du godkänner, och att lämna det oavgjort innebär en tyst återgång till den vanliga anslutningen, vilket är precis den läcka som gästpolicyn skulle förhindra. Receptet för routning av internettrafik går igenom samma vägval för en pfSense-baserad router.

DNS som kommer från routern är fallet som överraskar folk sist. Om gästerna använder routern som resolver följer routerns egna frågor routerns rutt i stället för gästregeln, så sökningar kan gå ut via den vanliga anslutningen medan applikationstrafiken inte gör det. Håll segmentet, resolveren och felpolicyn i ett enda anteckning, och nästa person kan kontrollera alla tre utan att härleda designen igen.