Внатрешните имиња не се решаваат преку VPN, а јавните сајтови се отвораат

Еден корисник пријавува дека името на интранет домаќинот не се решава преку VPN. Второ пријавување, од истиот лаптоп, вели дека тестот за протекување сѐ уште покажува прашања одговорени од локалниот resolver. Тие звучат како еден проблем, а се два, со различен доказ, и вообичаената поправка за првиот го влошува вториот. Одделете ги пред да допрете било кое поставување.

Два симптоми што не се една грешка

Неуспешното решавање на внатрешно име значи дека прашањето отишло некаде каде што нема одговор за него. Прашањата што излегуваат од тунелот значат дека прашањето отишло на погрешно место дури и кога одговорот бил достапен. Тоа се спротивни грешки: едната е одговор што недостига, другата е вишок одредиште.

Стапицата е што додавањето на канцеларискиот resolver насекаде го поправа првиот и го гарантира вториот. Додавањето на јавен resolver насекаде го прави спротивното.

Забележете ги двете набљудувања со временска ознака, потоа поминете низ четирите проверки подолу по ред.

Кој resolver на адаптерот го добива прашањето

На Windows, DNS клиентот избира сервери според редоследот на поврзување на адаптерите, а тунелскиот адаптер не е автоматски прв. Отворете ги напредните поставувања на адаптерот и преместете ја врската за далечински пристап над физичкиот адаптер, потоа поврзете се повторно за промената да важи за нова сесија.

Редоследот на поврзување е само првата половина. Клиентот мора да знае и кои имиња припаѓаат на тој адаптер, а тоа е прашање на суфикс, не на редослед.

Ставете го ipconfig /all од машината што работи до оној од лаптопот, двата земени додека тунелот е активен. Машината што работи ќе покаже DNS суфикс специфичен за врската на својот канцелариски адаптер, а лаптопот може да не покаже ниту еден на тунелот. Таа разлика објаснува цела класа пријави дека серверот е токму таму, а името сѐ уште не се решава, бидејќи без суфикс краткото име никогаш не се дополнува до зоната што ја служи канцеларискиот resolver.

На краткото име прво му треба суфикс, потоа рута

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

Копирајте го суфиксот од машината што работи во IPv4 својствата на VPN адаптерот на табот DNS, потоа поврзете се повторно. На Linux еквивалентот е доменот за пребарување на тунелската врска, кој systemd-resolved го изложува по врска, а не глобално.

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

Прашајте го resolverот директно, потоа името

Директно прашање до канцеларискиот resolver одделува проблем со име од проблем со патека, бидејќи целосно го заобиколува изборот на resolver кај клиентот.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

Внимавајте на џокер одговори, кои некои мрежи ги враќаат за непознати имиња. Одговор што изгледа веродостојно не е доказ дека одговорил предвидениот сервер, затоа споредете ја вратената адреса со онаа што навистина ја користи внатрешната служба. Ако адресата припаѓа на страница за паркирање или на прокси, resolverот одговорил, но одговорот никогаш не бил ваш. Таа разлика заштедува еден час во бркање тунел што работел цело време.

На Linux, VPN клиент што го препишува /etc/resolv.conf целосно ги заменува локалните resolverи. vpnc го изложува DNSUpdate no за да го запре тоа, а systemd-resolved може да ги насочи само наведените домени кон тунелската врска. Двата пристапа ги задржуваат јавните имиња на локалниот resolver, а внатрешните имиња ги праќаат во канцеларијата.

Протекувањето е правило, не поле за штиклирање

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

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

Ако прашањето се појави на тој интерфејс во читлива форма, тунелот не го пренесува. Поправката е правило што дозволува порта 53 само до resolverот што го испратил VPN и ги отфрла другите одредишта, заедно со конфигурација на клиентот што тивко не ја отфрла испратената опција.

Тој последен дел е поважен отколку што изгледа. Стартувајте OpenVPN со route-nopull и испратената DNS опција исчезнува заедно со рутите, освен ако филтерот за влечење не се прошири за да ја задржи. и клиент што го игнорира dhcp-option DNS ќе продолжи да го користи она што го имал претходно. Секоја промена на страната на серверот бара нова сесија за да стапи на сила, бидејќи списокот resolverи се доставува кога тунелот се крева, а застарена сесија продолжува да го покажува стариот статус.

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