Увозот во 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 плус desktop помошник; на 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 и осигурај се дека kernel страната постои со 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), при што агентот ја бара; за тоа нема посебен број на знаменце. Несовпаѓањето на знаменцата е вообичаената причина зошто профилот се поврзува од desktop аплетот, а не успева од скрипта или при подигање.

Најбрзиот начин да видиш што одфрлил парсерот е да го замолиш додатокот повторно да ја запише датотеката, па да ја споредиш: 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 (сопствениот default на 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 за да ја остави default рутата на мир, поновите изданија на 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-а, и остави точно еден од нив да ја инсталира default рутата. Две default рути со различни метрики не се split tunnel; тоа е трка што ја решава сервисот што стартува втор. И по reconnect, повторно провери ја применетата состојба — еднократна рачна измена на 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 страната, оневозможи секој втор сопственик, па по рестарт верификувај барање на име и табелата со рути. Кога една врска го поминува сето тоа, профилната датотека што ја стартувала може да се врати во заштитено складиште.