El Wi-Fi de convidats continua usant la ruta principal: doneu-li la seva pròpia sortida

Vau crear una xarxa de convidats, hi vau afegir una ruta i els convidats continuen sortint per la vostra connexió normal a Internet. El túnel està aixecat, la LAN principal funciona i els dispositius de convidats informen d'una adreça dins del rang que vau assignar, així que res no sembla trencat. Normalment no falta una ruta sinó un selector: l'encaminador decideix el camí abans de considerar per quina interfície ha arribat el paquet, i tret que alguna cosa coincideixi explícitament amb el trànsit de convidats, aquest trànsit hereta el predeterminat. La solució és un segment, una regla de política i un camí de resposta, en aquest ordre.

El símptoma: els convidats continuen sortint per la WAN

La pista és l'adreça de sortida. Un dispositiu de convidat que arriba a Internet pel túnel informarà de l'adreça del proveïdor del túnel, i un que ha heretat el predeterminat informarà de la vostra connexió normal. Compareu un dispositiu de convidat i un de la LAN principal costat a costat, perquè el cas interessant és quan difereixen del que vau configurar i coincideixen entre ells.

La segona pista és l'absència de trànsit a la interfície del túnel mentre els convidats naveguen. Si els comptadors no es mouen, la política no s'ha aplicat mai, i ajustar el túnel mateix no pot ajudar.

Pas 1: un segment real, no només un nom

Un nom d'SSID no crea aïllament. Comproveu que la xarxa de convidats acaba en la seva pròpia interfície, VLAN o pont, i que el rang d'adreces és diferent del de la LAN de confiança. En molts punts d'accés de consum, l'SSID de convidats es pontetja al mateix segment que tota la resta, cosa que fa impossible la resta d'aquesta feina fins que això es corregeixi.

Després confirmeu el rang de convidats i el seu servidor DHCP, i manteniu la configuració del resolutor associada a aquest segment en lloc de a tot l'encaminador. Una subxarxa de convidats que només existeix com a comentari en una regla de tallafocs no és un segment, i l'encaminador no tindrà cap interfície amb què coincidir.

No pontetgeu els convidats a la LAN principal per fer més fàcil configurar la VPN. Això canvia l'aïllament que volíeu per un curtcircuit d'encaminament, i és la raó habitual per la qual una xarxa de convidats acaba amb accés a la impressora i al NAS.

Pas 2: seleccioneu el túnel per origen

Les taules d'encaminament es trien per destinació, així que una regla que diu que s'enviï 0.0.0.0/0 al túnel s'aplica a tothom. L'encaminament per política afegeix una segona dimensió: seleccioneu la taula per adreça d'origen. En un encaminador basat en Linux, això és una regla addicional més una taula dedicada, i l'ordre importa perquè guanya la primera regla que coincideix:

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

Aquesta última ordre respon la pregunta directament: quina interfície farà servir aquest origen per a aquesta destinació. Executeu-la abans i després del canvi i sabreu si la política ha entrat en vigor sense tocar cap navegador.

La majoria de firmware d'encaminador expressa el mateix com a regla d'interfície o selecció de passarel·la basada en origen. Sigui quina sigui la sintaxi que faci servir la vostra plataforma, el principi és idèntic: coincidiu amb la interfície d'entrada o el prefix d'origen, i després substituïu la ruta només per a aquesta coincidència. Una regla que coincideix per destinació no pot distingir un convidat d'un dispositiu de la llar.

Pas 3: el camí de resposta i la traducció

Un paquet que surt pel túnel ha de tornar. O el company del túnel coneix una ruta de tornada al prefix de convidats, o l'encaminador tradueix l'origen de convidats a l'adreça del túnel. Trieu-ne un i escriviu-lo, perquè les maneres de fallar es veuen diferents: una ruta de retorn que falta dóna una connexió que s'estableix i no respon mai, mentre que la traducció que falta sovint no produeix res.

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

Si trieu la traducció, recordeu que el company ara veu una sola adreça per a cada convidat, així que qualsevol política per client a l'extrem llunyà desapareix. Si en canvi preserveu les adreces, tots dos extrems necessiten el prefix de convidats en el seu encaminament i la seva política, cosa que és més feina i més predictible.

IPv6 necessita la seva pròpia regla. Una política escrita per a IPv4 no cobreix l'altra família, i un dispositiu de convidat amb IPv6 funcionant l'usarà de bon grat mentre el vostre camí IPv4 acuradament encaminat queda inactiu. Encamineu les dues famílies o desactiveu IPv6 al segment de convidats, però no suposeu que la regla combinada que vau escriure cobreix el que el dispositiu fa realment. Proveu amb un client que tingui les dues famílies activades, perquè aquest és el cas que el disseny ha de suportar. Un portàtil que prefereix IPv6 sembla correcte en una prova només IPv4 i filtra en la real.

Proveu l'aïllament, no només la navegació

Navegar demostra que la sortida ha canviat. No demostra que el segment estigui aïllat, i l'aïllament és la raó per la qual existeix la xarxa de convidats. Des d'un dispositiu de convidat, proveu d'arribar a la interfície d'administració de l'encaminador, a un equip de confiança de la LAN i a un servei que hauria de ser refusat; tots tres haurien de fallar, i el fracàs hauria de ser una decisió de política i no un temps d'espera que ningú no pot explicar.

Després proveu un dispositiu de la LAN principal i confirmeu que la seva sortida no ha canviat. Aquesta és la regressió que aquest disseny causa més sovint: una regla àmplia pensada per als convidats, aplicada a totes les interfícies perquè la coincidència es va escriure per destinació.

Finalment, decidiu què passa quan el túnel està caigut. Els convidats o no tenen Internet o tornen a un camí que aproveu, i deixar-ho indecís significa una tornada silenciosa a la connexió normal, que és exactament la fuita que la política de convidats havia d'evitar. la recepta d'encaminament del trànsit d'Internet explica la mateixa selecció de camí per a un encaminador basat en pfSense.

El DNS originat a l'encaminador és el cas que sorprèn la gent al final. Si els convidats fan servir l'encaminador com a resolutor, les consultes del mateix encaminador segueixen la ruta de l'encaminador i no la regla de convidats, així que les cerques poden sortir per la connexió normal mentre el trànsit d'aplicacions no ho fa. Guardeu el segment, el resolutor i la política de fallada en una nota, i la propera persona podrà comprovar els tres sense tornar a derivar el disseny.