Gæste-Wi-Fi bruger stadig hovedruten: giv det sin egen udgang

Du oprettede et gæstenetværk, tilføjede en rute til det, og gæsterne går stadig ud gennem din normale internetforbindelse. Tunnelen er oppe, hoved-LAN'et virker, og gæsteenhederne rapporterer en adresse i det interval, du tildelte, så intet ser ødelagt ud. Det, der normalt mangler, er ikke en rute, men en selektor: routeren vælger stien, før den overvejer, hvilken grænseflade pakken ankom på, og medmindre noget udtrykkeligt matcher gæstetrafik, arver den trafik standarden. Rettelsen er et segment, en politikregel og en returvej, i den rækkefølge.

Symptomet: gæster går stadig ud gennem WAN

Tegnet er udgangsadressen. En gæsteenhed, der når internettet gennem tunnelen, rapporterer tunneludbyderens adresse, og en, der har arvet standarden, rapporterer din normale forbindelse. Sammenlign en gæsteenhed og en hoved-LAN-enhed side om side, fordi det interessante tilfælde er, når de afviger fra det, du konfigurerede, og matcher hinanden.

Det andet tegn er fraværet af trafik på tunnelgrænsefladen, mens gæsterne browser. Hvis tællerne ikke bevæger sig, blev politikken aldrig anvendt, og det hjælper ikke at justere selve tunnelen.

Trin 1: et rigtigt segment, ikke bare et navn

Et SSID-navn skaber ikke isolering. Kontrollér, at gæstenetværket terminerer på sin egen grænseflade, VLAN eller bro, og at adresseintervallet er forskelligt fra det betroede LAN. På mange forbrugeradgangspunkter broes gæste-SSID'et ind i samme segment som alt andet, hvilket gør resten af arbejdet umuligt, indtil det rettes.

Bekræft derefter gæsteintervallet og dets DHCP-server, og hold resolverindstillingerne knyttet til det segment i stedet for til hele routeren. Et gæstesubnet, der kun findes som en kommentar i en firewallregel, er ikke et segment, og routeren har ingen grænseflade at matche imod.

Bro ikke gæster ind i hoved-LAN'et for at gøre VPN lettere at konfigurere. Det bytter den isolering, du ønskede, for en genvej i routing, og det er den sædvanlige grund til, at et gæstenetværk ender med adgang til printeren og NAS'et.

Trin 2: vælg tunnelen efter kilde

Routingtabeller vælges efter destination, så en regel, der siger send 0.0.0.0/0 til tunnelen, gælder for alle. Policy routing tilføjer en anden dimension: vælg tabellen efter kildeadresse. På en Linux-baseret router er det en ekstra regel plus en dedikeret tabel, og rækkefølgen betyder noget, fordi den første matchende regel vinder:

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 sidste kommando besvarer spørgsmålet direkte: hvilken grænseflade vil denne kilde bruge til denne destination. Kør den før og efter ændringen, og du ved, om politikken trådte i kraft, uden at røre en browser.

De fleste routerfirmware udtrykker det samme som en grænsefladeregel eller et kildebaseret gatewayvalg. Uanset hvilken syntaks din platform bruger, er princippet det samme: match på indgangsgrænsefladen eller kildeforstavelsen, og tilsidesæt derefter ruten kun for det match. En regel, der matches på destinationen, kan ikke skelne en gæst fra en husholdningsenhed.

Trin 3: returvejen og oversættelsen

En pakke, der går ud gennem tunnelen, skal komme tilbage. Enten kender tunnelpeer'en en rute tilbage til gæstepræfikset, eller routeren oversætter gæstekilden til tunneladressen. Vælg én og skriv den ned, fordi fejlmåderne ser forskellige ud: en manglende returrute giver en forbindelse, der oprettes og aldrig svarer, mens manglende oversættelse ofte slet ikke giver noget.

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

Hvis du vælger oversættelse, så husk, at peer'en nu ser én adresse for hver gæst, så enhver politik pr. klient i den fjerne ende er væk. Hvis du i stedet bevarer adresser, skal begge ender have gæstepræfikset i deres routing og politik, hvilket er mere arbejde og mere forudsigeligt.

IPv6 har brug for sin egen regel. En politik skrevet til IPv4 dækker ikke den anden familie, og en gæsteenhed med fungerende IPv6 bruger den gerne, mens din omhyggeligt rutede IPv4-sti står uvirksom. Enten rut begge familier, eller deaktiver IPv6 på gæstesegmentet, men antag ikke, at den kombinerede regel, du skrev, dækker det, enheden faktisk gør. Test med en klient, der har begge familier aktiveret, fordi det er det tilfælde, designet skal overleve. En bærbar computer, der foretrækker IPv6, ser rigtig ud i en test med kun IPv4 og lækker i den virkelige.

Test isolering, ikke kun browsing

Browsing beviser, at udgangen ændrede sig. Det beviser ikke, at segmentet er isoleret, og isolering er grunden til, at gæstenetværket findes. Fra en gæsteenhed kan du prøve at nå routerens administrationsgrænseflade, en betroet LAN-vært og en tjeneste, der bør afvises; alle tre bør fejle, og fejlen bør være en politikbeslutning snarere end en timeout, ingen kan forklare.

Test derefter en hoved-LAN-enhed og bekræft, at dens udgang ikke ændrede sig. Det er den regression, dette design oftest forårsager: en bred regel beregnet til gæster, anvendt på hver grænseflade, fordi matchet blev skrevet på destinationen.

Beslut til sidst, hvad der sker, når tunnelen er nede. Gæsterne får enten ingen internetadgang eller falder tilbage til en sti, du godkender, og at lade det være uafgjort betyder et stille fald tilbage til den normale forbindelse, hvilket er præcis den lækage, gæstepolitikken skulle forhindre. opskriften til routing af internettrafik gennemgår samme stivalg for en pfSense-baseret router.

DNS med oprindelse i routeren er det tilfælde, der overrasker folk sidst. Hvis gæsterne bruger routeren som deres resolver, følger routerens egne forespørgsler routerens rute snarere end gæstereglen, så opslag kan gå ud gennem den normale forbindelse, mens applikationstrafikken ikke gør. Hold segment, resolver og fejlpolitik i ét notat, og den næste person kan kontrollere alle tre uden at udlede designet igen.