Svečių Wi-Fi vis dar naudoja pagrindinį maršrutą: suteikite jam atskirą išėjimą

Sukūrėte svečių tinklą, pridėjote jam maršrutą, o svečiai vis tiek išeina per įprastą interneto ryšį. Tunelis veikia, pagrindinis LAN veikia, o svečių įrenginiai praneša adresą iš jūsų priskirto diapazono, todėl niekas neatrodo sugedę. Dažniausiai trūksta ne maršruto, o selektoriaus: maršrutizatorius nusprendžia kelią prieš tai, kai atsižvelgia, per kurią sąsają atėjo paketas, ir jei niekas aiškiai neatitinka svečių srauto, tas srautas paveldi numatytąją reikšmę. Sprendimas yra segmentas, politikos taisyklė ir atsakymo kelias, būtent tokia tvarka.

Simptomas: svečiai vis dar išeina per WAN

Požymis yra išėjimo adresas. Svečių įrenginys, pasiekiantis internetą per tunelį, praneš tunelio teikėjo adresą, o paveldėjęs numatytąjį – jūsų įprastą ryšį. Palyginkite greta svečių įrenginį ir pagrindinio LAN įrenginį, nes įdomus atvejis yra tada, kai jie skiriasi nuo to, ką sukonfigūravote, ir sutampa tarpusavyje.

Antrasis požymis yra bet kokio srauto tunelio sąsajoje nebuvimas, kol svečiai naršo. Jei skaitikliai nejuda, politika niekada nebuvo pritaikyta, o paties tunelio reguliavimas negali padėti.

1 žingsnis: tikras segmentas, o ne tik pavadinimas

SSID pavadinimas nesukuria izoliacijos. Patikrinkite, ar svečių tinklas baigiasi savo sąsajoje, VLAN ar tiltu, ir ar adresų diapazonas skiriasi nuo patikimo LAN. Daugelyje vartotojiškų prieigos taškų svečių SSID sujungiamas tiltu į tą patį segmentą kaip ir visa kita, todėl likęs darbas neįmanomas, kol tai nebus ištaisyta.

Tada patvirtinkite svečių diapazoną ir jo DHCP serverį, o sprendiklio nustatymus laikykite susietus su tuo segmentu, o ne su visu maršrutizatoriumi. Svečių potinklis, egzistuojantis tik kaip ugniasienės taisyklės komentaras, nėra segmentas, ir maršrutizatorius neturės jokios sąsajos, su kuria derinti.

Nejunkite svečių į pagrindinį LAN, kad būtų lengviau konfigūruoti VPN. Tai iškeičia norimą izoliaciją į maršrutizavimo trumpinį, ir tai yra įprasta priežastis, kodėl svečių tinklas galiausiai gauna prieigą prie spausdintuvo ir NAS.

2 žingsnis: pasirinkite tunelį pagal šaltinį

Maršrutizavimo lentelės parenkamos pagal paskirties vietą, todėl taisyklė „siųsk 0.0.0.0/0 į tunelį“ galioja visiems. Politika pagrįstas maršrutizavimas prideda antrą dimensiją: pasirinkite lentelę pagal šaltinio adresą. Linux pagrindu veikiančiame maršrutizatoriuje tai papildoma taisyklė ir atskira lentelė, o tvarka svarbi, nes laimi pirmoji atitinkanti taisyklė:

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

Paskutinė komanda tiesiogiai atsako į klausimą: kurią sąsają šis šaltinis naudos šiai paskirties vietai. Paleiskite ją prieš ir po pakeitimo ir žinosite, ar politika įsigaliojo, neliesdami naršyklės.

Dauguma maršrutizatorių programinės įrangos tą patį išreiškia kaip sąsajos taisyklę arba šaltiniu pagrįstą šliuzo pasirinkimą. Kad ir kokią sintaksę naudotų jūsų platforma, principas tas pats: suderinkite su įeinančia sąsaja arba šaltinio priešdėliu, tada pakeiskite maršrutą tik tam atitikimui. Taisyklė, suderinta pagal paskirties vietą, negali atskirti svečio nuo namų įrenginio.

