Изабрао сам Увези из датотеке… у 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 се мапира на NetworkManager-ове resolver особине, MTU се мапира на wireguard.mtu (wg-quick-ов сопствени default је 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 показује шта је daemon урадио са овом везом у овом подизању. За други десктоп копирај keyfile и држи га у власништву root-а са модом 600, или користи nmcli connection export за OpenVPN и поново увези резултујући .ovpn — путања извоза нема WireGuard еквивалент, па је тај смер копија датотеке или свеж увоз из заштићеног оригинала.

Кратка верзија, по реду: потврди додатак или верзију NetworkManager-а, увези са апсолутне путање, читај парсирана подешавања укључујући secret заставице, упореди OpenVPN извоз са оригиналом, провери hook-ове и руте на WireGuard страни, онемогући сваког другог власника, па након поновног покретања верификуј разрешавање имена и табелу рута. Када веза прође све то, профилна датотека која ју је покренула може се вратити у заштићено складиште.

Повезани чланци