Хто кіруе 1.1.1.1? Праверка DNS-адраса, перш чым яму давяраць

Вы ўставілі 1.1.1.1 у поле DNS VPN, старонка загрузілася, і дапаможнік цяпер выглядае пацверджаным. Гэта назіранне вузейшае, чым здаецца: праграма паводзіла сябе інакш, а змена пакуль нічога не кажа пра тое, хто адказаў на запыт або чаму старая канфігурацыя не спрацавала. Скапіяваны дапаможнік часта называе вядомы публічны адрас «DNS VPN», і гэта сцвярджэнне пра ўласнасць, а не пра дасяжнасць. Праверка таго, што ўяўляе адрас, займае пяць хвілін і прадухіляе пастаянную змену, зробленую з няправільнай прычыны.

Працоўная налада не ёсць ідэнтычнасцю

Адрас у полі налад — гэта канцавы пункт, а канцавы пункт мае аператара. Гэтыя два факты асобныя, і другі людзі звычайна прапускаюць. Для найчасцей скапіяванай пары адказ публічны: Cloudflare публікуе 1.1.1.1 і 1.0.0.1 як адрасы свайго рэзолвера і пералічвае іх у сваім афіцыйным даведніку адрасоў. Таму імя аператара належыць побач з адрасам, а не ў асобны дапаможнік.

Увод гэтай пары пры актыўным тунелі не робіць VPN-кампанію яе аператарам і не робіць трафік ананімным. Запыт пакідае вашу машыну ў напрамку кампаніі, якая публікуе дыяпазон адрасоў, і гэтая кампанія можа быць паважанай, але ўсё роўна не тым бокам, які меў на ўвазе дапаможнік. Пазнака ў інструкцыях і рэальны аператар — два розныя сцвярджэнні. Ні адно не кажа, хто кіруе прамежкавым сеткавым шляхам.

Выкарыстоўвайце ўласны апублікаваны даведнік рэзолвера, каб пацвердзіць пару адрасоў або зашыфраваны канцавы пункт. Рэкамендацыя іншага пастаўшчыка можа быць легітымнай, і «рэкамендавана», «дасягнута праз» ды «кіруецца» па-ранейшаму апісваюць тры розныя адносіны.

Параўнайце тры рэчы, якія патрэбны запісу

Запіс, гатовы да разгляду, раздзяляе тры пытанні: хто мусіць атрымаць запыт, ці абмен просты або зашыфраваны і які шлях мусіць яго несці. Назва пастаўшчыка не можа запоўніць другое ці трэцяе, а пазнака краіны не можа запоўніць ніводнага з іх. Запішыце тры пункты да змены і параўнайце іх пасля. Гэтыя пункты не ўзаемазаменныя, і стаўленне да іх як да аднаго — гэта шлях, якім здагадка робіцца дакументацыяй.

Менавіта параўнанне ператварае працоўную наладу ў задокументаванае рашэнне. Без яго наступны чалавек атрымлівае адрас без ніякай прычыны. Спачатку прачытайце трэці слупок табліцы ніжэй, бо менавіта там большасць упэўненых тлумачэнняў насамрэч спыняецца.

Табліца наўмысна кароткая. Яе сутнасць у тым, што кожны пункт адказвае на іншае пытанне і ніводнае поле само не запаўняе ўсе тры.

Лакальны перасылальнік хавае сапраўдную крыніцу

Прылада, наладжаная выкарыстоўваць свой маршрутызатар як DNS, паказвае на перасылальнік. Гэты адрас вызначае наступнага атрымальніка запыту, а не рэзолвер, які ўрэшце адказвае. Лакальны stub-рэзолвер дадае той жа дадатковы крок, і яго лёгка спутаць з сапраўднай рэччу, бо ён з’яўляецца ў кожным вывадзе стану.

Stub перасылае да крыніц, якія той жа вывад таксама пералічвае, звычайна ніжэй. Прачытайце ўвесь ланцужок, перш чым рабіць высновы пра аператара, бо першы радок — не ўвесь адказ. Інакш вы называеце рэцэпцыю кампаніяй.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

Другая каманда выкарыстоўвае луна-імя рэзолвера, калі аператар яго публікуе, каб паведаміць крынічны адрас, які ён бачыць. Трэцяя называе сервер, што адказаў, і гэта часта не той адрас, які вы наладзілі. Параўнайце ўсе тры вывады, перш чым запісаць аператара.

Зашыфраваны DNS змяняе тое, што бачна, а не тое, хто гэта бачыць

DNS over HTTPS і DNS over TLS абараняюць абмен паміж кліентам і рэзолверам. Рэзолвер па-ранейшаму чытае кожнае імя, пра якое пытаюцца, бо адказваць — гэта яго праца. Змяняецца тое, хто можа назіраць за абменам: лакальная сетка бачыць злучэнне з адным канцавым пунктам замест патоку запытаў у адкрытым тэксце.

Тое, што не змяняецца, — гэта адносіны даверу, якія па-ранейшаму паказваюць на арганізацыю, што кіруе гэтым канцавым пунктам. Браўзер з уласнай наладай бяспечнага DNS можа цалкам абысці рэзолвер аперацыйнай сістэмы. Стаўцеся да іх як да дзвюх канфігурацый, якія могуць не супадаць, а не як да адной налады, ужытай двойчы.

Прыватныя імёны зноў патрабуюць уласнага рашэння. Працоўны тунель можа скіроўваць выбраныя дамены да арганізацыйных рэзолвераў, і замена яго публічным сэрвісам можа зламаць унутраныя пошукі або раскрыць унутраныя імёны не таму боку. Праверце палітыку даменаў, перш чым замяняць налады цэлага адаптара.

Трымайце назіранне вузкім

Калі параўноўваеце, захавайце старую канфігурацыю і змяняйце адну наладу за раз. Занатуйце праграму, аперацыю, палітыку рэзолвера і тое, ці вырашаюцца публічныя і дазволеныя прыватныя імёны пасля паўторнага падключэння. Параўнанне з дзвюма зменамі не даказвае ніводнай з іх. Запішыце вынік там, дзе яго знойдзе наступны чалавек, побач з самой наладай.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Калі праграма пачне працаваць, трымайце сцвярджэнне такім малым, як дазваляюць доказы. Гэтая змена дапамагла аднаму тэсту, і яна нічога не кажа пра тое, ці папярэдні рэзолвер дзейнічаў нядобрасумленна, ці тунель быў зламаны, ці іншай прыладзе патрэбна тая ж замена. Трывалы вынік — гэта канфігурацыя, чыіх аператара і мэту вы можаце патлумачыць.