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, с мотива, че разрешаването на имена не бива да умира заедно с тунела. Това е удобно в домашна LAN, където рутерът разрешава за целия дом. В Wi-Fi на хотел или летище същото изключение сочи към чужд сървър и всяко име, което напишете, се разкрива, дори трафикът ви в мрежата да остава блокиран.
Границата е кой притежава резолвера. Ако вярвате на локалния, изключението е малка и честна дупка. Ако не, подходът само през тунела е единственият, който издържа, а цената е, че падналият тунел отнася всички имена.
Защо собственото търсене на VPN клиента още работи
Клиентът трябва да разреши името на хостинг шлюза, преди да има тунел, затова строгата блокада не бива да покрива пътя за първоначално зареждане на клиента. Повечето клиенти или кешират адреса на крайната точка, или предоставят документирано изключение за този единствен хост. Ако наборът ви от правила блокира това търсене, тунелът никога не се връща и журналите показват клиент, който не може да достигне собствения си сървър — това е дефект в политиката, а не в DNS.
Разделеният DNS е другото място, където това се проявява. Клиентът изпраща вътрешна зона към частен резолвер и оставя всичко останало на системния резолвер. След падане публичните имена може да се разрешават, докато вътрешните изтичат по време, защото частната зона няма останал маршрут. За потребителя това е "VPN-ът счупи интернет"; за журнала на резолвера това е заявка, която така и не е пристигнала.
Под systemd-resolved можете да видите разделянето директно.resolvectl statusпоказва DNS сървърите за всяка връзка и домейните за маршрутизиране, а след падането на тунела вътрешният домейн продължава да сочи към сървър на връзка, която вече не съществува. Заглушката на 127.0.0.53 все още приема заявката, после чака източник по-нагоре, който няма да отговори, и затова отказът отнема секунди, вместо да се върне веднага.
Шифрованият DNS не заобикаля филтъра на пакети
DNS през HTTPS и DNS през 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документира това поведение за всяка платформа.
После проверете в този ред. В Linuxresolvectl statusпоказва активната връзка,dig +short example.comпроверява публично име,dig @10.8.0.1 internal.example.comпроверява частното, аsudo tcpdump -ni any port 53показва кой интерфейс използват пакетите, докато пускате и двете. В WindowsGet-DnsClientServerAddress -AddressFamily IPv4иResolve-DnsName example.comдават същите два факта: кой е конфигуриран и кой отговаря.
Завършете с негативния тест. Изключете тунела, потвърдете, че ново публично име не се разрешава, потвърдете, че частното име не се разрешава, ипотвърдете, че нито един пакет на порт 53 не е напуснал физическия адаптер. Блокада, която издържа само за кеширани отговори, не издържа изобщо.
Контролен списък, преди да затворите тикета:
- Резолверът, използван по време на аварията, е този, който политиката предвижда.
- Собственото търсене на крайната точка от клиента все още е разрешено — чрез кеш или изключение.
- DoH и DoT или се покриват от блокадата, или са изключени от политиката.
- Частните зони се провалят затворени, не отворени, щом тунелът изчезне.