Импортът в NetworkManager се проваля с OpenVPN и WireGuard файлове

Избрах Импортиране от файл… в настройките на GNOME, избрах профил, който работи с клиента на доставчика, и диалогът се затвори, без да добави нищо към списъка. На втори лаптоп импортът завърши, връзката се появи под името на профила и след това се провали при първата заявка за удостоверяване. NetworkManager никога не изпълнява твоя .ovpn или wg-quick файл такъв, какъвто е. Той предава файла на анализатор, анализаторът го превръща в собствения формат за връзка на NetworkManager и оттам нататък тунелът се изгражда от този анализиран обект — тайни, маршрути, DNS и всичко останало. Затова полезният въпрос не е защо файлът е повреден, а дали анализът се е случил и какво е запазил.

Какво всъщност прави импортът с файла

За OpenVPN анализаторът живее в пакета на приставката, а връзката, която създава, сочи към D-Bus услуга като org.freedesktop.NetworkManager.openvpn. Без приставка няма анализатор: типът е непознат за nmcli, а графичният списък за добавяне на VPN може изобщо да не показва запис за импорт. WireGuard се различава по една важна точка — NetworkManager има собствени WireGuard настройки от серията 1.30, така че няма отделен пакет на приставка, но четецът на wg-quick съществува само в сборки, които го доставят.

Както и да е, файлът се чете веднъж. Резултатът се записва като keyfile в /etc/NetworkManager/system-connections/, именуван по връзката, собственост на root и нечетим за други потребители, защото съдържа ключовия материал. Този keyfile вече е връзката; по-късно редактиране на оригиналния .ovpn не променя нищо.

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

Потвърди приставката, преди да дебъгваш профила

Липсваща приставка изглежда точно като повреден профил, затова първо провери пакета. В Debian и Ubuntu поддръжката на OpenVPN идва като network-manager-openvpn плюс помощник за работния плот; във Fedora пакетите са NetworkManager-openvpn и NetworkManager-openvpn-gnome; в Arch това е networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

След това импортирай от абсолютен път: nmcli connection import type openvpn file /home/you/profile.ovpn. Относителните пътища обикновено работят, но shell, който е сменил директорията, превръща бързия импорт в обиколка. За WireGuard провери nmcli --version и се увери, че страната на ядрото съществува с modprobe wireguard; импорт, който успява на машина без модула, те оставя с връзка, чието устройство никога не се появява. nmcli референцията документира подкомандата import и приетите имена на типове. Ако type wireguard бъде отказан веднага, сборката е по-стара от функцията и правилната стъпка е пакет от дистрибуцията или backport — не копиране на конфигурацията в произволна директория и надежда нещо да я прочете.

Чети OpenVPN връзката, а не .ovpn

След като връзката съществува, чети анализираните настройки, вместо да препрочиташ файла: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Искаш remote и порта, транспорта, идентификационния материал — ca, cert, key, tls-auth или tls-crypt — и метода за удостоверяване. На профил с парола за частния ключ добави sudo nmcli --show-secrets connection show "Work VPN" и виж secret флаговете: 0 е none, така че тайната стои в keyfile; 1 е agent-owned; 2 е not-saved, което значи, че никога не се записва в keyfile; 4 е not-required, което значи, че изобщо не е нужна тайна. Това са битове, не скала, така че 3 е просто agent-owned плюс not-saved. Тайна, която те пита веднъж на сесия, е agent-owned (1), като агентът я иска; за това няма отделен номер на флаг. Несъответствието на флаговете е обичайната причина профил да се свързва от аплета на работния плот и да се проваля от скрипт или при зареждане.

Най-бързият начин да видиш какво е изхвърлил анализаторът е да помолиш приставката да запише файла обратно и после да го сравниш: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Директивите, които изчезнат в този diff, няма да съществуват при свързване. Hook-овете са обичайните заподозрени — script-security, up, down и route-up очакват скрипт, който се изпълнява с повишени права, и умишлено не се пренасят. Не понижавай проверката и не давай допълнителни права, за да успее импорт; неподдържана опция обикновено отразява набора от функции на приставката, а не недостъпен сървър. Премести това поведение в NetworkManager dispatcher скрипт или в политика от страна на сървъра.

