Чаму прыватныя DNS-імены не працуюць на VPN-кліентах і дзе праверыць

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

Перш чым рэдагаваць любы профіль, праверце, што кліент робіць з іменем. У Linux resolvectl query files.corp.example паказвае, праз якое злучэнне і які рэзалвер створаны адказ. У Windows Resolve-DnsName files.corp.example паказвае сервер, які адказаў, і адрас, які ён вярнуў.

Прачытайце адказ, перш чым нешта змяніць

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

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

Раздайце рэзалвер знутры тунеля

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

OpenVPN у першай групе. На серверы push "dhcp-option DNS 10.8.0.53" і push "dhcp-option DOMAIN corp.example" ідуць па кантрольным канале, але толькі калі ў канфігурацыі кліента pull яшчэ ўключана. Кліент, адрэдагаваны ўручную, з pull-filter ignore "dhcp-option" ніколі іх не ўбачыць, і гэты адзін радок тлумачыць дзіўна шмат выпадкаў тыпу «сервер гэта штурхае, але мой ноўтбук не згодны».

WireGuard у другой групе, бо пратакол зусім не мае перамоваў пра опцыі. Рэзалвер і домен пошуку трапляюць у ўласны блок [Interface] кліента як DNS = 10.8.0.53, corp.example. wg-quick ужывае гэта праз resolvconf або systemd-resolved, а ў Windows афіцыйны кліент ставіць правілы NRPT, якія існуюць толькі пакуль тунель падняты: Get-DnsClientNrptPolicy пералічвае іх, што робіць гэта хуткім спосабам убачыць, ці кліент калі-небудзь ужыў ваш файл.

IPsec/IKEv2 пасярэдзіне. Дадатак attr ад strongSwan можа вярнуць DNS-сервер, узяты з пула, і кліент Windows звычайна яго прымае, але профіль, які замацоўвае ўласны сервер імёнаў, перамагае ўсё, што прапануе шлюз. На кліенце Linux эквівалентны ручны крок — resolvectl dns wg0 10.8.0.53, за ім resolvectl domain wg0 '~corp.example'; абодва знікаюць разам з інтэрфейсам, што якраз тое, што вы хочаце для налады, абмежаванай тунелем.

Абмяжуйце суфікс, а не глытайце кожны запыт

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

Дасылайце ўнутр толькі прыватны суфікс. У systemd-resolved домен, які пачынаецца з ~, прызначаны толькі для маршрутызацыі, таму ~corp.example азначае, што запыты пад гэтым суфіксам ідуць да сервераў таго злучэння, а ўсё астатняе працягвае карыстацца фізічнай сеткай. Windows робіць тое ж з правіламі NRPT, абмежаванымі прасторай імёнаў, а macOS — з дадатковым файлам рэзалвера ў /etc/resolver/.

Мультыкаст-імены заслугоўваюць уласнага адказу. Імены .local паводле дызайну link-local (RFC 6762), і інтэрфейс tun кропка-да-кропкі не нясе гэтую мультыкаст-групу, таму даданне публічнага рэзалвера іх не апублікуе, а запыт да ўнутранага unicast-рэзалвера вяртае NXDOMAIN. Адбітнік накшталт avahi у рэжыме адбіцця можа злучыць два сегменты, але гэта рашэнне на баку сервера, якога ні адзін кліент не можа патрабаваць. Калі прынтар або NAS мусіць быць даступны па імені, дайце яму запіс A у сваёй зоне.

Дакажыце, што адказ можа вярнуцца

Правільны адказ, які паказвае на недасягальны адрас, выглядае як раз як праблема рэзалвера, пакуль вы не праверыце маршрут. Спытайце ядро, куды пойдзе адказ: ip route get 10.20.5.20 называе інтэрфейс і, карысней, зыходны адрас, які ён выкарыстае.

Сачыце за самім адрасам рэзалвера. Кліент з DNS = 10.8.0.53 побач з AllowedIPs = 10.20.0.0/16 дасылае запыты праз фізічную сеткавую карту, дзе яны ціха паміраюць, бо рэзалвер не знаходзіцца ў межах ніводнага прэфікса, які патрабуе тунель. Гэтае разыходжанне — самая частая аднапрычынная памылка ва ўсёй гэтай галіне, і яно застаецца нябачным, пакуль вы не параўнаеце наладу DNS з дазволенымі прэфіксамі радок за радком.

Перакрыжаваныя дыяпазоны выклікаюць адваротную памылку. Адказ правільны, маршрут існуе, і ён паказвае на няправільны хост, бо 192.168.0.0/24 дома больш канкрэтны, чым маршрут тунеля да таго ж дыяпазону. Перанумаруйце адзін бок або праштурхніце вузкі маршрут, потым пацвердзіце файрвол і зваротны шлях хоста службы; нататкі strongSwan пра перанакіраванне ахопліваюць бок sysctl гэтага шляху.

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

Ператэстуйце з кліента, а не з шлюза

Тэстуйце ўнутры праграмы, на якую скардзіцца карыстальнік, бо пошук з каманднага радка не даказвае, што браўзер ідзе тым жа шляхам. Бяспечны DNS Chrome і network.trr.mode у Firefox могуць цалкам абысці сістэмны рэзалвер, і калі яны гэта робяць, прыватнае імя або правальваецца, або выцякае да публічнага рэзалвера. Параўнанне resolvectl query з запушчаным уручную dig @10.8.0.53 files.corp.example скажа, які з двух выпадкаў адбыўся.

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

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