Защо собственият 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, сам по себе си не е изтичане; той става изтичане само когато конфигурацията е избрала този път случайно.