Як збудаваць палітыку пераключэння VPN на маршрутызатары без уцечак

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

Вызначце вынік, перш чым выбраць дэтэктар

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

Гэтыя тры не ўзаемазаменныя. Пераход на WAN трымае службу падтрымкі на тэлефонах, але паказвае ўнутраныя імёны лакальнаму рэзалверу. Рэзервовы тунель захоўвае палітыку, але можа апынуцца на адрасе выхаду, які іншы бок не прымае. Блакаванне слушнае для VLAN разліковых ведамасцяў і няслушнае для гасцявой сеткі, якая ніколі не карысталася тунелем.

Падбярыце дэтэктар пад збой, якога вы сапраўды баіцеся

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

На pfSense практычная схема — гэта група шлюзаў, якую сілкуе dpinger; ён правярае адрас маніторынгу і пазначае шлюз як непрацаздольны, калі страты або затрымка перавышаюць парогі. Накіруйце гэты маніторынг на нешта за межамі тунеля, напрыклад на хост у далёкай LAN або на публічны адрас, да якога вы дабіраецеся праз яго. Нацэльванне на ўласны адрас партнёра тунеля вымярае тую частку, пра якую вы ўжо ведаеце, што яна жывая.

Пабудуйце групу так, каб рэзерв заставаўся апошнім сродкам

Выкарыстоўвайце ўзроўні, а не адзін плоскі спіс членаў. Асноўны на ўзроўні 1, рэзервовы тунель на ўзроўні 2, WAN на ўзроўні 3 толькі для тых VLAN, чыя палітыка гэта дазваляе. У pfSense гэта знаходзіцца ў System > Routing > Gateway Groups: дадайце абодва шлюзы, дайце ім розныя ўзроўні, усталюйце Trigger Level на member down plus packet loss, захавайце, а затым прымяніце групу як стандарт інтэрфейса або ў полі Gateway тых правілаў файрвола, якім гэта патрэбна.

Для асобніка кліента OpenVPN на pfSense 2.5 і пазней налада Default Gateway асобніка вырашае, ці наогул тунель замяняе сістэмны маршрут па змаўчанні. Маршрутызацыя палітыкі па правіле паводзіць сябе як трэба толькі тады, калі маршрут, які вы мяркуеце, сапраўды ўсталяваны. Пасля змены праверце Status > Gateways, а не давярайце значку стану тунеля.

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

Закрыйце шляхі, якімі тунель ніколі не валодаў

Спачатку ўцечкі DNS. Рэзалвер працягвае адказваць на WAN і перасылае праз яго, таму імёны працягваюць вырашацца праз правайдра, пакуль трафік прыкаваны да тунеля. Абмяжуйце выходныя інтэрфейсы рэзалвера, перанясіце ўнутраны рэзалвер на кліентаў і заблакуйце порт 53 для ўсяго іншага ў VLAN толькі-VPN.

IPv6 патрабуе ўласнага рашэння. Двухстэкавы LAN можа страціць тунель і захаваць працаздольны глабальны маршрут па змаўчанні IPv6, таму браўзеры аддаюць перавагу IPv6 і выходзяць праз WAN, пакуль IPv4 выглядае цалкам ізаляваным. Альбо накіруйце IPv6 у тунель, альбо спыніце абвяшчаць глабальны прэфікс, пакуль тунель не працуе. Палова палітыкі горш за адсутнасць, бо выглядае так, нібыта працуе.

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

Праверце падзенне, дрыжанне і шлях назад

Вырвіце асноўны пры бясшкодным трафіку, а затым прачытайце чатыры рэчы: Status > Gateways для станаў членаў групы, pfctl -ss для станаў, якія ўсё яшчэ прывязаныя да старога шлюза, traceroute з кліента для шляху выхаду і запыт да рэзалвера, каб убачыць, які сервер адказаў.

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

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

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