Чаму ўласны DNS маршрутызатара абыходзіць тунель VPN?

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

Да якога патоку насамрэч належыць перахоп пакетаў

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

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

Практычная праверка — назіраць за абодвума бакамі адначасова. На маршрутызатары пералічыце сокет рэзалвера, запытайце яго лакальна і злавіце інтэрфейс WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

Чаму палітычная маршрутызацыя не бачыць другі запыт

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

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

Дзе рэзалвер pfSense вызначае ўласны зыходны шлях

pfSense робіць гэтае раздзяленне бачным. Трафік кліентаў можна накіраваць праз шлюз VPN па палітыцы, тады як уласны трафік міжсеткавага экрана ідзе за наладай зыходу рэзалвера, а не за правіламі LAN. У вэб-інтэрфейсе гэтая налада знаходзіцца ў Services > DNS Resolver > Outgoing Network Interfaces, і яе значэнне — спіс інтэрфейсаў, якія рэзалвер можа выкарыстоўваць для зыходных запытаў.

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

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

Выберыце паводзіны пры збоі раней за наладу

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

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

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

Праверце абодва шляхі і трымайце вынікі асобна

DNS-тэст у браўзеры адказвае на вузкае пытанне: якімі рэзалверамі карыстаўся гэты браўзер ва ўмовах гэтага тэсту. Ён не інвентарызуе прылады ў сетцы і не бачыць запыт, які маршрутызатар стварыў для сябе. Стаўцеся да яго выніку як да адной кропкі даных, а не як да аўдыту.

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

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

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