Тунель піднято, тож чому приватне ім'я досі не розв'язується?

У з'єднанні все виглядає правильно: тунель піднято, консоль показує приватну кінцеву точку, але кожен запит зазнає невдачі під час розв'язання імен. Природний крок — звинувачувати тунель, який зазвичай виявляється невинним. Запит надсилається на сервер, який нічого не знає про приватну зону. Жодна зміна маршрутизації не змінить цю відповідь, бо проблема в тому, кого запитали.

Який резолвер отримав запит?

Знайдіть резолвер, прив'язаний до кожного з'єднання, перш ніж взагалі дивитися на тунель. Linux показує сервери для кожного з'єднання командою стану резолвера, а macOS показує резолвери з областю дії у виводі конфігурації DNS. Якщо відповідь досі надходить від домашнього роутера, з'єднання тунелю ніколи не запитувалося.

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

Тут змішуються два етапи: сервер, що проштовхує адресу резолвера, і клієнт, який встановлює її на активному з'єднанні. Профіль може містити параметр, і журнал може показувати його надходження, поки операційна система продовжує використовувати старий сервер. Порівняйте журнал із тим, що повідомляє з'єднання, і довіртеся з'єднанню.

Використовуйте адресу, на яку хмарна мережа справді відповідає

Хмарні мережі зазвичай відповідають на приватні імена через зарезервовану адресу, зсунуту на два від основи діапазону, тому мережа, що починається з 10.0.0.0, відповідає на 10.0.0.2. Деякі провайдери також публікують локальний для з'єднання резолвер, який працює без знання діапазону, що допомагає, коли мережу побудував хтось інший. Запитайте адресу-кандидат напряму, перш ніж передавати її комусь. Адреса, яка не є резолвером, виглядає точно як відкидання міжмережевим екраном, бо запит просто ніколи не отримує відповіді.

Якщо прямий запит відповідає зсередини мережі, але не через тунель, резолвер у порядку, а шлях між двома точками — ні. Цей результат переносить розслідування на маршрути, пересилання та правила доступу, а не на профіль клієнта.

Тунель не несе простір імен

Пакети проходять; імена — ні. Кожній стороні треба сказати, який простір імен належить іншій, і це окремий об'єкт, яким володіє той, хто тримає зону. Звичайна форма — пересилання для одного простору імен, спрямоване на резолвер, доступний через тунель.

На практиці кожному напрямку потрібне своє правило, бо сторона, яка володіє зоною, має надсилати запит далі. Обидва напрямки вимагають, щоб джерело запиту було маршрутизоване й дозволене, а сторона, що відповідає, має повертати відповіді через тунель, а не в інтернет. Тримайте пересилання вузьким, щоб від з'єднання залежав лише приватний простір імен. Надсилання кожного запиту через нього перетворює малу залежність на повний збій у мить, коли тунель падає.

Пройдіть межі по порядку

Перевірте резолвер, встановлений на активному з'єднанні, потім прямий запит до цього резолвера, потім той самий запит з дальнього боку і нарешті застосунок, що використовує те саме ім'я. Кожен крок ізолює одну межу, тому збій підказує, де дивитися, замість того щоб починати розслідування заново. Відповідь, яка працює, поки застосунок зазнає невдачі, вказує на довіру до сертифіката або політику API, а не на DNS. Ці несправності реальні, і жодна зміна резолвера їх не виправить.

Запишіть, який крок не вдався. Цей єдиний рядок — те, що потрібно наступній людині, і на його запис іде десять секунд.

Тримайте ланцюг там, де наступна людина його знайде

Запишіть проштовхнутий резолвер, правило пересилання, дозволене джерело запитів і кінцеву точку, що відповідає, в одному місці. Коли приватне ім'я знову не розв'яжеться, запис покаже, чи змістився тунель, чи змінилася адреса резолвера, чи було звужено правило. Без нього кожен інцидент починається з нуля і закінчується тими самими трьома здогадками.

Тримайте запис достатньо коротким, щоб він залишався точним: чотири рядки, дата і ім'я власника кожної частини. Застарілий запис гірший за відсутній, бо виглядає авторитетно, поки він помилковий.