Смяна на 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. Щом тази сесия работи и старият край не регистрира оторизирани опити за пълен цикъл на повторна връзка, преместването е завършено.