Vieras-Wi-Fi käyttää yhä pääreittiä: anna sille oma ulospääsy

Loit vierasverkon, lisäsit sille reitin, ja vieraat lähtevät silti tavallisen internet-yhteytesi kautta. Tunneli on pystyssä, pää-LAN toimii ja vieraslaitteet ilmoittavat antamasi alueen osoitteen, joten mikään ei näytä rikkinäiseltä. Yleensä puuttuu reitti, mutta valitsin: reititin päättää polun ennen kuin se ottaa huomioon, miltä liitännältä paketti saapui, ja ellei jokin vastaa nimenomaisesti vierasliikennettä, se liikenne perii oletuksen. Korjaus on segmentti, käytäntösääntö ja paluureitti, tässä järjestyksessä.

Oire: vieraat lähtevät yhä WANin kautta

Tunnusmerkki on lähtöosoite. Tunnelin kautta internetiin pääsevä vieraslaite ilmoittaa tunnelin tarjoajan osoitteen, ja oletuksen perinyt laite ilmoittaa tavallisen yhteytesi. Vertaa vieraslaitetta ja pää-LANin laitetta rinnakkain, sillä kiinnostava tapaus on, kun ne eroavat määrittämästäsi ja vastaavat toisiaan.

Toinen tunnusmerkki on kaiken liikenteen puuttuminen tunnelin liitännältä vieraiden selatessa. Jos laskurit eivät liiku, käytäntöä ei koskaan sovellettu, eikä itse tunnelin säätäminen voi auttaa.

Vaihe 1: todellinen segmentti, ei vain nimi

SSID-nimi ei luo eristystä. Tarkista, että vierasverkko päättyy omaan liitäntäänsä, VLANiin tai siltaan, ja että osoitealue eroaa luotetusta LANista. Monissa kuluttajien tukiasemissa vieras-SSID sillataan samaan segmenttiin kaiken muun kanssa, mikä tekee lopputyön mahdottomaksi, kunnes se korjataan.

Vahvista sitten vierasalue ja sen DHCP-palvelin ja pidä nimipalvelimen asetukset kyseiseen segmenttiin liitettyinä eikä koko reitittimeen. Vierasaliverkko, joka on olemassa vain palomuurisäännön kommenttina, ei ole segmentti, eikä reitittimellä ole yhtään liitäntää, johon sovittaa.

Älä sillaa vieraita pää-LANiin, jotta VPN olisi helpompi määrittää. Se vaihtaa haluamasi eristyksen reititysoikotiehen, ja se on tavallinen syy siihen, että vierasverkko päätyy käsiksi tulostimeen ja NASiin.

Vaihe 2: valitse tunneli lähteen mukaan

Reititystaulut valitaan kohteen mukaan, joten sääntö «lähetä 0.0.0.0/0 tunneliin» koskee kaikkia. Käytäntöreititys lisää toisen ulottuvuuden: valitse taulu lähdeosoitteen mukaan. Linux-pohjaisessa reitittimessä se on lisäsääntö ja oma taulu, ja järjestys on tärkeä, koska ensimmäinen täsmäävä sääntö voittaa:

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

Viimeinen komento vastaa kysymykseen suoraan: mitä liitäntää tämä lähde käyttää tälle kohteelle. Aja se ennen muutosta ja sen jälkeen, niin tiedät, vaikuttiko käytäntö, koskematta selaimeen.

Useimmat reitittimien laiteohjelmistot ilmaisevat saman liitäntäsääntönä tai lähtöperusteisena yhdyskäytävän valintana. Riippumatta siitä, mitä syntaksia alustasi käyttää, periaate on sama: sovita saapuva liitäntä tai lähdeprefiksi ja ohita sitten reitti vain kyseiselle osumalle. Kohteen mukaan sovitettu sääntö ei voi erottaa vierasta kotitalouden laitteesta.

Vaihe 3: paluureitti ja käännös

Tunnelista lähtevän paketin on tultava takaisin. Joko tunnelin vastapuoli tuntee reitin takaisin vierasalueelle, tai reititin kääntää vieraslähteen tunnelin osoitteeksi. Valitse yksi ja kirjoita se, koska vikamuodot näyttävät erilaisilta: puuttuva paluureitti antaa yhteyden, joka muodostuu eikä koskaan vastaa, kun taas puuttuva käännös ei usein tuota mitään.

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

Jos valitset käännöksen, muista, että vastapuoli näkee nyt yhden osoitteen kaikille vieraille, joten kaikki asiakaskohtainen käytäntö kauhaussa katoaa. Jos säilytät osoitteet, molemmat päät tarvitsevat vierasalueen prefiksin reititykseensä ja käytäntöönsä, mikä on enemmän työtä ja ennustettavampaa.

IPv6 tarvitsee oman sääntönsä. IPv4:lle kirjoitettu käytäntö ei kata toista perhettä, ja toimivalla IPv6:lla varustettu vieraslaite käyttää sitä mielellään, kun huolellisesti reititetty IPv4-polku on käyttämättä. Reititä molemmat perheet tai poista IPv6 käytöstä vierassegmentissä, mutta älä oleta, että kirjoittamasi yhdistetty sääntö kattaa sen, mitä laite todella tekee. Testaa asiakkaalla, jolla on molemmat perheet käytössä, koska juuri se tapaus suunnittelun on kestettävä. Kannettava, joka suosii IPv6:ta, näyttää oikealta vain IPv4-testissä ja vuotaa todellisessa.

Testaa eristystä, älä vain selailua

Selailu todistaa, että lähtö vaihtui. Se ei todista, että segmentti on eristetty, ja eristys on syy vierasverkon olemassaoloon. Yritä vieraslaitteesta päästä reitittimen hallintaliitäntään, luotetun LANin isäntään ja palveluun, joka pitäisi hylätä; kaikkien kolmen pitäisi epäonnistua, ja epäonnistumisen pitäisi olla käytäntöpäätös eikä aikakatkaisu, jota kukaan ei osaa selittää.

Testaa sitten pää-LANin laite ja varmista, että sen lähtö ei muuttunut. Se on regressio, jonka tämä suunnittelu useimmin aiheuttaa: vieraille tarkoitettu laaja sääntö, jota sovelletaan kaikkiin liitäntöihin, koska osuma kirjoitettiin kohteen mukaan.

Päätä lopuksi, mitä tapahtuu, kun tunneli on alhaalla. Vieraat joko jäävät ilman internetiä tai siirtyvät hyväksymällesi polulle, ja sen päättämättä jättäminen tarkoittaa hiljaista paluuta tavalliseen yhteyteen, mikä on juuri se vuoto, jonka vieraskäytäntö oli tarkoitettu estämään. Internetliikenteen reititysohje käy läpi saman polun valinnan pfSense-pohjaiselle reitittimelle.

Reitittimen oma DNS on tapaus, joka yllättää ihmiset viimeisenä. Jos vieraat käyttävät reititintä nimipalvelimenaan, reitittimen omat kyselyt seuraavat reitittimen reittiä eikä vierassääntöä, joten haut voivat lähteä tavallisesta yhteydestä, vaikka sovellusliikenne ei lähde. Pidä segmentti, nimipalvelin ja vikakäytäntö yhdessä muistiinpanossa, niin seuraava henkilö voi tarkistaa kaikki kolme johtamatta suunnittelua uudelleen.