Перенесення VPN-сервера на нову публічну IP: що перевірити насамперед

Повторне призначення адреси займає хвилину. Наступний тиждень — це місце, де перенесення ламається, і рідко там, де підказує консоль провайдера. Нова публічна IP згадується в чотирьох місцях: сокет, на якому слухає демон, якір довіри, який перевіряють клієнти, кожне правило, що називає стару адресу, і DNS-запис, який їх з'єднує. Два перенесення виглядають з панелі керування однаково, але поводяться зовсім по-різному: призначити адресу заново на машині, якою ви керуєте, або підняти другий endpoint і перевести клієнтів на нього. Перевірки нижче ставлять дешеві збої першими, і кожен розділ зазначає, до якого перенесення він належить.

Заміна на місці й паралельний перехід — різні завдання

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

Паралельний endpoint — це другий хост, який виконує ту саму роботу. Побудуйте його, перевірте одним профілем і залиште старий відповідати, доки новий не доведе себе на реальному шляху. Ціна — стан. Без спільних записів peer, відкликань і журналювання у вас дві мережі, які випадково ділять ім'я.

Знайдіть кожне місце, де записано стару адресу

Почніть із текстового пошуку, бо конфігураційні файли — це легка половина. Пошукайте в конфігурації демона, фрагментах брандмауера, цілях моніторингу та будь-якому згенерованому клієнтському пакеті на диску. Додайте адресу IPv6, якщо таку публікуєте; перенесення, яке стежить лише за A-записом, залишає двостекових клієнтів на старому шляху.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

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

Запишіть інвентаризацію до того, як щось змінювати; вона ж служить скриптом відкату.

Клієнти за іменем хоста відновлюються; клієнти з буквальною IP замовкають

Якщо клієнти приходять на сервер за іменем хоста, перехід — переважно проблема DNS, і TTL, заданий учора, вирішує, наскільки все буде погано. Резолвери кешують, stub-резолвери кешують ще раз, і багато клієнтів шукають ім'я лише при новому з'єднанні, тож установлений тунель зберігає свою початкову адресу.

Якщо endpoint — буквальна адреса, нічого не розв'язується заново і ніщо не записує скаргу. WireGuard зберігає розв'язану адресу сокета: Endpoint = vpn.example.net:51820 стає IP тієї миті, коли запускається wg-quick up, і залишається цією IP, доки ви її не зміните. OpenVPN поблажливіший: він розв'язує ім'я хоста remote під час підключення і з resolv-retry infinite знову пробує DNS при перепідключенні. З буквальною IP обидва далі набирають машину, якої вже немає.

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

Довіра не переїжджає разом з адресою

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

Сервери на TLS — зворотний випадок. Сертифікат прив'язаний до імені, і клієнт, який набирає адресу, порівнює набране з альтернативними іменами суб'єкта. Підключіться за IP до сертифіката, що несе лише DNS SAN, і перевірка не пройде: імені, яке використав клієнт, у сертифікаті немає. Перевипуск з IP SAN виправляє це одне з'єднання й робить наступне перенесення гіршим. Збереження імені хоста в профілі й залишення verify-x509-name на місці тримає перевірку суворою, поки адреса під ним змінюється.

Потім перевірте, до чого прив'язаний демон; сокет, прикріплений до старої адреси, тихо відмовляє. Сервер OpenVPN, запущений з local 203.0.113.10, відмовляється підніматися, щойно ця адреса зникає, а слухач на 0.0.0.0 слідує за зміною безкоштовно. NAT ділиться так само: MASQUERADE слідує за будь-якою адресою, яку машина має зараз, а статичний SNAT --to-source 203.0.113.10 далі переписує на адресу, якою ви більше не володієте, тож зворотний трафік зникає. Якщо нова адреса приходить з іншим upstream-шлюзом, перевірте rp_filter: фільтрація зворотного шляху відкидає зворотний трафік, що надходить на інтерфейс, якого ядро не очікувало.

Порядок переходу й докази, що він спрацював

Знизьте TTL за день, підніміть новий слухач і доведіть його профілем, який є лише у вас. Перевірка зсередини тієї ж мережі не доводить майже нічого, тому використайте телефон у стільниковій мережі й перевірте те, що тунель має переносити, а не ping до endpoint.

Стежте за обома адресами протягом усього вікна. wg show all latest-handshakes на новому хості або файл стану OpenVPN скаже, скільки peer'ів справді переїхало. Коли в нового endpoint'а є очікувані peer'и, а в старого лише відсталі, виведіть старий слухач з експлуатації, видаліть застаріле правило NAT і приберіть адресу з брандмауера провайдера. Видалення старого слухача — це крок, який пропускають, і він закриває щілину, де застарілий профіль ще доходить до старої мережі.

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