Перанос VPN-сервера на новы публічны IP: што праверыць перш за ўсё

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

Замена на месцы і паралельны пераход — розныя задачы

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

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

Знайдзіце ўсякае месца, дзе запісаны стары адрас

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

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

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

Запішыце інвентар да таго, як нешта змяніць; ён жа служыць скрыптам адкату.

Кліенты з іменем хоста аднаўляюцца; кліенты з літаральным IP маўчаць

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

Калі endpoint — літаральны адрас, нішто не пераразвязае і нішто не піша скаргу. WireGuard захоўвае развязаны адрас сокета: Endpoint = vpn.example.net:51820 становіцца IP у момант, калі запускаецца wg-quick up, і застаецца гэтым IP, пакуль вы яго не зменіце. OpenVPN больш памяркоўны: ён развязвае імя хоста remote падчас злучэння і з resolv-retry infinite зноў спрабуе DNS пры перападключэнні. Але з літаральным IP абодва працягваюць набіраць машыну, якой ужо няма.

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

Давер не пераносіцца разам з адрасам

WireGuard аддзяляе ідэнтычнасць ад дасяжнасці, што робіць перанос адраса амаль бясплатным. Peer ідэнтыфікуюцца публічным ключом, а endpoint — гэта толькі тое, куды цяпер ідуць пакеты; хост абнаўляе endpoint peer з адраса крыніцы апошняга аўтэнтыфікаванага пакета. Бяздзейны peer усё ж мае патрэбу ў прычыне звярнуцца да новага месца, і ён даведаецца адрас толькі калі яго сесія састарэе, а паўторы handshake няўдала скончацца ў бачным месцы. Хуткі дапаможнік WireGuard апісвае поле endpoint.

Серверы на TLS — адваротны выпадак. Сертыфікат прывязаны да імені, і кліент, які набірае адрас, параўноўвае набранае з альтэрнатыўнымі імёнамі суб'екта. Падключыцеся па IP да сертыфіката, які нясе толькі DNS SAN, і праверка праваліцца: імя, якое выкарыстаў кліент, адсутнічае ў сертыфікаце. Перазапіс з IP SAN выпраўляе адно гэтае злучэнне і робіць наступны перанос горшым. Захаванне імені хоста ў профілі і пакіданне verify-x509-name на месцы трымае праверку строгай, пакуль адрас пад ёй змяняецца.

Затым праверце, да чаго прывязаны дэман; сокет, замацаваны за старым адрасам, маўкліва правальваецца. Сервер OpenVPN, запушчаны з local 203.0.113.10, адмаўляецца ўздымацца, як толькі гэты адрас знікае, а слухач на 0.0.0.0 бясплатна ідзе за зменай. NAT дзеліцца гэтак жа: MASQUERADE ідзе за любым адрасам, які цяпер мае машына, а статычны SNAT --to-source 203.0.113.10 працягвае перапісваць на адрас, якім вы ўжо не валодаеце, таму зваротны трафік знікае. Калі новы адрас прыходзіць з іншым upstream-шлюзам, праверце rp_filter: фільтраванне зваротнага шляху адкідае зваротны трафік, што прыходзіць на інтэрфейс, якога ядро не чакала.

Парадак пераходу і доказы, што ён спрацаваў

Знізьце TTL за дзень да таго, падніміце новы слухач і дакажыце яго профілем, які ёсць толькі ў вас. Тэст знутры той жа сеткі не даказвае амаль нічога, таму выкарыстайце тэлефон у сотавай сетцы і праверце тое, што тунэль павінен пераносіць, а не ping да endpoint.

Сачыце за абодвума адрасамі праз акно. wg show all latest-handshakes на новым хосце або файл стану OpenVPN пакажа, колькі peer сапраўды перайшлі. Калі ў новага endpoint ёсць чаканыя peer, а ў старога засталіся толькі адстаючыя, вывядзіце стары слухач з эксплуатацыі, выдаліце састарэлае правіла NAT і прыбярыце адрас з файрвола правайдэра. Выдаленне старога слухача — гэта крок, які прапускаюць, і ён закрывае пралом, дзе састарэлы профіль яшчэ дасягае старую сетку.

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