WireGuard DNS на iPhone: дамен — гэта толькі суфікс пошуку
Даданне дамена ў радок DNS выглядае як падзелены DNS. На кліентах Apple ён толькі дапаўняе кароткія імёны, а любы запыт па-ранейшаму ідзе да рэзалвера тунеля.
Вы пішаце адзін радок з адрасам рэзалвера і даменам кампаніі, спадзеючыся, што толькі імёны ў гэтым дамене будуць выкарыстоўваць рэзалвер тунеля. На кліенце Apple усе імёны цяпер ідуць туды, і кароткія імёны ў дамене таксама вырашаюцца. Радок робіць дзве асобныя рэчы, і толькі адна з іх тычыцца таго, якія запыты апрацоўвае тунель. Другая — гэта зручнасць набору, якую праз жаданае тлумачэнне павысілі да палітыкі.
У што пераўтвараецца радок DNS
Кліент чытае запіс як спіс і класіфікуе кожны элемент паводле формы. Усё, што выглядае як адрас, становіцца DNS-серверам; усё, што выглядае як дамен, становіцца суфіксам пошуку. Абодва трапляюць у налады тунеля, але ў розныя палі. Ілюстрацыйны радок для тунеля, які нясе прыватны рэзалвер і адзін унутраны дамен, выглядае так.
DNS = 10.24.8.53, lab.internal.exampleАдрас дае рэзалвер. Дамен дае суфікс, які дазваляе кліенту набраць кароткае імя, а сістэме — дапісаць рэшту перад запытам. Ні адзін з элементаў нічога не кажа пра абмежаванне рэзалвера гэтым даменам, а гэта менавіта тое, чаго людзі чакаюць і не атрымліваюць. Толькі адно поле ў платформе можа выразіць гэтае абмежаванне, і гэта не гэтае поле.
Два палі Apple, дзве розныя задачы
Apple паказвае гэтае размежаванне ў аб'екце налад DNS. Спіс даменаў пошуку апісаны як спіс, які ўжываецца для ўдакладнення адназначных імёнаў хостаў: набярыце голай імя хоста, і сістэма можа дадаць кожны суфікс па чарзе. Гэта правіла дапаўнення, а не правіла маршрутызацыі. Нішто ў гэтым спісе не вызначае, да якога сервера звяртацца.
Спіс даменаў супастаўлення — гэта іншая ўласцівасць. Ён вызначае, якія прасторы імёнаў выкарыстоўваюць гэты набор налад DNS, а пусты запіс азначае дамен па змаўчанні, а не пэўны суфікс. генератар налад пакетнага тунеля у кліенце Apple ідзе па гэтай мадэлі. Ён змяшчае разабраныя суфіксы пошуку ў спіс пошуку, а калі серверы прысутнічаюць, ставіць спіс супастаўлення ў пусты радок. Вынік — рэзалвер тунеля, які адказвае на ўсё, што сістэма яму дасылае, плюс суфікс, які дапамагае з кароткімі імёнамі.
Такім чынам, дамен у гэтым радку — не селектар прасторы імёнаў. Даданне яшчэ аднаго не звужвае запыты, якія выкарыстоўвае тунель, а выдаленне не пашырае іх. Змяняецца толькі тое, колькі кароткіх імёнаў дапаўняецца.
Чаму кожнае імя ўсё ж дасягае рэзалвера тунеля
З пустым запісам супастаўлення тунель з'яўляецца кандыдатам-рэзалверам для звычайных імёнаў, а не толькі для дамена кампаніі. У поўнатунельнай канфігурацыі гэта звычайна мала важна, бо ўвесь трафік і так у тунелі. У падзеленым тунелі гэта вельмі важна. Публічныя імёны цяпер могуць вырашацца рэзалверам, які трымае толькі прыватную зону, і збой выглядае як зламаны VPN, хоць насамрэч гэта рэзалвер, які адказвае толькі частцы прасторы імёнаў. Тунель у парадку, запыты выходзяць, а адказы вяртаюцца пустымі.
Ёсць два спосабы выправіць, і гэта розныя рашэнні. Зрабіце рэзалвер тунеля поўным рэзалверам, які перадае публічныя імёны праз ухвалены шлях, або спыніце дасылаць публічныя імёны туды, змяніўшы канфігурацыю кліента, а не спіс даменаў. Першы трымае кожны запыт у тунелі і давярае вышэйшаму ўзроўню. Другі пакідае частку запытаў лакальна і прымае, што прыватныя імёны могуць перастаць вырашацца, пакуль тунель не працуе.
Што насамрэч спатрэбілася б падзеленаму DNS
Палітыка рэзалвера ў межах прасторы імёнаў патрабуе кліента, які дазваляе яе выразіць: супастаўленне даменаў на платформах Apple або эквівалентная налада ў прадукце, які вы карыстаеце. Поле канфігурацыі, якое прымае толькі серверы і суфіксы, не можа выразіць яе, як бы яно ні было пунктуавана. Профіль можа несці гэтую палітыку, бо ён апісвае кіраваную канфігурацыю, а не падказку часу падключэння. Ён можа назваць дамен, серверы і тое, што павінна адбыцца, калі гэты дамен недасяжны. Гэта і ёсць розніца паміж наладай і кантрактам.
На кіраваных прыладах Apple гэта звычайна дастаўляецца праз профіль канфігурацыі, які нясе налады DNS для пэўнага дамена. Гэта іншы механізм, чым файл канфігурацыі WireGuard, і абодва могуць суіснаваць, толькі калі кліент паважае профіль. Праверце, як вашы кліент фактычна называе поле, перш чым меркаваць, што абодва прадукты паводзяць сябе аднолькава. Скрыпт wg-quick на Mac і праграма WireGuard на iPhone чытаюць падобныя радкі і ўсталёўваюць іх праз розныя ўзроўні.
Чытайце ўсталяваныя налады, а не канфігурацыю
На Mac вы можаце паглядзець, да чаго прыйшла сістэма, і гэта больш інфарматыўна, чым перачытваць напісаны вамі файл. Спіс рэзалвераў паказвае, якія серверы наладжаны для якіх даменаў, а абмежаваныя запыты паказваюць, які з іх перамог. Кліент, які псуе радок, паказвае гэта тут, а не ў напісаным вамі файле. На iOS няма эквівалентнага каманднага радка, таму доказ там — вынік: прыватнае імя, якое вырашаецца праз тунель, і публічнае імя, адказ якога выдае, які рэзалвер адказаў.
scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-FiГэтыя дзве каманды друкуюць бягучую канфігурацыю рэзалвера і DNS-серверы актыўнай службы. Калі рэзалвер тунеля выступае як рэзалвер па змаўчанні без абмежавання дамена, канфігурацыя робіць менавіта тое, што запытаў кліент. Выпраўце гэта, змяніўшы механізм, а не дадаўшы другі суфікс і спадзеючыся, што паводзіны зменяцца.