Зошто приватните 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 ви кажува кој од двата случаја се случил.

Потоа прекинете ја и повторно поврзете ја врската пред да го прогласите за поправено. Поставките внесени рачно на интерфејс исчезнуваат со интерфејсот, а профил што изгледал точно само поради заборавена локална измена ќе откаже при следното подигање.

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