Külalis-Wi-Fi jätkab põhitee kasutamist: anna sellele oma väljapääs

Lõite külalisvõrgu, lisasite sellele tee, ja külalised väljuvad ikka teie tavalisest internetiühendusest. Tunnel on üleval, põhi-LAN töötab ja külalisseadmed teatavad teie määratud vahemikku jääva aadressi, nii et miski ei tundu katki olevat. Tavaliselt ei puudu tee, vaid valija: ruuter otsustab tee enne, kui arvestab, millise liidese kaudu pakett saabus, ja kui miski ei vasta külalisliiklusele selgesõnaliselt, pärib see liiklus vaikeväärtuse. Lahendus on segment, poliitikareegel ja vastustee, just selles järjekorras.

Sümptom: külalised väljuvad ikka WAN-i kaudu

Vihjeks on väljumisaadress. Külalisseade, mis jõuab internetti tunneli kaudu, teatab tunneliteenuse pakkuja aadressi, ja seade, mis päris vaikeväärtuse, teatab teie tavalisest ühendusest. Võrrelge külalisseadet ja põhi-LAN-i seadet kõrvuti, sest huvitav juhtum on see, kui need erinevad sellest, mida seadistasite, ja sarnanevad üksteisega.

Teine vihje on igasuguse liikluse puudumine tunneli liidesel, kui külalised sirvivad. Kui loendurid ei liigu, ei rakendatud poliitikat kunagi, ja tunneli enda häälestamine ei aita.

Samm 1: tõeline segment, mitte ainult nimi

SSID-i nimi ei loo isolatsiooni. Kontrollige, et külalisvõrk lõpeb oma liidesel, VLAN-is või sillal, ja et aadressivahemik erineb usaldusväärsest LAN-ist. Paljudel tarbijate juurdepääsupunktidel sillatakse külalis-SSID kõige muuga samasse segmenti, mis teeb ülejäänud töö võimatuks, kuni see on parandatud.

Seejärel kinnitage külalisvahemik ja selle DHCP-server ning hoidke nimeserveri seaded seotud selle segmendiga, mitte kogu ruuteriga. Külalisalamvõrk, mis eksisteerib ainult tulemüürireegli kommentaarina, ei ole segment, ja ruuteril ei ole ühtegi liidest, millega vastata.

Ärge sillutage külalisi põhi-LAN-i, et VPN-i oleks lihtsam seadistada. See vahetab soovitud isolatsiooni marsruutimise otsetee vastu, ja see on tavaline põhjus, miks külalisvõrk satub printerile ja NAS-ile ligi pääsema.

Samm 2: valige tunnel lähteaadressi järgi

Marsruutimistabelid valitakse sihtkoha järgi, nii et reegel «saada 0.0.0.0/0 tunnelisse» kehtib kõigile. Poliitikapõhine marsruutimine lisab teise mõõtme: valige tabel lähteaadressi järgi. Linuxil põhineval ruuteril on see lisareegel pluss sihtotstarbeline tabel, ja järjekord on oluline, sest võidab esimene sobiv reegel:

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

See viimane käsk vastab küsimusele otse: millist liidest see lähteallikas selle sihtkoha jaoks kasutab. Käivitage see enne ja pärast muudatust ning teate, kas poliitika mõjus, ilma brauserit puutumata.

Enamik ruuteri püsivarasid väljendab sama asja liidese reeglina või lähtepõhise lüüsivalikuna. Ükskõik millist süntaksit teie platvorm kasutab, on põhimõte sama: sobitage sissetulev liides või lähteprefiks ja seejärel alistage marsruut ainult selle sobivuse jaoks. Sihtkoha järgi sobitatud reegel ei suuda eristada külalist koduseadmest.

Samm 3: vastustee ja teisendus

Tunnelist väljuv pakett peab tagasi tulema. Kas tunnelipartner teab teed tagasi külalisprefiksisse, või teisendab ruuter külalisallika tunneli aadressiks. Valige üks ja kirjutage see üles, sest tõrkerežiimid näevad erinevad välja: puuduv tagasitee annab ühenduse, mis luuakse ja ei vasta kunagi, samas kui puuduv teisendus ei anna sageli üldse midagi.

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

Kui valite teisenduse, pidage meeles, et partner näeb nüüd kõigi külaliste jaoks ühte aadressi, nii et igasugune kliendipõhine poliitika kaugemas otsas kaob. Kui säilitate aadressid, vajavad mõlemad otsad külalisprefiksi oma marsruutimises ja poliitikas, mis on rohkem tööd ja paremini etteaimatav.

IPv6 vajab oma reeglit. IPv4 jaoks kirjutatud poliitika ei kata teist perekonda, ja töötava IPv6-ga külalisseade kasutab seda hea meelega, samal ajal kui teie hoolikalt marsruuditud IPv4-tee seisab jõude. Marsruutige mõlemad perekonnad või lülitage külalisegmendis IPv6 välja, kuid ärge eeldage, et kirjutatud kombineeritud reegel katab selle, mida seade tegelikult teeb. Testige kliendiga, millel on mõlemad perekonnad lubatud, sest see on juhtum, millele disain peab vastu pidama. Sülearvuti, mis eelistab IPv6-te, näib IPv4-ainult testis õige ja lekib tegelikus.

Testige isolatsiooni, mitte ainult sirvimist

Sirvimine tõestab, et väljapääs muutus. See ei tõesta, et segment on isoleeritud, ja isolatsioon on põhjus, miks külalisvõrk olemas on. Proovige külalisseadmest pääseda ruuteri haldusliidesele, usaldusväärse LAN-i hostile ja teenusele, mida tuleks keelduda; kõik kolm peaksid ebaõnnestuma ja ebaõnnestumine peaks olema poliitikaotsus, mitte ajastus, mida keegi seletada ei oska.

Seejärel testige põhi-LAN-i seadet ja kinnitage, et selle väljapääs ei muutunud. See on regressioon, mida see disain kõige sagedamini põhjustab: külalistele mõeldud lai reegel, mida rakendatakse igale liidesele, sest sobivus kirjutati sihtkoha järgi.

Lõpuks otsustage, mis juhtub, kui tunnel on maas. Külalised kas ei saa internetti või lülituvad teie heakskiidetud teele, ja selle otsustamata jätmine tähendab vaikset tagasilangust tavalisse ühendusse, mis on täpselt see leke, mida külalispoliitika pidi ära hoidma. Internetiliikluse marsruutimise retsept käib läbi sama teevaliku pfSense-põhise ruuteri jaoks.

Ruuteri enda DNS on juhtum, mis üllatab inimesi viimasena. Kui külalised kasutavad ruuterit oma nimeserverina, järgivad ruuteri enda päringud ruuteri marsruuti, mitte külalisreeglit, nii et otsingud võivad väljuda tavalisest ühendusest, samal ajal kui rakenduse liiklus ei välju. Hoidke segment, nimeserver ja tõrkepoliitika ühes märkmes, ja järgmine inimene saab kõiki kolme kontrollida ilma disaini uuesti tuletamata.