Wi-Fi pentru oaspeți folosește în continuare ruta principală: dă-i propria ieșire

Ai creat o rețea pentru oaspeți, ai adăugat o rută pentru ea, iar oaspeții ies în continuare prin conexiunea ta normală la internet. Tunelul este activ, LAN-ul principal funcționează, iar dispozitivele oaspeților raportează o adresă din intervalul pe care l-ai atribuit, așa că nimic nu pare stricat. De obicei lipsește nu o rută, ci un selector: routerul decide calea înainte de a lua în considerare prin ce interfață a sosit pachetul, iar dacă nimic nu corespunde explicit traficului oaspeților, acel trafic moștenește valoarea implicită. Soluția este un segment, o regulă de politică și o cale de răspuns, în această ordine.

Simptomul: oaspeții ies în continuare prin WAN

Indiciul este adresa de ieșire. Un dispozitiv al oaspeților care ajunge la internet prin tunel va raporta adresa furnizorului tunelului, iar unul care a moștenit valoarea implicită va raporta conexiunea ta normală. Compară alături un dispozitiv al oaspeților și un dispozitiv din LAN-ul principal, pentru că cazul interesant este când diferă de ceea ce ai configurat și se potrivesc între ele.

Al doilea indiciu este absența oricărui trafic pe interfața tunelului în timp ce oaspeții navighează. Dacă contoarele nu se mișcă, politica nu a fost niciodată aplicată, iar ajustarea tunelului în sine nu poate ajuta.

Pasul 1: un segment real, nu doar un nume

Un nume de SSID nu creează izolare. Verifică faptul că rețeaua oaspeților se termină pe propria interfață, VLAN sau punte, și că intervalul de adrese este diferit de LAN-ul de încredere. Pe multe puncte de acces pentru consumatori, SSID-ul oaspeților este pus în punte în același segment ca tot restul, ceea ce face imposibil restul acestei lucrări până când acest lucru nu este corectat.

Apoi confirmă intervalul oaspeților și serverul DHCP al acestuia, și păstrează setările resolverului asociate cu acel segment, nu cu întregul router. O subrețea a oaspeților care există doar ca un comentariu într-o regulă de firewall nu este un segment, iar routerul nu va avea nicio interfață cu care să se potrivească.

Nu pune oaspeții în punte în LAN-ul principal pentru a face VPN-ul mai ușor de configurat. Asta schimbă izolarea pe care o doreai cu o scurtătură de rutare, și este motivul obișnuit pentru care o rețea de oaspeți ajunge cu acces la imprimantă și la NAS.

Pasul 2: selectează tunelul după sursă

Tabelele de rutare sunt alese după destinație, așa că o regulă care spune «trimite 0.0.0.0/0 la tunel» se aplică tuturor. Rutarea pe politică adaugă o a doua dimensiune: selectează tabelul după adresa sursă. Pe un router bazat pe Linux, aceasta este o regulă suplimentară plus un tabel dedicat, iar ordinea contează pentru că câștigă prima regulă care se potrivește:

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

Acea ultimă comandă răspunde direct la întrebare: ce interfață va folosi această sursă pentru această destinație. Rulează-o înainte și după modificare și vei ști dacă politica a intrat în vigoare fără să atingi un browser.

Majoritatea firmware-urilor de router exprimă același lucru ca o regulă de interfață sau o selecție de gateway bazată pe sursă. Indiferent de sintaxa pe care o folosește platforma ta, principiul este identic: potrivește interfața de intrare sau prefixul sursei, apoi suprascrie ruta doar pentru acea potrivire. O regulă potrivită după destinație nu poate distinge un oaspete de un dispozitiv casnic.

Pasul 3: calea de răspuns și traducerea

Un pachet care iese prin tunel trebuie să se întoarcă. Fie partenerul tunelului cunoaște o rută înapoi la prefixul oaspeților, fie routerul traduce sursa oaspeților în adresa tunelului. Alege una și noteaz-o, pentru că modurile de eșec arată diferit: o cale de întoarcere lipsă dă o conexiune care se stabilește și nu răspunde niciodată, în timp ce o traducere lipsă adesea nu produce nimic.

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

Dacă alegi traducerea, amintește-ți că partenerul vede acum o singură adresă pentru fiecare oaspete, așa că orice politică pe client la capătul îndepărtat dispare. Dacă păstrezi adresele, ambele capete au nevoie de prefixul oaspeților în rutarea și politica lor, ceea ce înseamnă mai multă muncă și este mai previzibil.

IPv6 are nevoie de propria regulă. O politică scrisă pentru IPv4 nu acoperă cealaltă familie, iar un dispozitiv al oaspeților cu IPv6 funcțional îl va folosi bucuros în timp ce calea IPv4 atent rutată stă neutilizată. Rutează ambele familii sau dezactivează IPv6 pe segmentul oaspeților, dar nu presupune că regula combinată pe care ai scris-o acoperă ceea ce face dispozitivul de fapt. Testează cu un client care are ambele familii activate, pentru că acesta este cazul pe care designul trebuie să-l reziste. Un laptop care preferă IPv6 pare corect într-un test doar IPv4 și pierde în cel real.

Testează izolarea, nu doar navigarea

Navigarea dovedește că ieșirea s-a schimbat. Nu dovedește că segmentul este izolat, iar izolarea este motivul pentru care există rețeaua oaspeților. Dintr-un dispozitiv al oaspeților, încearcă să ajungi la interfața de administrare a routerului, la un host din LAN-ul de încredere și la un serviciu care ar trebui refuzat; toate trei ar trebui să eșueze, iar eșecul ar trebui să fie o decizie de politică, nu un timp de așteptare pe care nimeni nu-l poate explica.

Apoi testează un dispozitiv din LAN-ul principal și confirmă că ieșirea lui nu s-a schimbat. Aceasta este regresia pe care acest design o provoacă cel mai des: o regulă largă destinată oaspeților, aplicată fiecărei interfețe pentru că potrivirea a fost scrisă pe destinație.

În final, decide ce se întâmplă când tunelul este oprit. Oaspeții fie nu au internet, fie trec pe o cale pe care o aprobi, iar lăsarea acestui lucru nedecis înseamnă o revenire silențioasă la conexiunea normală, care este exact scurgerea pe care politica oaspeților trebuia să o prevină. Rețeta de rutare a traficului de internet parcurge aceeași selecție a căii pentru un router bazat pe pfSense.

DNS-ul originat în router este cazul care surprinde oamenii ultimul. Dacă oaspeții folosesc routerul ca resolver, interogările routerului însuși urmează ruta routerului în loc de regula oaspeților, așa că căutările pot ieși prin conexiunea normală în timp ce traficul aplicației nu iese. Ține segmentul, resolverul și politica de eșec într-o singură notă, iar următoarea persoană va putea verifica toate trei fără să rederive designul.