Адзін службовы IP на кожным вузле OpenVPN: што ён не робіць
Зарэзервуйце прыватны /32 на кожным вузле, каб кліент дасягаў таго сервера, які абраў. Адрас не забяспечвае пераключэнне пры збоі, не пераносіць сесіі і не выбірае здаровы вузел.
Кліент падключаецца да аднаго з некалькіх OpenVPN сервераў і потым мае патрэбу ў невялікім сэрвісе, які працуе на гэтым вузле: старонка стану, кропка метрык, агент рэзервовага капіравання. Калі кожны вузел атрымлівае той жа прыватны адрас сэрвісу, канфігурацыя кліента становіцца аднолькавай незалежна ад таго, на які сервер ён трапіў. Гэтая зручнасць рэальная, і яе таксама лёгка перачытаць: агульны адрас паведамляе, да якога вузла вы дабраліся, а не тое, што нешта лішняе.
Чаму аднолькавы адрас на кожным вузле працуе
Кожны вузел валодае адрасам лакальна і адказвае за яго, таму кліент, які дасягае яго праз свой бягучы тунэль, атрымлівае сэрвіс на далёкім канцы гэтага тунэля. Паміж вузламі нічога не ўзгадняецца, і ніякі трафік не пераходзіць з аднаго вузла на другі.
Адрас — гэта лакальная метка, паўтораная, а не рэплікаваная. Кожны вузел адказвае толькі за сябе, і ніводзін з іх не перасылае трафік за адрас на іншым вузле. Менавіта гэта захоўвае адну канфігурацыю кліента сапраўднай, пакуль серверы застаюцца незалежнымі. Гэта таксама прычына, чаму дызайн не патрабуе ўзгаднення паміж вузламі.
Менавіта таму адна і тая ж канфігурацыя працуе на кожным серверы без пратаколу маршрутызацыі паміж імі. І менавіта таму дызайн нічога не кажа пра здароўе: адрас існуе на нездаровым вузле гэтак жа, як на здаровым, бо ён прывязаны да хоста, а не да таго, што сэрвіс карысны.
Прызначце яго loopback, а не тунэлю
Размяшчэнне адраса на loopback-інтэрфейсе адвязвае яго ад часу жыцця любой тунэльнай прылады, таму перападключэнне або перазагрузка канфігурацыі не выдаляе яго. Адрас існуе, пакуль існуе хост.
Адрас на lo — гэта не фільтр. Сэрвіс усё яшчэ павінен слухаць яго, і файрвол хоста ўсё яшчэ ацэньвае рэальны ўваходны шлях, які прыходзіць праз тунэльны інтэрфейс. Хто думае, што loopback азначае толькі лакальна, у выніку або блакуе законных кліентаў, або выкрывае нешта, чаго не меў намеру.
Замацуйце прызначэнне праз сеткавую канфігурацыю хоста, а не дадавайце яго зноў з хук. Хук наладкі не спрацуе на вузле, дзе тунэль не ўзняўся, і адрас сэрвісу не павінен залежаць ад актыўнасці тунэля. Змясціце адрас у канфігурацыю інтэрфейса, якой валодае ваша дыстрыбуцыя, потым адзін раз перазагрузіце і праверце яго. Перазагрузка — адзіны тэст, які перажывае наступную змену канфігурацыі.
ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev loПраштурхніце адзін маршрут і майце на ўвазе адзін пункт прызначэння
Кліенту патрэбен маршрут да хоста для адраса, які прапануе сервер, да якога ён падключаецца. Паколькі кожны сервер прапануе той жа пункт прызначэння, профіль не змяняецца, калі кліент перамяшчаецца.
Праверце, што ўсталяваў кліент, перш чым вінаваціць сэрвіс.
ip route get 10.250.0.1Для HTTP-сэрвісу дайце адрасу імя і сертыфікат для гэтага імя. Агульны IP — гэта не ідэнтычнасць, і ён не адмяняе праверку TLS, а таксама не апраўдвае капіраванне аднаго прыватнага ключа на кожны вузел. Імя, якое развязваецца ў агульны адрас, пакідае гісторыю з сертыфікатам звычайнай і дазваляе захаваць асобную ідэнтычнасць для кожнага вузла, калі яна патрэбна.
Што агульны адрас не можа зрабіць
Ён не забяспечвае пераключэнне пры збоі. Калі выбраны вузел гіне, адрас гіне разам з ім, і кліент мусіць перападключыцца ў іншае месца.
Ён не пераносіць жывую TCP-сесію, бо новае злучэнне завяршаецца на іншым хосце без ведаў пра старое.
Ён не выбірае здаровы вузел, не балансуе нагрузку і не сінхранізуе даныя паміж вузламі. Кожнае з гэтага — асобны механізм з уласнымі рэжымамі адмоў, і ўяўленне, што хітрасць з адрасацыяй іх пакрывае, — гэта шлях, якім просты дызайн набывае незаслужаную рэпутацыю ўстойлівасці. Калі два тунэлі актыўныя адначасова, сэнс пункта прызначэння становіцца няпэўным, таму трымайце дапушчэнне пра адзін актыўны тунэль яўным.
Захавайце ідэнтычнасць сэрвісу разам з імем
Запішыце, што азначае адрас: ён дасягае сэрвіс на вузле, да якога кліент зараз падключаны. Гэтае адно сказ прадухіляе большасць непаразуменняў, якія прыцягвае гэты шаблон.
Затым дакументуйце часткі разам: адрас, інтэрфейс, на якім ён жыве, маршрут, які прасоўвае сервер, і імя ды сертыфікат, якія прадстаўляе сэрвіс. Чатыры малыя факты, якія будучы чытач зможа праверыць, у тым парадку, у якім ён іх правярацьме.
Калі патрабаванне — стабільны пункт прызначэння для лакальнага сэрвісу вузла, шаблон падыходзіць і амаль нічога не каштуе.
Калі патрабаванне — даступнасць, падніміцеся на ўзровень вышэй: балансіроўшчык нагрузкі, імя сэрвісу з праверкамі стану або сістэма аркестрацыі, якая ўжо ўмее замяняць вузел.
Рашэнне, прынятае рана, пакідае агульны адрас тым, чым ён ёсць, — зручнай меткай, а не кампанентам, ад якога ціха чакаюць працы, для якой ён ніколі не быў распрацаваны.