Промена 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. Када та сесија проради и стара крајња тачка не забележи ниједан овлашћени покушај током пуног циклуса поновног повезивања, премештање је завршено.