Пераключэнне VPN: калі зваротны шлях застаецца на старым тунелі

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

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

Запішыце маршруты абодвух сайтаў да тэсту

Для кожнага абароненага прэфікса запішыце асноўны маршрут, рэзервовы маршрут і перавагу, якая выбірае паміж імі. Уключыце LAN-шлюз за кожнай канцавой кропкай VPN, бо канцавая кропка рэдка бывае апошнім скачком.

Статычныя метрыкі, адсочваемыя маршруты і дынамічная маршрутызацыя выражаюць прыдатнасць па-рознаму. Ведайце, што выкарыстоўвае ваш дызайн і што трэба, каб альтэрнатыва стала актыўнай. Запішыце ўмову побач з маршрутам, напрыклад, ніжэйшую метрыку, пакуль праверка не завершыцца няўдачай.

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

Назірайце за запытамі і адказамі на кожнай фазе

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

Калі запыты пераносяцца, а адказы не, праверце маршрут аддаленага сайта да прэфікса кліента і яго перавагу для рэзерву. Гэта рашэнне аб маршрутызацыі, а не адмова тунеля.

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

Кіруйце станам сеанса пры змене шлюза

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

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

Тэстуйце праграму, якая ўтрымлівае доўгі сеанс, а не толькі новы запыт.

Аднавіце асноўны шлях і праверце на флапінг

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

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