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

Що float послаблює і що не послаблює ніколи

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

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

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

Пакет, що переміщує сеанс, має пройти автентифікацію

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

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

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

Виявлення — цілком окремий механізм

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

Додавання параметра ще раз не компенсує відсутності маршруту до нової адреси. Воно не допоможе й тоді, коли партнер мовчить, бо мовчазний партнер ніколи не надсилає того автентифікованого пакета, який щось зсунув би.

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

Коли профілем володіє NetworkManager

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

Перевіряйте збережене з'єднання, а не початковий файл імпорту. Рядок, що вцілів у файлі .ovpn, нічого не доводить, якщо активний менеджер його так і не застосував, і редактор без прапорця для даного параметра теж нічого не доводить про можливості протоколу.

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

Доведіть перехід, а не припускайте його

Виконайте тест так, як відбувається збій. Підключіться, перевірте трафік через тунель, змусьте зовнішню адресу змінитися і потім перевірте три речі: сеанс ще існує, записана адреса партнера зсунулася, і реальний запит досі досягає мети. Усе, що менше за всі три, — часткова відповідь.

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

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

Схожі статті