Gjest-Wi-Fi bruker fortsatt hovedruten: gi det sin egen utgang

Du opprettet et gjestenettverk, la til en rute for det, og gjestene går fortsatt ut gjennom din vanlige internettforbindelse. Tunnelen er oppe, hoved-LANet fungerer, og gjestenhetene rapporterer en adresse i området du tildelte, så ingenting ser ødelagt ut. Det som vanligvis mangler er ikke en rute, men en velger: ruteren bestemmer banen før den vurderer hvilket grensesnitt pakken kom inn på, og med mindre noe eksplisitt samsvarer med gjestetrafikken, arver den trafikken standardverdien. Løsningen er et segment, en policyregel og en returvei, i den rekkefølgen.

Symptomet: gjestene går fortsatt ut gjennom WAN

Tegnet er utgangsadressen. En gjestenhet som når internett gjennom tunnelen, vil rapportere tunnelleverandørens adresse, og en som arvet standardverdien vil rapportere din vanlige forbindelse. Sammenlign en gjestenhet og en hoved-LAN-enhet side ved side, fordi det interessante tilfellet er når de avviker fra det du konfigurerte og samsvarer med hverandre.

Det andre tegnet er fraværet av all trafikk på tunnelgrensesnittet mens gjestene surfer. Hvis tellerne ikke beveger seg, ble policyen aldri brukt, og å justere selve tunnelen kan ikke hjelpe.

Trinn 1: et ekte segment, ikke bare et navn

Et SSID-navn skaper ikke isolasjon. Sjekk at gjestenettverket avsluttes på sitt eget grensesnitt, VLAN eller bro, og at adresseområdet er forskjellig fra det klarerte LANet. På mange forbrukeraksesspunkter brues gjeste-SSIDet inn i samme segment som alt annet, noe som gjør resten av dette arbeidet umulig til det er rettet.

Bekreft deretter gjesteområdet og DHCP-serveren, og hold resolverinnstillingene knyttet til det segmentet i stedet for hele ruteren. Et gjestesubnett som bare finnes som en kommentar i en brannmurregel er ikke et segment, og ruteren vil ikke ha noe grensesnitt å matche mot.

Ikke bru gjestene inn i hoved-LANet for å gjøre VPN-en lettere å konfigurere. Det bytter isolasjonen du ønsket mot en ruteomvei, og det er den vanlige grunnen til at et gjestenettverk ender opp med tilgang til skriveren og NASen.

Trinn 2: velg tunnelen etter kilde

Rutetabeller velges etter destinasjon, så en regel som sier «send 0.0.0.0/0 til tunnelen» gjelder for alle. Policyrutering legger til en andre dimensjon: velg tabellen etter kildeadresse. På en Linux-basert ruter er det en ekstra regel pluss en dedikert tabell, og rekkefølgen betyr noe fordi den første samsvarende regelen 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

Den siste kommandoen svarer direkte på spørsmålet: hvilket grensesnitt denne kilden vil bruke for denne destinasjonen. Kjør den før og etter endringen, og du vet om policyen trådte i kraft uten å røre en nettleser.

De fleste ruterfastvarer uttrykker det samme som en grensesnittregel eller kildebasert gatewayvalg. Uansett hvilken syntaks plattformen din bruker, er prinsippet identisk: match inngangsgrensesnittet eller kildeperfikset, og overstyr deretter ruten bare for den matchen. En regel som matches etter destinasjon kan ikke skille en gjest fra en husholdningsenhet.

Trinn 3: returveien og oversettelsen

En pakke som går ut gjennom tunnelen må komme tilbake. Enten kjenner tunnelpartneren en rute tilbake til gjesteperfikset, eller så oversetter ruteren gjestekilden til tunneladressen. Velg én og skriv den ned, fordi feilmodusene ser forskjellige ut: en manglende returvei gir en tilkobling som etableres og aldri svarer, mens en manglende oversettelse ofte ikke gir noe i det hele tatt.

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

Hvis du velger oversettelse, husk at partneren nå ser én adresse for hver gjest, så all per-klient-policy i den fjerne enden forsvinner. Hvis du beholder adressene i stedet, trenger begge ender gjesteperfikset i ruteringen og policyen sin, noe som er mer arbeid og mer forutsigbart.

IPv6 trenger sin egen regel. En policy skrevet for IPv4 dekker ikke den andre familien, og en gjestenhet med fungerende IPv6 vil gjerne bruke den mens din nøye rutede IPv4-bane står ubrukt. Rut både familiene eller deaktiver IPv6 på gjestesegmentet, men ikke anta at den kombinerte regelen du skrev dekker det enheten faktisk gjør. Test med en klient som har begge familiene aktivert, fordi det er tilfellet designet må tåle. En bærbar PC som foretrekker IPv6 ser riktig ut i en IPv4-bare test og lekker i den virkelige.

Test isolasjon, ikke bare surfing

Surfing beviser at utgangen endret seg. Det beviser ikke at segmentet er isolert, og isolasjon er grunnen til at gjestenettverket finnes. Fra en gjestenhet, prøv å nå ruterens administrasjonsgrensesnitt, en vert i det klarerte LANet og en tjeneste som skal avvises; alle tre skal mislykkes, og feilen skal være en policybeslutning i stedet for en timeout ingen kan forklare.

Test deretter en hoved-LAN-enhet og bekreft at utgangen ikke endret seg. Det er regresjonen dette designet oftest forårsaker: en bred regel ment for gjester, brukt på hvert grensesnitt fordi matchen ble skrevet på destinasjonen.

Til slutt, bestem hva som skjer når tunnelen er nede. Gjestene får enten ingen internett eller faller tilbake til en bane du godkjenner, og å la det være uavgjort betyr en stille tilbakefall til den vanlige forbindelsen, som er nøyaktig lekkasjen gjestepolicyen skulle forhindre. Oppskriften for rutering av internettrafikk går gjennom det samme banevalget for en pfSense-basert ruter.

DNS som kommer fra ruteren er tilfellet som overrasker folk sist. Hvis gjestene bruker ruteren som resolver, følger ruterens egne spørringer ruterens rute i stedet for gjesteregelen, så oppslag kan gå ut gjennom den vanlige forbindelsen mens applikasjonstrafikken ikke gjør det. Hold segmentet, resolveren og feilpolicyen i ett notat, og neste person kan sjekke alle tre uten å utlede designet på nytt.