Зміна VPN-провайдера: плануйте ім'я хоста, а не лише IP
Новий запис DNS не переносить наявні сесії. Сплануйте, хто керує іменем, коли кожен клієнт його розв'язує і як ви виведете з експлуатації стару кінцеву точку.
Ваш запис DNS правильний, заміна здорова, і все ж деякі клієнти годинами набирають стару адресу. Кілька одразу зазнають невдачі на імені, яке розв'язується і ніколи не відповідає. Обидва результати походять з однієї прогалини: ім'я хоста змінює те, що клієнт шукає, а не коли він це шукає, і не те, чому він довіряє, коли надходить відповідь.
Симптом: правильний запис, застарілі тунелі
Профіль, який зберігає ім'я, — це не клієнт, який постійно його розв'язує. Більшість розв'язує його один раз, під час застосування конфігурації або коли піднімається тунель, а потім використовує цю адресу до кінця сесії. Довгий TTL поверх цього — причина, чому перехід треба планувати навколо повторних підключень, а не навколо редагування DNS.
Жодна з цих двох поведінок не є дефектом, і саме це робить симптом заплутаним. Клієнт працює з відповіддю, отриманою раніше, і ніщо на боці сервера не показує, якою була ця відповідь. Заплануйте повторне підключення у вікно обслуговування і скажіть користувачам, що вони побачать, або витратьте вікно на відповіді на заявки. Черга однакових звітів — звичайний результат.
Хто керує іменем і що перевіряє клієнт
Контроль над зоною визначає, наскільки швидко може рухатися міграція. Тримайте запис у реєстратора, до якого ви можете увійти, і запишіть, хто ще може його змінити.
Довіра не йде за іменем. Клієнт на основі TLS може перевіряти ідентичність сертифіката або закріплене ім'я, тоді як WireGuard автентифікує відкритий ключ партнера і повністю ігнорує ім'я хоста. Ця різниця вирішує, чи достатньо редагування DNS, чи кожному профілю потрібен новий відбиток. Зміна запису ніколи не повинна авторизувати кінцеву точку, яку ніхто не схвалив.
Тримайте адміністративний доступ і доступ для відновлення далеко від публічного імені клієнта. Втрата хостинг-акаунта не повинна коштувати вам ще й запису, який перенаправляє клієнтів. Зберігайте шлях відновлення там, де він не залежить від провайдера, якого ви залишаєте.
Коли кожен клієнт перечитує ім'я
Момент розв'язання — властивість кожного клієнта, тому перевірте реалізацію, яку ви справді постачаєте, перш ніж обіцяти вікно переходу. wg-quick розв'язує кінцеву точку під час підняття інтерфейсу і зберігає цю адресу до перезапуску тунелю. Клієнт OpenVPN шукає ім'я під час підключення, а чи подивиться він знову під час повторного підключення, залежить від його опцій.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Мобільні клієнти — звичайний сюрприз, бо вони можуть зберігати розв'язану адресу під час сну або зміни мережі. Публікуйте записи A і AAAA лише якщо заміна відповідає в обох родинах. Адреса, що відповідає в одній родині, нічого не доводить про іншу, а мертвий запис AAAA додає тайм-аут до кожної спроби. Задокументуйте поведінку розв'язання для кожного клієнта, який ви підтримуєте, а потім тестуйте на пристроях, які люди справді використовують.
Повторне підключення в більшості клієнтів — дія користувача, і сервер не може її змусити. Внесіть цей крок у нотатку про обслуговування, з рядком про те, що побачить користувач, коли це станеться.
Переходьте на основі доказів, потім виведіть стару кінцеву точку
Перед перемиканням доведіть кожен шар на заміні: слухач відповідає, міжмережевий екран пропускає порт, маршрути повертаються правильно, ім'я розв'язується в нову адресу і відома ідентичність приймається. Слухач, що приймає з'єднання, — не те саме, що той, який завершує рукостискання, тому тестуйте рукостискання, а не порт. Тримайте поточний список відкликання поруч із конфігурацією, бо відновлена резервна копія знову створює список партнерів таким, яким він був, і знову відкрила б доступ, який ви вже закрили. Запишіть, з якою ідентичністю ви тестували, бо «це працює» — не доказ, який хтось може повторити.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesПід час переходу спостерігайте за спробами підключення на обох кінцевих точках для однієї й тієї самої ідентичності. Клієнт, який усе ще автентифікується проти старої адреси, — це профіль або кешована відповідь, що так і не переїхала. Виведіть стару кінцеву точку за планом із датою, бо дві служби, що приймають одну ідентичність, залишають дві двері відчиненими.
Тест переходу — це сесія застосунку через нову кінцеву точку, а не ping. Щойно ця сесія працює і стара кінцева точка не реєструє жодної авторизованої спроби протягом повного циклу повторного підключення, переміщення завершено.