Зошто nslookup решава преку VPN, а прелистувачот не може
nslookup прашува директно еден сервер; прелистувачот ги следи резолверите на интерфејсите, NRPT правилата и шифрираниот DNS. Споредете ги овие патеки пред да го уредите VPN-от.
nslookup испраќа барање до серверот што ќе го наведете и го печати одговорот, затоа може да успее додека секое јазиче во прелистувачот не успева. Прелистувачот бара од оперативниот систем да реши, а системот ги мери резолверите по интерфејс, правилата за политика на решавање имиња и мрежната положба на адаптерот. Потоа прелистувачот може да го додаде својот шифриран DNS одозгора. Три различни патеки, еден симптом, и тунелот обично не е расипаниот дел.
Проверките подолу ги следат тие патеки од системот кон надвор. Не уредувајте го профилот на VPN-от додека не знаете која патека одговорила и која не успеала.
Три политики го одредуваат одговорот
Секој интерфејс носи своја листа резолвери и суфикси за пребарување. VPN адаптерот додава сервери додека физичкиот адаптер ги задржува своите, и системот може да го земе тој што ќе одговори прв, па пребарувањето може да биде услужено надвор од тунелот без некој тоа да го избере. Правилата на табелата за политика на решавање имиња можат да испраќаат избрани домени до избрани сервери, така обично се изразува split DNS на Windows. И клиентот или портата на VPN-от можат да турнат адреса на резолвер што постои само во приватната мрежа.
Овие три дејствуваат еден на друг на начини што од прелистувач изгледаат произволно. Турнат резолвер на приватна адреса без рута низ разделениот тунел го блокира секое пребарување и потоа го прави неуспешно. Правило што го покрива внатрешниот суфикс и покажува на исклучен сервер го дава истиот видлив дефект како рута што недостига. Суфикс за пребарување што недостига на VPN адаптерот го претвора краткото име во јавно барање за погрешен домен. Секое од нив бара различен поправка.
Зошто прелистувачот поставува друго прашање
nslookup го испраќа своето барање до серверот што ќе го избере и не следи ниту политиката на именски простор ниту поставката за шифриран DNS на прелистувачот. Затоа рачното барање до јавен резолвер добива одговор додека прелистувачот известува дека страницата не постои. Споредувате две програми, а не две состојби на една програма.
Претпочитањето на семејството адреси објаснува доцнење, а не неуспех. Прелистувач што прво бара IPv6 записи на тунел што пренесува само IPv4 чека да истече времето пред да се повлече. Firefox имал такво претпочитање токму за ова, а неговото исклучување е дијагностички чекор, не поправка.
Прочитајте ја листата резолвери и правилата
На Windows, испечатете што држи системот пред да теоретизирате. Get-DnsClientServerAddress ги покажува серверите по интерфејс, Get-DnsClientNrptRule ги набројува правилата на именскиот простор, а Resolve-DnsName одговара на точното име низ системската патека. Споредете го тој одговор со директно барање до серверот на VPN-от по адреса. Кога Resolve-DnsName не успева, а директното барање успева, сомнителниот е листата резолвери или правило на именскиот простор.
Проверете го и самото име. Внатрешното кратко име може да бара приватен суфикс што го дава само VPN адаптерот, додека целосно квалификуваното име се решава добро. Предупредување за сертификат по успешно пребарување припаѓа на друг проблем.
Недостапниот турнат резолвер
Портата или клиентот можат да турнат адреса на резолвер, и таа адреса мора да биде достапна низ тунелот. Во разделен тунел приватниот опсег што го држи резолверот можеби не е меѓу вклучените рути, што дава пребарување што никогаш не добива одговор. Потврдете дека рутата постои, потоа прашајте ја токму таа адреса низ тунелот. Ова е неуспехот зад дефектот на доменот во прелистувачот додека јавен резолвер се уште одговара.
Ако резолверот е недостапен, поправката е рута или вклучена подмрежа, не друг DNS сервер.
Шифрираниот DNS го заобиколува целиот пат
Прелистувачите со DNS-over-HTTPS сами ги решаваат имињата преку HTTPS врска со избран давател. Кога тоа е вклучено, системскиот резолвер и правилата за split DNS целосно се заобиколуваат за тие пребарувања, па внатрешните имиња не успеваат во прелистувачот додека оперативниот систем ги решава правилно. Се случува и обратното: внатрешни имиња успеваат во прелистувачот преку давател што никогаш не требало да ги види, и тоа е проблем на политика, не на поврзаност.
Одлучете свесно дали шифрираниот DNS е дозволен на управувани уреди, потоа конфигурирајте го преку интерфејсот за управување на прелистувачот за изборот да биде видлив. Оставањето на индивидуална преференца создава флота во која истиот VPN се однесува различно на секој преносен сметач.
Поправки што одговараат на неуспехот
Ако VPN-от го турка својот резолвер, направете тунелот да носи сообраќај до него и истата поставка да биде видлива на адаптерите што учествуваат во решавањето. Ако локалните страници престанат да се решаваат додека сте поврзани, додајте изречни исклучоци на именскиот простор или условен препраќач наместо целосно да го замените резолверот. Ако шифрираниот DNS на прелистувачот ја заобиколува политиката, тоа е поставката што треба да се смени. Никогаш не додавајте јавен резолвер за да поправите внатрешно име: тој истекува приватни барања и не го решава името.
Потоа одвојте го пребарувањето од врската. Име што се решава на точната адреса но одбива врска е проблем на услуга, заштитен ѕид или сертификат, и DNS промените нема да го поправат.
Запишете која патека одговорила, која не успеала и што сте смениле. Тогаш следниот извештај за истиот симптом ќе бара една наредба наместо цело попладне.