Gjest-Wi-Fi brukar framleis hovudruta: gje det sin eigen utgang

Du oppretta eit gjestenettverk, la til ei rute for det, og gjestene går framleis ut gjennom den vanlege internettilkoplinga di. Tunnelen er oppe, hovud-LANet fungerer, og gjesteiningane rapporterer ei adresse i området du tildelte, så ingenting ser øydelagt ut. Det som vanlegvis manglar er ikkje ei rute, men ein veljar: rutaren avgjer vegen før han vurderer kva grensesnitt pakken kom inn på, og med mindre noko eksplisitt samsvarar med gjestetrafikken, arvar den trafikken standardverdien. Løysinga er eit segment, ein policyregel og ein returveg, i den rekkjefølgja.

Symptomet: gjestene går framleis ut gjennom WAN

Teiknet er utgangsadressa. Ei gjesteining som når internett gjennom tunnelen, vil rapportere adressa til tunnelleverandøren, og ei som arva standardverdien vil rapportere den vanlege tilkoplinga di. Samanlikn ei gjesteining og ei hovud-LAN-eining side ved side, fordi det interessante tilfellet er når dei avvik frå det du konfigurerte og samsvarar med kvarandre.

Det andre teiknet er fråværet av all trafikk på tunnelgrensesnittet medan gjestene surfar. Viss teljarane ikkje rører seg, vart policyen aldri brukt, og å justere sjølve tunnelen kan ikkje hjelpe.

Steg 1: eit ekte segment, ikkje berre eit namn

Eit SSID-namn skapar ikkje isolasjon. Sjekk at gjestenettverket endar på sitt eige grensesnitt, VLAN eller bru, og at adresseområdet er forskjellig frå det klarerte LANet. På mange forbrukaraksesspunkt blir gjeste-SSIDet brua inn i same segment som alt anna, noko som gjer resten av dette arbeidet umogleg til det er retta.

Stadfest deretter gjesteområdet og DHCP-tenaren, og hald resolverinnstillingane knytte til det segmentet i staden for heile rutaren. Eit gjestesubnett som berre finst som ein kommentar i ein brannmurregel er ikkje eit segment, og rutaren vil ikkje ha noko grensesnitt å matche mot.

Ikkje bru gjestene inn i hovud-LANet for å gjere VPN-en lettare å konfigurere. Det byter isolasjonen du ønskte mot ein ruteomveg, og det er den vanlege grunnen til at eit gjestenettverk endar opp med tilgang til skrivaren og NASen.

Steg 2: vel tunnelen etter kjelde

Rutetabellar blir valde etter destinasjon, så ein regel som seier «send 0.0.0.0/0 til tunnelen» gjeld for alle. Policyrutering legg til ein andre dimensjon: vel tabellen etter kjeldeadresse. På ein Linux-basert rutar er det ein ekstra regel pluss ein dedikert tabell, og rekkjefølgja betyr noko fordi den første samsvarande regelen vinn:

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 svarar direkte på spørsmålet: kva grensesnitt denne kjelda vil bruke for denne destinasjonen. Køyr han før og etter endringa, og du veit om policyen tredde i kraft utan å røre ein nettlesar.

Dei fleste rutarfastvarar uttrykkjer det same som ein grensesnittregel eller eit kjeldebasert gatewayval. Uansett kva syntaks plattformen din brukar, er prinsippet identisk: match inngangsgrensesnittet eller kjeldeperfikset, og overstyr deretter ruta berre for den matchen. Ein regel som matchar etter destinasjon kan ikkje skilje ein gjest frå ei hushaldseining.

Steg 3: returvegen og omsetjinga

Ein pakke som går ut gjennom tunnelen må kome tilbake. Anten kjenner tunnelpartnaren ei rute tilbake til gjesteperfikset, eller så omset rutaren gjestekjelda til tunneladressa. Vel éin og skriv han ned, fordi feilmodusane ser forskjellige ut: ein manglande returveg gir ei tilkopling som blir oppretta og aldri svarar, medan ei manglande omsetjing ofte ikkje gir noko i det heile.

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

Viss du vel omsetjing, hugs at partnaren no ser éi adresse for kvar gjest, så all per-klient-policy i den fjerne enden forsvinn. Viss du held på adressene i staden, treng begge endar gjesteperfikset i ruteringa og policyen sin, noko som er meir arbeid og meir føreseieleg.

IPv6 treng sin eigen regel. Ein policy skriven for IPv4 dekkjer ikkje den andre familien, og ei gjesteining med fungerande IPv6 vil gjerne bruke han medan den nøye ruta IPv4-bana di står ubrukt. Rut båe familiane eller deaktiver IPv6 på gjestesegmentet, men ikkje anta at den kombinerte regelen du skreiv dekkjer det eininga faktisk gjer. Test med ein klient som har båe familiane aktiverte, fordi det er tilfellet designet må tole. Ein berbar PC som føretrekkjer IPv6 ser riktig ut i ein IPv4-berre test og lek i den verkelege.

Test isolasjon, ikkje berre surfing

Surfing beviser at utgangen endra seg. Det beviser ikkje at segmentet er isolert, og isolasjon er grunnen til at gjestenettverket finst. Frå ei gjesteining, prøv å nå administrasjonsgrensesnittet til rutaren, ein vert i det klarerte LANet og ein teneste som skal avvisast; alle tre skal mislykkast, og feilen skal vere ein policyavgjerd i staden for ein timeout ingen kan forklare.

Test deretter ei hovud-LAN-eining og stadfest at utgangen ikkje endra seg. Det er regresjonen dette designet oftast fører til: ein brei regel meint for gjester, brukt på kvart grensesnitt fordi matchen vart skriven på destinasjonen.

Til slutt, avgjer kva som skjer når tunnelen er nede. Gjestene får anten ingen internett eller fell tilbake til ein bane du godkjenner, og å la det vere uavgjort betyr eit stille tilbakefall til den vanlege tilkoplinga, som er nøyaktig lekkasjen gjestepolicyen skulle hindre. Oppskrifta for rutering av internettrafikk går gjennom det same banevalet for ein pfSense-basert rutar.

DNS som kjem frå rutaren er tilfellet som overraskar folk sist. Viss gjestene brukar rutaren som resolver, følgjer dei eigne spørjingane til rutaren ruta til rutaren i staden for gjesteregelen, så oppslag kan gå ut gjennom den vanlege tilkoplinga medan applikasjonstrafikken ikkje gjer det. Hald segmentet, resolveren og feilpolicyen i eitt notat, og neste person kan sjekke alle tre utan å utleie designet på nytt.