Потвърди също, че идентификационните полета са оцелели: CA референцията, remote-cert-tls и всяка проверка на име, на която профилът е разчитал. Връзка, която се вдигне без тях, може да говори с каквото и да отговаря на този адрес.

Чети WireGuard връзката, а не wg-quick файла

wg-quick файлът е формат със shell семантика; импортираната връзка е набор от настройки. PrivateKey става частният ключ на интерфейса, Address става един или повече IPv4 и IPv6 адреса, DNS се съпоставя на resolver свойствата на NetworkManager, MTU се съпоставя на wireguard.mtu (собствената стойност по подразбиране на wg-quick е 1420), а всеки peer блок става peer запис с публичен ключ, endpoint, разрешени IP-та и persistent keepalive. Отпечатай какво е запазено с nmcli --show-secrets connection show wg0; ако списъкът с peer-ове не се появи в този изход, прочети keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Това, което не оцелява, е shell половината на wg-quick. PreUp, PostUp, PreDown, PostDown и Table са поведение на този инструмент, не атрибути на WireGuard интерфейс, така че нищо не ги изпълнява след импорт. Ако оригиналът е използвал Table = off, за да остави маршрута по подразбиране на мира, по-новите издания на NetworkManager излагат ip4-auto-default-route и ip6-auto-default-route за същата цел; задай ги изрично, вместо да предполагаш, че връзката се държи като скрипта. Hook, който е избутвал персонализиран маршрут, се нуждае от този маршрут в routing настройките на връзката, иначе просто ще липсва.

Дай на връзката точно един собственик

Класическата последваща повреда е връзка, която работи до следващото зареждане и после влиза в цикъл. Обикновено [email protected] е бил все още включен от предишен експеримент или клиент на доставчика е стартирал собствен daemon, и двама собственици са писали маршрути и DNS за една и съща дестинация. NetworkManager задава resolver по собствения си път, wg-quick пише през resolvconf и последният писател печели — така че разрешаването на имена работи, после спира, после пак работи. Провери systemctl status wg-quick@wg0, nmcli connection show --active и ip link show type wireguard, после изключи втория собственик, вместо да настройваш неговата метрика.

Ако наистина ти трябват и двете, дай им отделни интерфейси и несъвпадащи разрешени IP-та и остави точно един от тях да инсталира маршрута по подразбиране. Два маршрута по подразбиране с различни метрики не са split tunnel; това е състезание, решено от услугата, която стартира втора. И след повторно свързване прегледай отново приложеното състояние — еднократна ръчна промяна на resolver, която кара нещата да работят, не е доказателство, че импортът е пълен.

Провери с трафик и оцелей при рестарт

Вдигни връзката с nmcli connection up "Work VPN", после чети състояние, адрес и маршрути, вместо да се доверяваш на иконата: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default и истинско търсене на име, което се разрешава само вътре в тунела. Handshake или успешен ping доказва само, че криптографията работи; не казва нищо за препращането, split-tunnel префиксите или частния DNS, а това са частите, които обикновено се чупят.

След това рестартирай и повтори. Поведението на autoconnect, преименуван интерфейс и приставка, която се зарежда след устройството, са все повреди, които виждаш само при чисто зареждане. journalctl -u NetworkManager -b --no-pager | tail -n 40 показва какво е направил демонът с тази връзка при това зареждане. За втори компютър копирай keyfile и го дръж собственост на root с режим 600, или използвай nmcli connection export за OpenVPN и импортирай отново получения .ovpn — пътят за експорт няма WireGuard еквивалент, така че тази посока е копие на файл или нов импорт от защитения оригинал.

Кратка версия, по ред: потвърди приставката или версията на NetworkManager, импортирай от абсолютен път, чети анализираните настройки включително secret флаговете, сравни OpenVPN експорта с оригинала, провери hook-ове и маршрути от страната на WireGuard, изключи всеки втори собственик и после след рестарт провери търсене на име и таблицата с маршрути. Когато една връзка премине всичко това, профилният файл, който я е стартирал, може да се върне в защитено хранилище.