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 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дакументуе гэтыя паводзіны для кожнай платформы.
Затым праверце ў такім парадку. У 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 або пакрытыя блакіроўкай, або адключаныя палітыкай.
- Прыватныя зоны адмаўляюць зачынена, а не адкрыта, калі тунель знік.