Унутраныя імёны не развязваюцца праз VPN, а публічныя сайты працуюць

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

Два сімптомы, якія не з’яўляюцца адной няспраўнасцю

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

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

Запішыце абодва назіранні з адзнакай часу, затым прайдзіце чатыры праверкі ніжэй па парадку.

Чый рэзалвер адаптара атрымлівае пытанне

У Windows кліент DNS выбірае серверы па парадку прывязкі адаптараў, і адаптар тунэля не аўтаматычна першы. Адкрыйце дадатковыя параметры адаптара і перанясіце злучэнне аддаленага доступу вышэй за фізічны адаптар, затым перападключыцеся, каб змена дзейнічала ў новым сеансе.

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

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

Кароткаму імені патрэбны суфікс раней, чым маршрут

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

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

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

Спытайце рэзалвер напрамую, затым імя

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

У Linux кліент VPN, які перапісвае /etc/resolv.conf, цалкам замяняе лакальныя рэзалверы. vpnc прадстаўляе DNSUpdate no, каб гэтага не было, а systemd-resolved можа накіроўваць на звяно тунэля толькі пералічаныя дамены. Абодва падыходы пакідаюць публічныя імёны на лакальным рэзалверы і адпраўляюць унутраныя імёны ў офіс.

Уцечкі — гэта правіла, а не сцяжок

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

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Калі запыт з’яўляецца на гэтым інтэрфейсе ў чытальным выглядзе, тунэль яго не нясе. Выпраўленне — правіла, якое дазваляе порт 53 толькі рэзалверу, прадстаўленаму VPN, і адкідвае іншыя прызначэнні, плюс канфігурацыя кліента, якая не адкідвае прадстаўлены параметр моўчкі.

Гэтая апошняя частка важнейшая, чым здаецца. Запусціце OpenVPN з route-nopull, і прадстаўлены параметр DNS знікне разам з маршрутамі, калі фільтр выцягвання не пашыраны, каб яго захаваць. А кліент, які ігнаруе dhcp-option DNS, будзе далей выкарыстоўваць тое, што меў раней. Любая змена на баку сервера патрабуе новага сеанса, бо спіс рэзалвераў перадаецца пры ўзняцці тунэля, а састарэлы сеанс працягвае паказваць ранейшы стан.

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