Адресът на партньора се смени по средата на сесията: какво прави float в OpenVPN
float позволява на удостоверен партньор да смени външния си адрес по средата на сесията. Той не открива крайни точки, не отваря отново мъртва връзка и не пропуска проверки на самоличността.
Лаптопът преминава от офис Wi-Fi към точка за достъп от телефон, тунелът остава няколко секунди още, а после трафикът спира, докато интерфейсът продължава да твърди, че е свързан. На сървъра списъкът със състоянието продължава да показва стария публичен адрес. Това е ситуацията, за която съществува float, и също ситуацията, в която хората очакват от него да прави много повече, отколкото прави. Правилното очертаване на границата превръща объркващото засичане или в промяна на конфигурацията с един ред, или в напълно друго разследване.
Какво облекчава float и какво никога не облекчава
Обикновено сесията продължава да говори с външния адрес и порт, с които е започнала, а пакетите, пристигащи от другаде, се игнорират. Опцията float премахва тази строга обвързаност, след като партньорът вече се е доказал, така че промененото съответствие на източника може да продължи същата сесия, вместо да бъде изхвърлено. Нищо в криптографските проверки не се променя: ключовете, сертификатите и всякаква HMAC защита остават точно както са конфигурирани.
Това е решение за всеки пакет, а не политика кой може да се свързва. Непозната машина, която изпрати пакет от нов адрес, не е доказала нищо и пакетът ѝ се изхвърля като всеки друг неудостоверен трафик. Само трафик, който преминава през собствената автентикация на сесията, може да премести записания адрес на партньора, и затова е безопасно float да остане включен в среди, където клиентите се движат.
Той не казва нищо и за вътрешния тунел. Преместен външен адрес не преназначава адрес на тунела, не сменя пула и не дава на партньора достъп до нещо ново. Вътре в тунела същата самоличност и същите изпратени маршрути важат преди и след преместването. Придвижването също не предоговаря канала за данни, така че договореният шифър и ключове продължават.
Пакетът, който мести сесията, трябва да се удостовери
Стартирайте сесия по обичайния начин към конфигурирания отдалечен край и float поема какво се случва, когато съответствието се промени. Мобилен оператор, който преномерира по средата на потока, NAT шлюз, който пренаписва съответствието на порта, или лаптоп, който сменя горния канал, дават една и съща форма: удостоверени пакети от нов кортеж, пристигащи в сесия, която още вярва на стария.
Когато ви попитат дали float работи, полезното доказателство е завършено ръкостискане, последвано от приета промяна на източника, а не ред в журнала само за адреса. Съпоставете стария и новия външен адрес със сесията, която е останала жива, после потвърдете, че трафикът наистина е продължил през тунела.
Ако сесията умре, вместо да се премести, пакетът, пристигнал от новия адрес, вероятно не е преминал автентикация или изобщо не е пристигнал. И двата случая изглеждат еднакво от страна на клиента. На сървъра запис на публичния интерфейс ви казва кой от тях имате, преди да пипнете каквато и да е конфигурация.
Откриването е напълно отделен механизъм
float не разрешава имена по таймер и не следи динамичен DNS запис. Ако името на хоста на сървъра започне да се разрешава към нов адрес, неактивният клиент няма причина да го забележи и няма пакет от новата крайна точка, който да удостовери. Този проблем принадлежи на логиката за повторно свързване, на собственото поведение на клиента при повторен опит и на DNS, не на float.
Добавянето на опцията още веднъж не компенсира липсата на маршрут до новия адрес. То не помага и когато партньорът мълчи, защото мълчащият партньор никога не изпраща удостоверения пакет, който би преместил нещо.
Долният защитен екран също има думата. Правило, което разрешава само старата външна крайна точка, блокира променения адрес, преди OpenVPN изобщо да го види, и никаква клиентска конфигурация не поправя това. Прегледайте жизнения цикъл на разрешените адреси като отделна задача; разширяването на правилото до произволен източник разменя малък проблем за голям.
Когато NetworkManager притежава профила
Профилът от командния ред и импортираната връзка са отделни конфигурации и редактирането на едната не засяга другата. Преди да приемете, че опцията не се поддържа, установете какъв тип приставка всъщност използва запазеният профил и къде живеят стойностите му. UUID на профила е идентификаторът, който има значение, когато проверявате или променяте нещо.
Прегледайте запазената връзка, а не оригиналния файл за импорт. Ред, който е останал във файл .ovpn, не доказва нищо, ако активният мениджър никога не го е приложил, а редактор без отметка за дадена опция също не доказва нищо за възможностите на протокола.
Не кърпете пакетирана приставка, за да добавите поведението, особено не с разлика, написана за историческа версия на несвързан компонент. Ако инсталираната интеграция наистина не може да изрази настройката, правилният ход е поддържан профил или друг клиентски път, одобрен от този, който притежава внедряването.
Докажете прехода, вместо да го предполагате
Проведете теста така, както се случва отказът. Свържете се, проверете трафика през тунела, принудете външния адрес да се промени и после проверете три неща: сесията още съществува, записаният адрес на партньора се е преместил и реална заявка още достига до местоназначението си. Всичко по-малко от трите е частичен отговор.
Пазете достъп за възстановяване, докато тествате, защото експериментите с роуминг имат навика да оставят машината, от която работите, в безизходно положение. Серийна конзола или извънлентов маршрут превръща неуспешния тест в петминутно възстановяване вместо посещение на място.
Накрая опишете само случая, който сте упражнили. Успешна смяна на адреса по време на сесия не е доказателство, че миграциите на DNS, друга клиентска реализация или пресъздаден профил ще се държат по същия начин. Документацията за link-options посочва обхвата на опцията точно; журналът на теста ви трябва да посочи коя част от този обхват всъщност сте покрили.