Палітычная маршрутызацыя OpenWrt: ланцуг, які ловіць лакальны DNS

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

Два патокі, адзін адрас рэзальвера

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

Другі паток ніколі ніадкуль не прыходзіць. Яго стварае маршрутызатар, таму няма ні ўваходнага пакета, ні кроку перанакіравання для супастаўлення.

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

Перанакіраваныя і лакальна створаныя пакеты ўваходзяць па-рознаму

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

Лакальна створаны трафік ствараецца працэсам на маршрутызатары і замест гэтага ўваходзіць у шлях выхаду. Ён маршрутызуецца ўласным рашэннем маршрутызатара і сустракае палітыку толькі тады, калі палітыка ахоплівае гэты ланцуг. Няма ні ўваходнага інтэрфейса для супастаўлення, ні рашэння аб перанакіраванні для назірання.

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

Выберыце ланцуг выхаду, затым звузьце супастаўленне

Рамонак у тым, каб прывязаць тую ж мэту і да ланцуга выхаду, або перанесці правіла туды, калі вам важныя ўласныя запыты маршрутызатара. У наладзе OpenWrt, пабудаванай на пакеце палітычнай маршрутызацыі, гэта значыць выбраць output, а не prerouting у наладзе ланцуга правіла. Пакіньце абодва правілы, калі абедзве групы патрабуюць ахопу.

Затым звузьце тое, з чым супастаўляецца правіла. Адрасы рэзальвера прызначэння на порце, які рэзальвер фактычна выкарыстоўвае, — значна меншае рашэнне, чым адпраўляць усё, што стварае маршрутызатар, у тунель.

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

Трымайце ўласны транспарт тунеля па-за правілам

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

Другой ахвярай з'яўляецца доступ да кіравання. Адміністрацыйныя сеансы, якія паходзяць ад маршрутызатара, або адказы на іх, могуць быць уцягнуты ў тунель занадта шырокім лакальным правілам і стаць недасягальнымі з LAN.

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

Праверце абодзве групы, а не адну

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

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

Праверце і порт: правіла, якое супастаўляе порт прызначэння 53, прапускае рэзальвер, дасягнуты праз DNS over TLS на 853 або канчатковую кропку HTTPS. Супастаўляйце транспарт, які фактычна выкарыстоўвае наладжаны ўверх, і ўцечка зачыніцца па правільнай прычыне.