Чому власний 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, сама по собі не є витоком; вона стає витоком лише тоді, коли конфігурація вибрала цей шлях випадково.