Застарілий запис DDNS чи зламана кінцева точка VPN: як їх розрізнити

Зовні застаріле ім’я хоста і зламаний VPN виглядають однаково. Клієнт розв’язує ім’я, ім’я вказує кудись, а з’єднання або завершується за тайм-аутом, або відхиляється. Одне — проблема оновлення DNS, друге — проблема автентифікації чи пересилання, і різниця стає очевидною лише тоді, коли ви порівняєте опубліковану адресу з адресою, яку ваша лінія насправді має.

Дві несправності, що виглядають однаково

Перша несправність у тому, що запис усе ще містить учорашню адресу WAN. Друга — у тому, що запис правильний, а тунель відхиляє вас зі своїх причин. Обидві дають те саме повідомлення на клієнті, і виникає спокуса почати перегенеровувати сертифікати.

Тут важливий порядок. Перевірка DNS триває хвилину і є оборотною. Перегенерування CA не є ні тим, ні іншим.

Спершу порівняйте адреси

Запитайте у власника мережі, яку адресу лінія має зараз, потім запитайте в DNS, що він публікує. dig +short vpn.example.com дає відповідь, яку отримає ваш клієнт, а dig @1.1.1.1 vpn.example.com показує, чи бачить інший резолвер щось інше. Якщо ці два не збігаються, ви дивитеся на поведінку кешу, а не на зламаний оновлювач.

Рекурсивна відповідь може відставати від оновлення на свій TTL, тому тримайте авторитетний запис і те, що закешував ваш ноутбук, в окремих ящиках.

Що насправді являють собою облікові дані оновлювача

Старі пристрої DDNS часто автентифікуються самим паролем облікового запису, тому зміна цього пароля тихо їх ламає. Вони продовжують намагатися зі старим значенням і не повідомляють нічого корисного. Настанова No-IP щодо пароля пристрою документує саме цю проблему сумісності на старому обладнанні, і розумна відповідь — облікові дані оновлення з обмеженим обсягом, а не слабший пароль облікового запису.

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

Огляньте несекретний стан оновлювача: час останнього успіху, категорію відповіді та ім’я хоста, яке він вважає своїм. Відмова в облікових даних і збій з’єднання потребують різних виправлень.

Чого не може зробити виправлення DNS

Виправлення запису не створює вхідної доступності. Якщо лінія стоїть за NAT операторського рівня, жодне ім’я хоста не змусить вхідне з’єднання працювати. Воно також не відкриває правило брандмауера і не пересилає порт. І це ніколи не причина вимикати перевірку сервера на клієнті — крок, який люди роблять, вирішивши, що проблема обов’язково в сертифікаті.

І навпаки, зміна пароля VPN не є виправленням застарілого DNS. Вона лише додає другу несправність до того самого тікета.

Перепідключіться і доведіть це від початку до кінця

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

Тримайте оновлювач у контрольному списку ротації поруч з обліковим записом VPN. Один передбачений власник запису, чинні облікові дані й спостережуваний успіх — це те, що запобігає наступній версії цього тікета.