VPN переїхав: чому ваш клієнт OpenVPN досі набирає стару IP-адресу

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

Дивіться, куди набирає профіль, а не що каже DNS

Відкрийте з'єднання, яке ви справді використовуєте, і прочитайте рядок remote. Числова адреса там ніколи не йде за оновленням імені хоста, хоч би яким правильним став запис.

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

Два файли, одна кінцева точка — ось типова знахідка тут.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Прочитайте наступну спробу підключення клієнта

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

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

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

Знайте, який перезапуск ви робите

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

Налаштування збереження стану теж важливі, бо вони покликані втримати те, що було автентифіковано, а не гнатися за новими адресами.

Найчистіша перевірка — новий запуск із потрібного профілю, а потім погляд на рядок журналу, де названо кінцеву точку. Усе, що ви дізнаєтеся з частково збереженої сесії, — це твердження про цю сесію.

Чотири параметри та їхні окремі завдання

remote з іменем хоста — це параметр, який узагалі уможливлює повторне розв'язування; буквальна адреса в цьому рядку виключає його. resolv-retry керує тим, що відбувається при невдалому пошуку, і 2.6 уже за замовчуванням робить його нескінченним. Тож його додавання нічого не змінює, і він ніколи не планує періодичної перевірки іншої відповіді. Хто каже, що він опитує нові адреси, той плутає відновлення зі свіжістю.

persist-remote-ip — про безперервність, а не про свіжість: він повторно використовує кінцеву точку, яка останньою пройшла автентифікацію, через підтримувані м'які перезапуски. Поки ви тестуєте переїзд, це протилежність тому, що вам потрібно. Вимкніть його для тесту, якщо ваша збірка його вмикає, а потім відновіть, коли нову кінцеву точку доведено. Якщо залишити ввімкненим, успішне перепідключення може нічого не сказати вам про DNS.

float приймає автентифікованого партнера, чия адреса змінилася посеред сесії, і лише в конфігураціях, які це підтримують. Він не оновлює DNS і не піде сам за зміною постачальника. Ставтеся до нього як до функції стійкості для партнерів, що переміщуються, а не як до механізму динамічних адрес для серверів.

Підтвердьте нову кінцеву точку, перш ніж звинувачувати клієнт

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

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

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