Гасцявы Wi-Fi працягвае ісці праз асноўны маршрут: дайце яму ўласны выхад

Вы стварылі гасцявую сетку, дадалі для яе маршрут, а госці ўсё роўна выходзяць праз ваша звычайнае падключэнне да інтэрнэту. Тунель узняты, асноўная LAN працуе, а гасцявыя прылады паведамляюць адрас у дыяпазоне, які вы прызначылі, таму нішто не выглядае зламаным. Часцей за ўсё не хапае не маршруту, а селектара: роўтар выбірае шлях перш, чым улічыць, праз які інтэрфейс прыйшоў пакет, і калі нешта відавочна не супадае з гасцявым трафікам, гэты трафік атрымлівае ў спадчыну тыповы маршрут. Выпраўленне — гэта сегмент, правіла палітыкі і шлях адказу, менавіта ў такім парадку.

Сімптом: госці ўсё яшчэ выходзяць праз WAN

Падказка — адрас выхаду. Гасцявая прылада, якая трапляе ў інтэрнэт праз тунель, паведаміць адрас пастаўшчыка тунеля, а тая, што атрымала ў спадчыну тыповы маршрут, паведаміць ваша звычайнае падключэнне. Параўнайце гасцявую прыладу і прыладу асноўнай LAN побач, бо цікавы выпадак — калі яны адрозніваюцца ад таго, што вы наладзілі, і супадаюць адна з адной.

Другая падказка — адсутнасць якога-небудзь трафіку на інтэрфейсе тунеля, пакуль госці праглядаюць сайты. Калі лічыльнікі не рухаюцца, палітыка ніколі не ўжывалася, і наладжванне самога тунеля не дапаможа.

Крок 1: сапраўдны сегмент, а не проста назва

Назва SSID не стварае ізаляцыі. Праверце, што гасцявая сетка заканчваецца на ўласным інтэрфейсе, VLAN або масце, і што дыяпазон адрасоў адрозніваецца ад даверанай LAN. На многіх спажывецкіх кропках доступу гасцявы SSID мосціцца ў той жа сегмент, што і ўсё астатняе, і гэта робіць астатнюю працу немагчымай, пакуль гэта не выправіць.

Затым пацвердзіце гасцявы дыяпазон і яго сервер DHCP, а налады рэзалвера трымайце прывязанымі да гэтага сегмента, а не да ўсяго роўтара. Гасцявая падсетка, якая існуе толькі як каментарый у правіле міжсеткавага экрана, — не сегмент, і роўтару не будзе з чым супастаўляць.

Не мосціце гасцей у асноўную LAN, каб было прасцей наладзіць VPN. Гэта мяняе жаданую ізаляцыю на кароткі шлях у маршрутызацыі, і гэта звычайная прычына, чаму гасцявая сетка атрымлівае доступ да прынтара і NAS.

Крок 2: выберыце тунель па крыніцы

Табліцы маршрутызацыі выбіраюцца па прызначэнні, таму правіла, якое кажа адпраўляць 0.0.0.0/0 у тунель, датычыцца ўсіх. Палітычная маршрутызацыя дадае другое вымярэнне: выбірайце табліцу па адрасе крыніцы. На роўтары на базе Linux гэта дадатковае правіла плюс асобная табліца, і парадак важны, бо першае адпаведнае правіла перамагае:

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

Апошняя каманда адказвае на пытанне наўпрост: які інтэрфейс выкарыстае гэтая крыніца для гэтага прызначэння. Запусціце яе да і пасля змены, і вы даведаецеся, ці ўступіла палітыка ў сілу, не кранаючы браўзер.

Большасць прашывак роўтараў выражае тое ж самае як правіла інтэрфейса або выбар шлюза на аснове крыніцы. Які б сінтаксіс ні выкарыстоўвала ваша платформа, прынцып адзін: супастаўце з уваходным інтэрфейсам або прэфіксам крыніцы, затым перавызначце маршрут толькі для гэтага супадзення. Правіла, супастаўленае па прызначэнні, не можа адрозніць госця ад хатняй прылады.

Крок 3: шлях адказу і трансляцыя

Пакет, які выходзіць праз тунель, павінен вярнуцца. Альбо суразмоўца тунеля ведае маршрут назад да гасцявага прэфікса, альбо роўтар транслюе гасцявую крыніцу ў адрас тунеля. Выберыце адно і запішыце, бо збоі выглядаюць па-рознаму: адсутны зваротны маршрут дае злучэнне, якое ўсталёўваецца і ніколі не адказвае, а адсутная трансляцыя часта не дае нічога наогул.

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

Калі вы выбераце трансляцыю, памятайце, што суразмоўца цяпер бачыць адзін адрас для кожнага госця, таму любая палітыка для асобнага кліента на далёкім канцы знікае. Калі захаваць адрасы, абодва канцы павінны мець гасцявы прэфікс у сваёй маршрутызацыі і палітыцы, што большая праца і больш прадказальна.

IPv6 патрабуе ўласнага правіла. Палітыка, напісаная для IPv4, не пакрывае другое сямейства, і гасцявая прылада з працоўным IPv6 з задавальненнем скарыстае яго, пакуль ваш старанна пракладзены шлях IPv4 стаіць без работы. Альбо маршрутызуйце абодва сямействы, альбо адключыце IPv6 на гасцявым сегменце, але не мяркуйце, што складзенае правіла пакрывае тое, што прылада робіць насамрэч. Тэстуйце кліентам, у якога ўключаны абодва сямействы, бо менавіта гэты выпадак праект павінен вытрымаць. Ноўтбук, які аддае перавагу IPv6, выглядае правільна ў тэсце толькі з IPv4 і працякае ў рэальным.

Праверце ізаляцыю, а не толькі прагляд сайтаў

Прагляд сайтаў даказвае, што выхад змяніўся. Ён не даказвае, што сегмент ізаляваны, а ізаляцыя — прычына існавання гасцявой сеткі. З гасцявой прылады паспрабуйце дасягнуць інтэрфейсу адміністравання роўтара, даверанага хаста LAN і сэрвісу, які павінен быць адхілены; усе тры павінны праваліцца, і правал павінен быць рашэннем палітыкі, а не тайм-аўтам, які ніхто не можа патлумачыць.

Затым праверце прыладу асноўнай LAN і пераканайцеся, што яе выхад не змяніўся. Гэта рэгрэсія, якую гэты праект выклікае найчасцей: шырокае правіла, прызначанае для гасцей, ужыта да кожнага інтэрфейса, бо супастаўленне было напісана па прызначэнні.

Нарэшце, вырашыце, што адбудзецца, калі тунель не працуе. Госці або не атрымаюць інтэрнэту, або вернуцца на шлях, які вы ўхвалілі, а пакінуць гэта нявырашаным — значыць маўкліва вярнуцца да звычайнага падключэння, што і ёсць тая ўцечка, якую гасцявая палітыка павінна была прадухіліць. рэцэпт маршрутызацыі інтэрнэт-трафіку апісвае той жа выбар шляху для роўтара на базе pfSense.

DNS, які паходзіць ад роўтара, — выпадак, які здзіўляе людзей апошнім. Калі госці выкарыстоўваюць роўтар як рэзалвер, уласныя запыты роўтара ідуць па маршруце роўтара, а не па гасцявым правіле, таму пошукі могуць выходзіць праз звычайнае падключэнне, пакуль трафік праграм не выходзіць. Трымайце сегмент, рэзалвер і палітыку збояў у адной нататцы, і наступны чалавек зможа праверыць усе тры, не выводзячы праект нанова.