DNS не розв'язується, коли kill switch VPN блокує порт 53
Kill switch може навмисно блокувати DNS. Порівняйте розв'язання лише всередині тунелю з винятком для локального резолвера, а потім визначте, який шар справді відмовив.
Коли kill switch звалює тунель, він забирає з собою й шлях DNS, а резолвер, що залишається, рідко буває тим, якого ви чекаєте. Два підходи трактують цю мить дуже по-різному: блокувати кожен пакет DNS, який не перебуває всередині тунелю, або залишити один резолвер як виняток. Обидва варіанти можна захистити. З вкладки браузера симптоми виглядають майже однаково, тому перше завдання — з'ясувати, який підхід ви насправді розгорнули.
Я тримаю цю різницю перед очима, бо виправлення в кожному разі протилежне. Одному підходу потрібен ширший виняток, іншому — вужчий. Здогади коштують вам або приватності, або півдня.
Два підходи до DNS для однієї аварії
Підхід A ставиться до резолвера як до звичайної служби за тунелем. Правила міжмережевого екрана дозволяють UDP і TCP 53 лише на інтерфейсі тунелю, а адреса, що видається клієнту, — це резолвер усередині тунелю. Коли тунель падає, пошук припиняється, і це запланований результат, а не несправність.
Підхід B тримає резолвер доступним у локальній мережі, зазвичай це маршрутизатор на 192.168.1.1 або заглушка операційної системи на 127.0.0.53, виходячи з того, що розв'язання імен не повинно вмирати разом із тунелем. Це зручно в домашній мережі, де маршрутизатор розв'язує імена для всієї оселі. У Wi-Fi готелю чи аеропорту той самий виняток указує на чужий сервер, і кожне введене ім'я розкривається, навіть якщо ваш вебтрафік лишається заблокованим.
Межа в тому, кому належить резолвер. Якщо ви довіряєте локальному, виняток — маленька й чесна діра. Якщо ні, підхід лише через тунель — єдиний, що тримається, і ціна в тому, що повалений тунель забирає всі імена.
Чому пошук самого VPN-клієнта досі працює
Клієнт має розв'язати ім'я хоста шлюзу до того, як з'явиться тунель, тому сувора блокада не повинна закривати шлях початкового завантаження клієнта. Більшість клієнтів або кешують адресу кінцевої точки, або надають задокументований виняток для цього єдиного хоста. Якщо ваш набір правил блокує цей пошук, тунель ніколи не повернеться, а журнали покажуть клієнта, який не може достукатися до власного сервера; це дефект політики, а не DNS.
Розділений DNS — друге місце, де це проявляється. Клієнт штовхає внутрішню зону до приватного резолвера, а все інше лишає системному. Після падіння публічні імена можуть ще розв'язуватися, тоді як внутрішні вичерпують час очікування, бо приватна зона більше не має маршруту. Для користувача це «VPN зламав інтернет»; для журналу резолвера це запит, який так і не надійшов.
Під systemd-resolved розподіл видно безпосередньо. resolvectl status перелічує DNS-сервери за кожним каналом і домени маршрутизації, і після падіння тунелю внутрішній домен далі вказує на сервер на каналі, якого вже немає. Заглушка на 127.0.0.53 досі приймає запит, потім чекає на вищий сервер, який не відповість, і саме тому збій триває секунди, а не повертається одразу.
Зашифрований DNS не обходить фільтр пакетів
DNS over HTTPS і DNS over TLS ідуть портами 443 і 853, тож правило, яке блокує порт 53, нічого про них не сказало. Блокувати «DNS» за портом — це політика про порт, а не про розв'язання імен. Якщо ваш kill switch блокує весь трафік поза тунелем, DoH потрапляє під блокування випадково. Якщо ви виокремили дозвіл для captive portal або публічного резолвера, то ні.
Засоби керування на боці клієнта — дешевший важіль. Firefox відмовляється від свого резолвера DoH, коли канареечне ім'я use-application-dns.net не розв'язується, і саме тому керовані мережі публікують цей домен як NXDOMAIN; корпоративна політика може ще й закріпити його вимкненим. Android Private DNS і безпечний DNS у Chrome мають власні перемикачі та власні типові значення. Вимкнути їх надійніше, ніж ганятися за адресами резолверів, бо список адрес змінюється, а ваш набір правил — ні.
Є версія цього, яка взагалі не про витоки. Застосунку із закріпленим резолвером усе одно потрібен мережевий шлях, щоб до нього дістатися. Шифрування змінює те, хто може прочитати запит, а не те, чи може пакет залишити машину, тому блокування для всього пристрою перемагає налаштування, не торкаючись його.
Зіставте симптом із шаром
Більшість звернень надходить одним реченням, і це речення зазвичай уже називає шар. Таблиця нижче — те, що я проходжу, перш ніж торкнутися правила; сенс у тому, щоб вирішити, чи запит заблокували, скерували не туди або взагалі не надіслали.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Перші два рядки — ті, що люди діагностують неправильно. Тихе скидання й відмова в браузері виглядають однаково як «DNS зламався», але лише одне з них означає, що ваш kill switch робить свою роботу. Відмова означає, що щось відповіло, отже блокування не там, де ви думаєте.
Відновіть політику резолвера, а потім доведіть її
Виправляйте підхід, а не симптом. Для розв'язання лише через тунель дозвольте 53 на інтерфейсі тунелю, протягніть внутрішній резолвер разом із конфігурацією тунелю і залиште фізичний канал без жодного дозволу DNS. У wg-quick саме рядок DNS = записує резолвер у конфігурацію інтерфейсу, тож тунель, який його пропускає, лишає старий резолвер на місці, і кожен запит іде не туди. посібник wg-quick документує таку поведінку для кожної платформи.
Потім перевірте в цьому порядку. У Linux resolvectl status показує активний канал, dig +short example.com перевіряє публічне ім'я, dig @10.8.0.1 internal.example.com перевіряє приватне, а sudo tcpdump -ni any port 53 показує, який інтерфейс використовують пакети, поки ви запускаєте обидва. У Windows Get-DnsClientServerAddress -AddressFamily IPv4 і Resolve-DnsName example.com дають ті самі два факти: хто налаштований і хто відповідає.
Заверште негативним тестом. Від'єднайте тунель, переконайтеся, що свіже публічне ім'я не розв'язується, переконайтеся, що приватне ім'я не розв'язується, і переконайтеся, що жоден пакет порту 53 не залишив фізичний адаптер. Блокування, яке тримається лише для кешованих відповідей, не тримається взагалі.
Контрольний список перед закриттям заявки:
- Резолвер, використаний під час аварії, — той, що його передбачає політика.
- Власний пошук кінцевої точки клієнтом досі дозволений, через кеш або виняток.
- DoH і DoT або охоплені блокуванням, або вимкнені політикою.
- Приватні зони відмовляють закрито, а не відкрито, щойно тунель зникає.