OpenVPN абрываецца пасля абнаўлення арандавання DHCP: захавайце маршрут да канчатковага пункта

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

Праверце сімптом супраць паўстандартных маршрутаў

З redirect-gateway def1 OpenVPN усталёўвае 0.0.0.0/1 і 128.0.0.0/1 замест замены стандартнага маршруту. Разам гэтыя два ахопліваюць усю адрасную прастору і перамагаюць 0.0.0.0/0 ужо адной даўжынёй прэфікса. Таму любы пункт прызначэння без больш дакладнага супадзення трапляе ў тунель.

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

Пацвердзіце форму табліцы, перш чым чапаць што-небудзь яшчэ. ip route show павінен пералічыць абедзве паловы плюс маршрут да вузла для адраса сервера; калі маршруту да вузла няма, рэшта расследавання мае відавочны пачатак.

Чаму паўстандартныя маршруты перамагаюць без змены метрыкі

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

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

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

Зрабіце тры здымкі, а не адзін

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

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

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

Вырашыце, які кампанент абнаўляе выключэнне

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

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

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

Праверце жыццёвы цыкл, а не толькі перападключэнне

Прымусьце абнаўленне праз dhcpcd -n eth0 або праз вызваленне і паўторную арэнду, потым зноў праверце ip route get для канчатковага пункта. Зрабіце гэта двойчы, бо другі прагон ловіць хукі, якія дадаюць дублікаты маршрутаў. Потым перазагрузіцеся, бо ўстойлівасць — гэта іншая ўласцівасць, чым правільнасць.

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