Поделен DNS и VPN: правилата за домени не се IP рути
Поделениот DNS избира резолвер по име, а одговорот сѐ уште бара рута. Тестирајте го правилото за домен и патот одделно, на платформата што навистина ја користите.
Вашиот лаптоп го решава intranet.corp преку тунелот, додека gitlab.com продолжува да оди кај резолверот на провајдерот, и тоа е поставеноста што работи како што е проектирана. Две одделни одлуки ја создадоа: правилото за совпаѓање на име го избра резолверот, а рутата го врати одговорот. Скршете кое било од двете и прелистувачот прикажува дефект што однадвор изгледа исто. Повеќето извештаи за поделен DNS го опишуваат вториот дефект додека цитираат докази за првиот.
Двете половини живеат на различни места и обично ги уредуваат различни луѓе. Едната е DNS политика прикачена на VPN профилот, другата е рута што тунелот ја инсталира или задржува. Отстранувањето грешки запира кога никој не утврди која половина навистина се преместила.
Две одлуки скриени во едно барање
Половината со име е објект на политика, а не рута. На Windows тоа е политика за разрешување имиња на VPN профилот; на Apple платформи множество домени за совпаѓање на објект со DNS поставки; на Linux домен за рутирање, линија за поделен резолвер или редослед на преклопникот за имени услуги. Половината со пат е обично рутирање, инсталирано од тунелот или рачно, и нема поим што е име на домаќин. Профил што дозволува суфикс само одлучува кој одговара; никогаш не го прави одговорот достапен.
Брз тест на симптоми ги одделува: заменете го името со адреса. Ако адресата работи, патот е во ред, а правилото е погрешно. Ако и адресата не успее, правилото може да е точно, а патот да недостасува.
Како секоја платформа го изразува истото правило за имиња
Намерата е иста, а имињата на полињата не се. Пример копиран од еден клиент во друг се парсира чисто и никогаш не се совпаѓа. Трите форми изгледаат вака:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Домен за совпаѓање или рутирање е тест на суфикс, затоа intranet.corp го покрива git.intranet.corp и не го покрива corp.intranet, и неговото превртување е најчестата грешка во целата поставеност. Windows го носи мапирањето како политика за разрешување имиња прикачена на профилот, со свој редослед на приоритет наспроти кој било список на суфикси што интерфејсот веќе го имал. Apple платформите ги прикачуваат домените за совпаѓање на објектот со DNS поставки на мрежното проширување, и системот ги применува за секој ограничен резолвер. Ниту една од овие форми не е рута и ниту една не може да направи недостапна адреса достапна. Политиката за разрешување имиња на Windows ги наведува имињата на полињата и правилата за приоритет за таа платформа, и тие не се оние што ги користат документите на Apple или systemd.
Точниот одговор сѐ уште бара пат
Одговорот на резолверот е само адреса, и апликацијата сѐ уште мора да стигне до неа. Дизајнот на поделен тунел често турка 10.20.0.0/16 и ја задржува стандардната рута, па внатрешното име се разрешува, а врската потоа виси. Спротивниот случај е исто толку чест: рутата постои, јавен резолвер одговара на приватното име со NXDOMAIN, и дефектот се регистрира како проблем со рутирање. Тестирањето на патот прво ве остава да гледате во рути за име што никогаш немало да се разреши.
Има и трета порта што ниту една половина не ја покрива. ACL на портата, правило за огнено ѕид или политика на клиентската страна може да ја отфрлат врската откако двете одлуки биле точни. Кога името се разрешува, рутата постои, а врската сѐ уште истекува, престанете да тестирате DNS.
Тестирање на имиња и патеки во фиксен редослед
Изберете редослед и држете се до него, инаку ќе го бркате чекорот што последен не успеал. Разрешете го документираното целосно внатрешно име, потврдете дека одговорот е адреса што може да ја носи табелата за рутирање, па повторете со јавно име за да докажете дека тунелот не фатил сѐ. На домаќин со systemd барањето и доменот за рутирање на резолверот се на една команда растојание:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Клиент на Windows ги поставува истите две прашања со други cmdlet команди. Втората известува за интерфејсот што системот навистина би го користел:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Ако пребарувањето врати адреса и проверката на патот го именува физичкиот интерфејс, правилото за имиња работело, а рутата не. Ако краткото име не успее додека целосното име се разрешува, списокот на суфикси е погрешен, а не резолверот.
Каде споредбата обично тргнува наопаку
Првата грешка е да се праша неповрзан јавен резолвер за приватно име и да се чита одбивањето како доказ за VPN. Втората е да се претпостави дека јавното пребарување што работи го докажува патот на резолверот на тунелот. Третата е да се третираат поделениот тунел и поделениот DNS како една дизајнерска одлука, кога распоредувањето може да биде точно во едното и скршено во другото. Секоја грешка дава сигурни заклучоци од тест што никогаш не го вежбал обвинетиот дел.
Прелистувач со сопствен безбеден DNS може исто така да го заобиколи системското правило, затоа тоа што еден прелистувач не успева додека друг успева не е противречност. Споредете го резолверот што одговорил, не прелистувачот што се пожалил.
Кога двете половини се видливи, преостанатото прашање е политичко, а не техничко: кои именски простори му припаѓаат на организацијата, кој го поседува секој одговор и кои од нив воопшто треба да ја напуштат машината. Запишете го тоа покрај профилот, бидејќи на следниот човек што ќе го допре правилото ќе му треба.