3 žingsnis: atsakymo kelias ir vertimas

Paketas, išėjęs per tunelį, turi grįžti. Arba tunelio partneris žino kelią atgal į svečių priešdėlį, arba maršrutizatorius išverčia svečių šaltinį į tunelio adresą. Pasirinkite vieną ir užsirašykite, nes gedimų režimai atrodo skirtingai: trūkstamas grįžimo kelias duoda ryšį, kuris užmezgamas ir niekada neatsako, o trūkstamas vertimas dažnai neduoda nieko.

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

Jei pasirinksite vertimą, atminkite, kad partneris dabar mato vieną adresą visiems svečiams, todėl bet kokia politika pagal klientą tolimajame gale išnyksta. Jei išsaugosite adresus, abiems galams reikia svečių priešdėlio jų maršrutizavime ir politikoje, o tai daugiau darbo ir labiau nuspėjama.

IPv6 reikia savo taisyklės. IPv4 parašyta politika neapima kitos šeimos, o svečių įrenginys su veikiančiu IPv6 mielai jį naudos, kol jūsų kruopščiai maršrutizuotas IPv4 kelias stovi be darbo. Maršrutizuokite abi šeimas arba išjunkite IPv6 svečių segmente, bet ne manykite, kad parašyta sujungta taisyklė apima tai, ką įrenginys iš tikrųjų daro. Testuokite su klientu, kuriame įjungtos abi šeimos, nes tai yra atvejis, kurį dizainas turi atlaikyti. Nešiojamasis kompiuteris, kuris teikia pirmenybę IPv6, atrodo teisingai tik IPv4 teste ir nuteka tikrame.

Testuokite izoliaciją, o ne tik naršymą

Naršymas įrodo, kad išėjimas pasikeitė. Tai neįrodo, kad segmentas izoliuotas, o izoliacija yra priežastis, kodėl svečių tinklas egzistuoja. Iš svečių įrenginio pabandykite pasiekti maršrutizatoriaus administravimo sąsają, patikimo LAN mazgą ir paslaugą, kurios turėtų būti atsisakyta; visi trys turėtų nepavykti, o nesėkmė turėtų būti politikos sprendimas, o ne laiko limitas, kurio niekas negali paaiškinti.

Tada testuokite pagrindinio LAN įrenginį ir patvirtinkite, kad jo išėjimas nepasikeitė. Tai regresija, kurią šis dizainas sukelia dažniausiai: plati taisyklė, skirta svečiams, pritaikyta kiekvienai sąsajai, nes atitikimas buvo parašytas pagal paskirties vietą.

Galiausiai nuspręskite, kas nutinka, kai tunelis yra išjungtas. Svečiai arba negauna interneto, arba grįžta į jūsų patvirtintą kelią, o palikus tai nenuspręsta reiškia tylų grįžimą prie įprasto ryšio, o tai yra būtent tas nutekėjimas, kurį svečių politika turėjo užkirsti. Interneto srauto maršrutizavimo receptas eina per tą patį kelio pasirinkimą pfSense pagrindu veikiančiam maršrutizatoriui.

Iš maršrutizatoriaus kilęs DNS yra atvejis, kuris žmones nustebina paskiausiai. Jei svečiai naudoja maršrutizatorių kaip savo sprendiklį, paties maršrutizatoriaus užklausos seka maršrutizatoriaus maršrutą, o ne svečių taisyklę, todėl paieškos gali išeiti per įprastą ryšį, nors programos srautas neišeina. Laikykite segmentą, sprendiklį ir gedimo politiką vienoje pastaboje, ir kitas žmogus galės patikrinti visus tris iš naujo neišvesdamas dizaino.