Тунел је активан, па зашто приватно име и даље не успева?

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

Који резолвер је добио упит?

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

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

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

Користите адресу на коју cloud мрежа заиста одговара

Cloud мреже обично одговарају на приватна имена преко резервисане адресе померене за два од основе опсега, па мрежа која почиње на 10.0.0.0 одговара на 10.0.0.2. Неки провајдери објављују и link-local резолвер који ради без познавања опсега, што помаже када је мрежу изградио неко други. Питајте кандидатску адресу директно пре него што је пошаљете било коме. Адреса која није резолвер изгледа тачно као одбацивање од стране заштитног зида, јер упит једноставно никада не добије одговор.

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

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

Пакети прелазе; имена не. Свакој страни треба рећи који простор имена припада другој, а то је засебан објекат који поседује онај који држи зону. Уобичајен облик је прослеђивање за један простор имена, усмерено на резолвер доступан преко тунела.

У пракси сваки смер треба своје правило, јер страна која поседује зону мора да пошаље упит даље. Оба смера захтевају да извор упита буде рутиран и дозвољен, а страна која одговара мора да враћа одговоре кроз тунел, а не ка интернету. Држите прослеђивање уским, тако да само приватни простор имена зависи од везе. Слање сваког упита кроз њега претвара малу зависност у потпуни прекид у тренутку када тунел падне.

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

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

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

Чувајте ланац тамо где ће га следећа особа наћи

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

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