Перанос OpenVPN з TAP на TUN: парадак міграцыі, які працуе

Замена dev tap на dev tun мяняе тое, што нясе тунель, а не толькі яго назву. Інтэрфейс TAP перадае кадры Ethernet у мост, таму кліенты паводзяць сябе так, нібы іх уключылі ў офісны камутатар. Інтэрфейс TUN нясе пакеты IP, таму кліентам патрэбныя маршруты, а процілегламу боку — шлях назад. Кліенты, план адрасоў і зваротны маршрут лакальнай сеткі павінны мяняцца разам з гэтым.

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

Інвентарызуйце, што сапраўды залежыць ад Ethernet

Пералічвайце праграмы, а не хасты. Вызначце, ці кожная выкарыстоўвае маршрутызаваныя службы TCP або UDP, шырокавяшчальнае выяўленне, DHCP з офіснай лакальнай сеткі, не-IP пратакол Ethernet або здагадку, што абодва бакі знаходзяцца ў адной падсетцы. Звычайны доступ па IP перажывае маршрутызаваную схему. А пратакол, якому патрэбныя сырыя кадры Ethernet, не перажывае, і ніякая маршрутызацыя не прымусіць яго працаваць. Праграмам, залежным ад выяўлення, патрэбны замяшчальны механізм, вырашаны да пераключэння, а не падчас яго.

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

Пабудуйце план адрасоў і зваротных маршрутаў

Выберыце прэфікс кліентаў, які не перакрываецца з лакальнай сеткай, старым дыяпазонам моста або любой сеткай, да якой кліент ужо дасягае.dev tun, topology subnet і server 10.78.0.0 255.255.255.0, але гэта фрагмент, а не працаздольны профіль. Захавайце вакол яго ўзгодненую палітыку TLS, ідэнтычнасці, транспарту і доступу і выкарыстоўвайце прэфікс, свабоду якога вы праверылі.

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

Пілот на асобным слухачы

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

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

Перамяшчайце кліентаў групамі з адкатам

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

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

Выведзіце мост толькі пасля прыёмкі

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

Міграцыя завершана не тады, калі інтэрфейс TAP знікае з вываду ip link, а тады, калі маршрутызаваная мадэль доступу працуе для спіса.