„File exists“ в OpenVPN за маршрут не е проблем с файл

Започнете от мястото, където се появява съобщението. Клиентът се свързва, тунелът се вдига и след това журналът съобщава, че командата за добавяне на маршрут в 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 от една страна и отдалечена мрежа от друга, проблемът е припокриване на адреси, а не дубликат, и никакво изтриване няма да направи и двете значения верни едновременно. Този случай изисква различен план за една от двете мрежи. Решете коя страна ще бъде преномерирана, преди да докоснете която и да е.