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

Кој решавач го доби барањето?

Најдете го решавачот поврзан со секоја врска пред воопшто да го погледнете тунелот. Linux ги прикажува серверите по врска преку командата за состојба на решавачот, а macOS прикажува решавачи со опсег во излезот од DNS конфигурацијата. Ако одговорот уште доаѓа од домашниот рутер, врската на тунелот никогаш не била консултирана.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Овде се мешаат две фази: сервер што турка адреса на решавач и клиент што ја инсталира на активната врска. Профилот може да ја содржи опцијата, а дневникот може да покажува дека пристигнува, додека оперативниот систем продолжува да го користи стариот сервер. Споредете го дневникот со она што го пријавува врската и верувајте ѝ на врската.

Користете адреса на која облачната мрежа навистина одговара

Облачните мрежи обично одговараат на приватни имиња преку резервирана адреса поместена за две од основата на опсегот, па мрежата што почнува на 10.0.0.0 одговара на 10.0.0.2. Некои даватели објавуваат и локален решавач за врската што работи без да го знае опсегот, што помага кога мрежата ја изградил некој друг. Прашајте ја кандидат-адресата директно пред да ѝ ја турнете на било кого. Адресата што не е решавач изгледа исто како отфрлање од огнен ѕид, бидејќи барањето едноставно никогаш не добива одговор.

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

Тунелот не го носи именскиот простор

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

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

Поминете ги границите по ред

Тестирајте го решавачот инсталиран на активната врска, потоа директно барање до тој решавач, потоа истото барање од спротивната страна и на крајот апликацијата што го користи истото име. Секој чекор изолира една граница, така што неуспехот ви кажува каде да гледате наместо да ја започнете истрагата повторно. Одговор што работи додека апликацијата не успева укажува на доверба во сертификатот или API политика, а не на DNS. Тие дефекти се реални и никаква промена на решавачот нема да ги поправи.

Запишете кој чекор не успеал. Таа една линија е она што му треба на следниот човек, а нејзиното запишување трае десет секунди.

Чувајте го синџирот таму каде што следниот човек ќе го најде

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

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

Поврзани статии