Липсващ VPN маршрут в NetworkManager: политика на профила или скрипт?

Свързвате се, интерфейсът на тунела се появява, а един префикс, който ви трябва, просто липсва в таблицата. Следващата стъпка обикновено е търсене на скрипт, който да го добави. Това търсене ви отвежда до отговори, които поставят помощник за OpenVPN в профил, и половината от тези отговори влошават положението, вместо да го подобрят, защото липсващият маршрут има три възможни собственика и само един от тях е липсващ скрипт.

Решете кой собственик отговаря, преди да напишете каквото и да е.

Три собственика, един липсващ префикс

Префиксът може да липсва, защото никой не го е предоставил, защото профилът го е отказал или защото е бил инсталиран някъде, където не гледате. Това са различни повреди и те имат различни поправки.

Първият е най-лесен за проверка: предлагал ли е сървърът или приставката някога маршрута? Бекенд, който никога не е получил префикса, не може да го инсталира, а помощният скрипт не може да измисли достъпност, която партньорът никога не е описвал. Вторият е политика на профила, която може да потиска маршрути, които връзката иначе би поела. Третият е таблица или правило, което може да държи маршрута на място, до което подразбиращото се търсене никога не се обръща.

Четвърти собственик сте вие, по-късно: скрипт, който добавя маршрута при свързване, но не го премахва при прекъсване. Това създава префикс, който надживява тунела, сочи към мъртъв интерфейс и обърква следващия човек, който ще отстранява проблеми на машината.

Прочетете профила, преди да добавите каквото и да е

Започнете със собствените свойства на запазената връзка. Прочетете ги, без да изливате тайни, и използвайте UUID, ако името на профила е двусмислено.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type ви казва кой бекенд притежава връзката, и това е важно, защото данните на приставката са специфични за бекенда. Ключ, приет от една приставка, не е поддържана инструкция за друга, така че откъс, копиран от документацията на друг клиент, не е доказателство за нищо.

ipv4.ignore-auto-routes и ipv4.never-default отговарят на различни въпроси. Първият може да отхвърля маршрути, които връзката иначе би поела автоматично, а вторият управлява дали профилът може да стане маршрут по подразбиране. Профил, който игнорира автоматичните маршрути и не разчита на нищо друго, ще се свърже чисто и ще инсталира почти нищо.

ip -4 rule show
ip -4 route show table all

Тези две команди решават третата възможност. Търсете своя префикс във всяка таблица, не само в main, и проверете дали правило за политика изпраща съответното търсене някъде другаде. Ако префиксът присъства в друга таблица и нищо не се обръща към нея, нямате липсващ маршрут; имате търсене, което никога не го достига.

Какво не може да поправи един скрипт

Добавянето на помощен скрипт дава на vpn.data на NetworkManager програма за изпълнение. Това е реален механизъм и той е грешният за повечето от тези случаи, защото скриптът получава контрол, след като собствената политика на профила вече е решила какво да приеме.

script-security на OpenVPN е другото повтарящо се объркване. Това е настройка на OpenVPN, която определя кои скриптове може да изпълнява клиентът и какво може да поставя в средата им; ниво 3 позволява предаване на идентификационни данни през средата, което е решение за работа с тайни, а не поправка на маршрут. Поставянето ѝ в профил, чийто бекенд не е OpenVPN, или повишаването ѝ, когато никой скрипт не се нуждае от нея, добавя излагане, без да добавя маршрут.

После идва рефлексът за рестартиране. Рестартирането на услугата NetworkManager разкъсва и изгражда наново всяка управлявана връзка, включително тази, през която сте свързани, ако работите отдалечено. Това е разрушително действие, а не безвредна диагностика, и на сървър може да е разликата между сесия, която оцелява, и такава, която не.

Решението, по ред

Задайте три въпроса последователно. Предоставил ли е партньорът префикса, което ще покаже журналът на бекенда или собственият му изход за състояние? Ако да, конфигуриран ли е профилът да приема и инсталира маршрути, или ги потиска? Ако маршрутът съществува някъде, правилен ли е пътят на търсене за трафика, който тествате?

Само когато първият отговор е да, вторият е да и третият е правилен, допълнителен скрипт става защитим, и дори тогава трябва да попитате дали бекендът поддържа маршрута първоначално. Справочникът за настройки на VPN документира service-type и речника с данни, специфичен за приставката, и точно оттам трябва да започнете, преди да предполагате, че ключ съществува.

След одобрена корекция се свържете отново и тествайте дестинацията по адрес, а след това по име, после прекъснете и се свържете отново, за да потвърдите, че състоянието е повторяемо. Един собственик, една таблица и маршрут, който изчезва заедно с тунела, е резултатът, който си заслужава.