«File exists» у OpenVPN на маршруце — гэта не праблема файла

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

Пачніце з таго месца, дзе з'яўляецца паведамленне. Кліент падключаецца, тунель узнікае, і затым журнал паведамляе, што каманда дадання маршруту Linux скончылася няўдачай з File exists. Нішто ў гэтым сказе не адносіцца да сертыфіката, ключа або файла канфігурацыі, хаця словы гэта мяркуюць. Ядро апісвае сваю табліцу маршрутызацыі, а прэфікс, які вы прасілі ўсталяваць, ужо мае запіс.

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

Што кліент насамрэч запытваў

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

Чытайце існуючы маршрут, а не толькі адрас

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

Чатыры ўладальнікі, якія могуць быць у прэфікса

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

Кожнаму ўладальніку патрэбна свая карэкцыя. Злучаны маршрут не ваш, каб выдаляць; яго выдаленне можа парушыць лакальны доступ, перш чым тунель стане прыдатным, і ядро верне яго назад. Маршрут, які належыць менеджэру, трэба змяняць праз гэтага менеджэра, а не ўручную ip route del, які наступнае перападключэнне адменіць.

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

block-local адказвае на іншае пытанне

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

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

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

Замкніце цыкл: выдаліце дублікат у яго крыніцы

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

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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

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