NetworkManager sau wg-quick: cine deține rutele tale WireGuard?

Modifici AllowedIPs în fișierul WireGuard, repornești tunelul, și tabelul de rutare arată exact ca înainte. Reacția obișnuită este să ștergi ruta incomodă și să mergi mai departe, ceea ce funcționează până când următoarea reconectare o pune la loc. Fișierul pe care l-ai editat nu este neapărat obiectul care a produs starea pe care o vezi. Doi manageri pot rula același protocol pe o singură mașină, și doar unul dintre ei deține interfața la un moment dat.

Mit: există o singură configurație WireGuard pe mașină

wg-quick citește un fișier în /etc/wireguard/ și construiește interfața când o ridici. NetworkManager stochează un profil de conexiune în propriul format keyfile și îl redă la activare, iar importul unui fișier wg-quick copiază valorile în acel profil în loc să facă o legătură către el. Editarea originalului după aceea nu schimbă nimic, pentru că profilul nu îl mai citește. Aceeași listă de parteneri și chei poate exista deci de două ori, cu a doua copie în vigoare.

Un semn care merită reținut: modificările care supraviețuiesc unei reporniri, dar nu unei reimportări, provin dintr-un depozit, iar modificările care dispar la repornire provin din celălalt.

Un exemplu practic face separarea evidentă. Compară nmcli connection show cu systemctl status wg-quick@wg0, apoi verifică de ce interfață depind de fapt rutele. Dacă serviciul este mort și interfața este ridicată, profilul face treaba, indiferent ce spune fișierul.

Mit: regulile de rutare fac parte din WireGuard

Dispozitivul WireGuard din nucleu cunoaște partenerii și cheile și nu știe nimic despre rutarea pe politici. Orice ip rule intrări și tabele suplimentare vezi au fost instalate de instrumentul care a ridicat interfața. wg-quick poate adăuga un fwmark și un tabel dedicat plus reguli care indică spre el, în timp ce NetworkManager instalează rute prin propriile setări ipv4 și lasă DNS-ul backendului de rezolvare pe care îl folosește sistemul. Același tunel, efecte secundare diferite.

Citește ip rule și ip route show table all înainte de a schimba ceva și notează în ce tabel locuiește fiecare rută. Un număr de tabel pe care nu l-ai configurat este un indiciu puternic despre instrumentul care l-a creat.

Mit: ștergerea rutei este o reparație

O rută ștearsă în timpul rulării este o rută pe care proprietarul o va reinstala la următoarea activare, iar activarea se poate întâmpla fără tine: trezirea unui laptop, o fluctuație a legăturii, o repornire a serviciului sau o autoconectare NetworkManager. De aceea revine aceeași rută și de aceea soluția temporară pare nesigură, nu greșită. Identifică mai întâi managerul, apoi schimbă intrarea pe care acel manager o citește de fapt.

Reconectarea și repornirea serviciului relevant este testul care separă o reparație reală de una care doar arată îngrijit.

Alege un singur proprietar și elimină-l pe celălalt

Alege managerul pe care îl susține implementarea ta, apoi dezactivează activarea concurentă prin controlul ei documentat, în loc să speri că va rămâne inactivă. Un serviciu wg-quick mascat sau un profil NetworkManager șters este explicit; a le lăsa pe amândouă activate și a le pune să concureze nu este. Păstrează accesul funcțional înainte de a dezactiva ceva, pentru că interfața care duce sesiunea ta la distanță poate fi exact cea pe care ești pe punctul de a o elimina.

După schimbare, verifică traficul inclus și exclus, apoi DNS, apoi repornește o dată. Dacă starea supraviețuiește unei reporniri cu un singur manager, ai un proprietar în loc de o coincidență.

Regula generală merită păstrată și dincolo de WireGuard: când o setare tot revine, oprește-te din ștergerea rezultatului și găsește procesul care îl produce în continuare.