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

Два планы адрасоў, якія рухаюцца незалежна

Унутраны план апісвае прыватныя адрасы, якія выкарыстоўваюць праграмы: сервер філіяла на 10.55.8.20, прэфікс галаўнога офіса, які маршрутызуецца да яго, і зваротны маршрут. Знешні план апісвае, як два шлюзы дасягаюць адзін аднаго: адрасы партнёраў, парты праслухоўвання і шлях праз інтэрнэт.

Змена правайдэра закранае знешні план. Сама па сабе яна не патрабуе змены ўнутранага плана.

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

Знешні тунель нясе ўнутраную размову

У тунелі шлюз-шлюз знешні загаловак IP адрасуе два шлюзы. Унутраны загаловак па-ранейшаму называе фактычныя канчатковыя кропкі праграмы. Апісанне шлюз-шлюз у RFC 7296 разглядае гэта як звычайную маршрутызацыю, якая дастаўляе трафік праз канчатковыя кропкі тунеля.

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

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

Пераход да новага правайдэра ўсё яшчэ мае кантрольны спіс

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

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

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

Што не захоўваецца: публічная крыніца і сесіі

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

Каб захаваць гэты адрас стабільным, патрэбна прадуманая схема выхаду з уласнай даступнасцю і палітыкай. Яна не дастаецца бясплатна разам з тунелем.

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

Праверце пераход чатырма кантролямі

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

На шлюзе Linux гэтыя тры пакрываюць сярэдзіну гэтага спіса:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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

Падобныя артыкулы