Адрас партнёра змяніўся падчас сеансу: што робіць float у OpenVPN
float дазваляе аўтэнтыфікаванаму партнёру змяніць свой знешні адрас падчас сеансу. Ён не шукае канчатковыя пункты, не адкрывае мёртвую сувязь і не прапускае праверкі асобы.
Ноўтбук пераходзіць з офіснай сеткі Wi-Fi на кропку доступу тэлефона, тунель трымаецца яшчэ некалькі секунд, а затым трафік спыняецца, хоць інтэрфейс па-ранейшаму сцвярджае, што злучаны. На серверы спіс стану працягвае паказваць стары публічны адрас. Гэта менавіта тая сітуацыя, для якой існуе float, і адначасова тая, у якой людзі чакаюць ад яго значна больш, чым ён робіць. Правільнае разуменне мяжы ператварае незразумелае завісанне або ў змену канфігурацыі ў адзін радок, або ў цалкам іншае расследаванне.
Што float паслабляе і што ён не паслабляе ніколі
Звычайна сеанс працягвае размаўляць з тым знешнім адрасам і портам, з якімі пачаўся, а пакеты, што прыходзяць з іншага месца, ігнаруюцца. Параметр float здымае гэтую жорсткую прывязку, калі партнёр ужо даказаў сябе, таму змененае адлюстраванне крыніцы можа працягнуць той жа сеанс замест таго, каб быць скінутым. Нічога ў крыптаграфічных праверках не змяняецца: ключы, сертыфікаты і любая абарона HMAC застаюцца дакладна такімі, як наладжана.
Гэта рашэнне для кожнага пакета, а не палітыка пра тое, каму можна падключацца. Невядомая машына, якая дасылае пакет з новага адраса, нічога не даказала, і яе пакет адкідваецца, як і любы іншы неаўтэнтыфікаваны трафік. Толькі трафік, які праходзіць уласную аўтэнтыфікацыю сеансу, можа перасунуць запісаны адрас партнёра, і менавіта таму float бяспечна пакідаць уключаным у асяроддзях, дзе кліенты перамяшчаюцца.
Ён таксама нічога не кажа пра ўнутраны тунель. Перасунуты знешні адрас не прызначае новы адрас тунеля, не змяняе пул і не дае партнёру доступ да чагосьці новага. Унутры тунеля тая ж асоба і тыя ж прасунутыя маршруты дзейнічаюць да і пасля перамяшчэння. Перамяшчэнне таксама не пераўзгадняе канал даных, таму ўзгоднены шыфр і ключы працягваюць дзейнічаць.
Пакет, які перасоўвае сеанс, павінен прайсці аўтэнтыфікацыю
Пачніце сеанс звычайным чынам супраць наладжанага выдаленага боку, і float вырашыць, што адбываецца, калі адлюстраванне змяняецца. Мабільны аператар, які перанумароўвае паток, NAT-шлюз, які перапісвае адлюстраванне порта, ці ноўтбук, што перамыкае вышэйшы канал, даюць адну і тую ж форму: аўтэнтыфікаваныя пакеты з новага картэжа, якія прыходзяць у сеанс, што ўсё яшчэ верыць у стары.
Калі пытаюцца, ці працуе float, карысным доказам з'яўляецца завершанае рукапацісканне, за якім рушыць прынятая змена крыніцы, а не радок журнала пра адзін адрас. Суаднясіце стары і новы знешнія адрасы з сеансам, які застаўся жывым, затым пацвердзіце, што трафік сапраўды працягнуўся праз тунель.
Калі сеанс памірае замест перамяшчэння, пакет, які прыйшоў з новага адраса, хутчэй за ўсё не прайшоў аўтэнтыфікацыю або не прыйшоў зусім. Абодва выпадкі з боку кліента выглядаюць аднолькава. На серверы запіс на публічным інтэрфейсе скажа, які з іх у вас, перш чым вы кранеце якую-небудзь канфігурацыю.
Выяўленне — цалкам асобны механізм
float не развязвае імёны па таймеры і не адсочвае дынамічны запіс DNS. Калі імя хоста сервера пачынае развязвацца ў новы адрас, у прастойнага кліента няма прычыны гэта заўважыць і няма пакета з новай канчатковай кропкі для аўтэнтыфікацыі. Гэтая праблема належыць логіцы перападключэння, уласным паводзінам кліента пры паўторы і DNS, а не float.
Паўторнае даданне параметра не кампенсуе адсутнасць маршруту да новага адраса. Яно таксама не дапаможа, калі партнёр маўчыць, бо маўклівы партнёр ніколі не дашле аўтэнтыфікаваны пакет, які нешта перасунуў бы.
Ніжні міжсеткавы экран таксама мае голас. Правіла, якое дазваляе толькі старую знешнюю канчатковую кропку, блакуе зменены адрас перш, чым OpenVPN яго ўбачыць, і ніякая кліенцкая канфігурацыя гэтага не выправіць. Разгледзьце жыццёвы цыкл дазволеных адрасоў як асобную задачу; пашырэнне правіла на любую крыніцу мяняе малую праблему на вялікую.
Калі профілем валодае NetworkManager
Профіль каманднага радка і імпартаванае злучэнне — гэта асобныя канфігурацыі, і рэдагаванне адной не закранае другую. Перш чым меркаваць, што параметр не падтрымліваецца, высветліце, які тып плагіна насамрэч выкарыстоўвае захаваны профіль і дзе жывуць яго значэнні. UUID профілю — гэта ідэнтыфікатар, які важны, калі вы нешта агледзіце або змяняеце.
Аглядайце захаванае злучэнне, а не арыгінальны файл імпарту. Радок, які застаўся ў файле .ovpn, нічога не даказвае, калі актыўны менеджар яго так і не прымяніў, а рэдактар без сцяжка для пэўнага параметра таксама нічога не даказвае пра магчымасці пратакола.
Не латуйце ўпакаваны плагін, каб дадаць паводзіны, асабліва не дыфам, напісаным для гістарычнай версіі незвязанага кампанента. Калі ўсталяваная інтэграцыя сапраўды не можа выказаць гэту наладу, правільны крок — падтрыманы профіль або іншы шлях кліента, ухвалены тым, хто валодае разгортваннем.
Дакажыце пераход, а не мяркуйце пра яго
Правядзіце тэст так, як адбываецца збой. Падключыцеся, праверце трафік праз тунель, прымусеце знешні адрас змяніцца, затым праверце тры рэчы: сеанс яшчэ існуе, запісаны адрас партнёра перасунуўся, і рэальны запыт усё яшчэ дасягае мэты. Усё, што менш за ўсе тры, — частковы адказ.
Трымайце доступ для аднаўлення, пакуль тэстуеце, бо эксперыменты з перамяшчэннем маюць звычку пакідаць машыну, з якой вы працуеце, у глухім куце. Паслядоўная кансоль або пазапаласны маршрут ператварае няўдалы тэст у пяціхвіліннае аднаўленне замест выезду на месца.
Нарэшце, апішыце толькі той выпадак, які вы правяралі. Паспяховая змена адраса падчас сеансу не з'яўляецца доказам таго, што міграцыі DNS, іншая рэалізацыя кліента або пераствораны профіль павядуць сябе гэтак жа. Дакументацыя link-options дакладна вызначае абсяг параметра; ваш журнал тэстаў павінен указаць, якую частку гэтага абсягу вы сапраўды пакрылі.