Тры віды адмоваўстойлівасці OpenVPN на pfSense, тры механізмы

«OpenVPN failover» на pfSense ахоплівае як мінімум тры незвязаныя праекты, і кожны з іх патрабуе свайго механізму. Утрыманне тунеля жывым праз рэзервовы інтэрнэт-канал, перападключэнне да іншага сервера і накіраванне трафіку LAN у іншы ўжо ўсталяваны тунель — гэта не варыянты адной функцыі. Выберыце збой, ад якога вы абараняецеся, перш чым будаваць групу шлюзаў. Група, якая выпраўляе адзін з іх, нічога не робіць для двух іншых.

Назавіце збой, перш чым будаваць групу

Запішыце сказ, які хочаце бачыць праўдзівым падчас збою. «Тунель перападключаецца праз рэзервовы WAN» і «філіял па-ранейшаму даходзіць да праграмы праз іншы тунель» — розныя сказы. Толькі першы пра транспарт.

Затым суаднясіце яго з механізмам. Страта лакальнага WAN — гэта праблема выбару інтэрфейсу, мёртвая аддаленая канцавая кропка — праблема спісу падключэнняў, а непрыдатны шлях усярэдзіне ўсталяванага тунеля — праблема маршрутызацыі і палітыкі.

Лакальны WAN: перанесці транспарт

Для кліента OpenVPN на pfSense схема з некалькімі WAN, якая падтрымліваецца, выбірае адпаведную групу шлюзаў як інтэрфейс, да якога прывязваецца кліент. Менавіта гэта дазваляе знешняму злучэнню выходзіць праз рэзервовы канал, калі асноўны адмаўляе. Само па сабе гэта не мяняе маршрутызацыю ўнутранага трафіку.

Серверны бок той самай схемы асобны. Серверу OpenVPN, які павінен быць даступным па некалькіх публічных адрасах, патрэбен слухач і ўваходная палітыка для кожнага з гэтых запісаў, а не толькі кліент, які ўмее набіраць праз два каналы. Адзін працоўны публічны запіс не даказвае, што другі наладжаны.

Правіла маршрутызацыі на аснове палітыкі для перасылаемых пакетаў LAN — не тая налада, якая пераносіць лакальна створанае транспартнае злучэнне VPN. Гэта два розныя пошукі, і змена аднаго не мяняе другога.

Аддаленая канцавая кропка: іншы сервер

Альтэрнатыўны remote — функцыя спісу падключэнняў. Кліент спрабуе наступны запіс, калі бягучы не адказвае, што карысна, калі недоступны канкрэтны хост, а не калі ляжыць ваш уласны ўзыходны канал. Абодва збоі з працоўнага месца карыстальніка выглядаюць падобна і патрабуюць розных выпраўленняў.

Кожны кандыдат павінен быць сапраўднай заменай: сумяшчальная аўтэнтыфікацыя, сумяшчальная кліенцкая палітыка і доступ да тых самых прыватных рэсурсаў. Другое імя хоста, якое развязваецца ў тую ж непрацаздольную інфраструктуру, — не рэзерв. Сервер без патрабаванага маршруту таксама не, як бы здарова выглядала яго рукапоцісканне.

Гэты механізм таксама не прымушае два тунелі перасылаць адначасова. Ён замяняе адно злучэнне іншым, паслядоўна, і разрыў паміж імі бачны ўсяму, што працавала.

Шлях тунеля: выбраць іншы выхад

Калі два тунелі ўжо паднятыя і трафік павінен выкарыстоўваць здаравейшы, механізм — гэта прызначаны інтэрфейс VPN з уласным шлюзам плюс яўнае правіла палітыкі, якое накіроўвае туды патрэбны трафік. Група шлюзаў паверх гэтых прызначаных інтэрфейсаў можа выяўляць прыярытэт і маніторынг.

Гэты праект пра выбар, а не пра аднаўленне. Перавод новых злучэнняў на другі тунель нічога не кажа пра сеансы, ужо ўсталяваныя на першым, і нічога пра тое, ці прыме аддалены бок новы адрас крыніцы. Ставіцца да яго як да механізму аднаўлення — гэта спосаб завысіць чаканні.

Калі патрабаванне ў тым, каб наяўныя сеансы выжылі, скажыце гэта прама. Большасць рэалізацый не пераносяць жывы паток паміж тунелямі, і праектаванне так, нібы пераносяць, дае адмоваўстойлівасць, якая выглядае правільна на схеме і на практыцы скідвае кожнае адчыненае злучэнне.

Маніторы, NAT і правіла fail-closed

Манітор павінен правяраць тое, што тунель павінен дастаўляць. Мэта, якая адказвае з боку партнёра тунеля, але не з прыкладнай сеткі за ім, паведаміць пра здаровы стан, пакуль карыстальнікі нічога не бачаць. Недаступная дыягнастычная мэта паведаміць пра мёртвы стан, пакуль шлях у парадку. Выбірайце адрас усвядомлена і пацвердзіце, што ён даступны толькі праз прызначаны тунель.

Праверце зыходны NAT для абодвух выхадаў. Працоўнае пераўтварэнне на асноўным не апісвае адрас крыніцы рэзерву, а аддаленай прыватнай сетцы патрэбен зваротны маршрут, які адпавядае той крыніцы, якую вы прадстаўляеце. Пераўтварэнне, правільнае на адным шляху, можа ціха быць няправільным на другім.

Далей вырашыце, што адбываецца з трафікам, які ніколі не павінен выкарыстоўваць WAN. У pfSense вызначаныя паводзіны для правілаў, чый выбраны шлюз недаступны, а пазнейшае шырокае правіла пропуску або маршрут па змаўчанні могуць адмяніць вашу задуму. Запішыце заблакаваны вынік як патрабаванне і праверце яго, адключыўшы шлях.

Правярайце страту і аднаўленне асобна, трафікам, які вам дазволена генераваць, і сачыце за трыма рэчамі адначасова: WAN, які нясе знешняе злучэнне, тунелем, які нясе запыт праграмы, і шляхам, які выбірае адказ. Пара зялёных індыкатараў шлюза не ўваходзіць у гэтыя тры. Кіраўніцтва Netgate па некалькіх WAN апісвае прывязку транспарту і экспартаваныя кліенцкія альтэрнатывы, на якіх гэта трымаецца.