Защо частните 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 ви казва кой от двата случая се е случил.

След това прекъснете и се свържете отново, преди да го обявите за поправено. Настройки, приложени на ръка към интерфейс, изчезват с интерфейса и профил, който е изглеждал правилен само заради забравена локална промяна, ще се провали при следващото стартиране.

Кратък контролен списък за следващата машина: името се разрешава през резолвера на тунела, суфиксът е ограничен, а не глобален, адресът на резолвера е в разрешените префикси, хостът от отговора отговаря на порта на услугата и сертификатът покрива името, което потребителят е въвел.