WAN IP змяніўся, а тунель абарваўся: праверкі па парадку

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

Назвіце падзею, перш чым чытаць журнал

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

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

Роўмінг і перападключэнне — розныя пратаколы

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

OpenVPN паводзіць сябе па-рознаму па змаўчанні. Сеанс UDP можа скончыцца і перападключыцца, а неабавязковыя паводзіны float дазваляюць аўтэнтыфікаванаму аднарангу працягваць з новага адраса там, дзе канфігурацыя гэта дазваляе. Тунелі на аснове TCP больш строгія, бо само злучэнне прывязана да пары адрасоў. Гэтая розніца вызначае, ці будзе аднаўленне выглядаць нябачным ці кожны раз абвяшчаць сябе ў журнале.

Ні адны з гэтых паводзін нічога не кажуць пра прыкладанні ўнутры. Адноўлены тунель не аднаўляе сеанс TCP, які аднаранг ужо лічыць мёртвым.

Стан, якім тунель не валодае

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

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

Упарадкуйце праверкі ад знешняга да ўнутранага

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

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

Вызначце чаканыя паводзіны і запішыце іх

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

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