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