NetworkManager vagy wg-quick: ki birtokolja a WireGuard-útvonalaidat?

Módosítod az AllowedIPs értéket a WireGuard-fájlban, újraindítod az alagutat, és az útválasztási tábla pontosan úgy néz ki, mint korábban. A szokásos reakció a zavaró útvonal törlése és továbblépés, ami addig működik, amíg a következő újracsatlakozás vissza nem teszi. A szerkesztett fájl nem feltétlenül az az objektum, amely a látott állapotot létrehozta. Két kezelő futtathatja ugyanazt a protokollt egy gépen, és egyszerre csak az egyikük birtokolja az interfészt.

Mítosz: egyetlen WireGuard-konfiguráció van a gépen

A wg-quick egy fájlt olvas itt: /etc/wireguard/ és felépíti az interfészt, amikor felhozod. A NetworkManager a saját keyfile-formátumában tárolja a kapcsolati profilt, és aktiváláskor jeleníti meg, valamint a wg-quick-fájl importálása átmásolja az értékeket ebbe a profilba, ahelyett hogy rá hivatkozna. Az eredeti utólagos szerkesztése semmit sem változtat, mert a profil már nem olvassa. Ugyanaz a peers- és kulcslista tehát kétszer is létezhet, a második példány érvényben.

Egy emlékezetre érdemes jel: az újraindítást túlélő, de újraimportálást nem túlélő módosítások egyik tárhelyről, az újraindításkor eltűnő módosítások a másikról származnak.

Egy gyakorlati példa nyilvánvalóvá teszi a szétválasztást. Hasonlítsd össze nmcli connection show ezzel: systemctl status wg-quick@wg0, majd ellenőrizd, melyik interfészen lógnak valójában az útvonalak. Ha a szolgáltatás halott, az interfész pedig fent van, a profil végzi a munkát, bármit is mond a fájl.

Mítosz: az útválasztási szabályok a WireGuard részei

A kernel WireGuard-eszköze ismeri a partnereket és kulcsokat, és semmit sem tud a házirend-alapú útválasztásról. Bármilyen ip rule bejegyzést és további táblát látsz, azokat az az eszköz telepítette, amely felhozta az interfészt. A wg-quick hozzáadhat egy fwmarkot és egy dedikált táblát, valamint az arra mutató szabályokat, míg a NetworkManager a saját ipv4-beállításain keresztül telepít útvonalakat, és a DNS-t arra a feloldó háttérprogramra bízza, amelyet a rendszer használ. Ugyanaz az alagút, más mellékhatások.

Olvasd el a ip rule és a ip route show table all parancsot, mielőtt bármit módosítasz, és jegyezd fel, melyik táblában él az egyes útvonalak. Az általad nem konfigurált táblaszám erős utalás a létrehozó eszközre.

Mítosz: az útvonal törlése megoldás

A futásidőben törölt útvonalat a tulajdonos a következő aktiváláskor újra telepíti, és az aktiválás nélküled is megtörténhet: laptop ébredése, kapcsolat megingása, szolgáltatás újraindítása vagy a NetworkManager automatikus csatlakozása. Ezért tér vissza ugyanaz az útvonal, és ezért tűnik megbízhatatlannak, nem pedig hibásnak a kerülőmegoldás. Először azonosítsd a kezelőt, aztán módosítsd azt a bemenetet, amelyet az a kezelő valóban olvas.

Az újracsatlakozás és az érintett szolgáltatás újraindítása az a próba, amely elválasztja az igazi javítást a csak rendezettnek látszótól.

Válassz egy tulajdonost, és távolítsd el a másikat

Válaszd azt a kezelőt, amelyet a telepítésed támogat, majd tiltsd le a versengő aktiválást a dokumentált vezérlőjével, ahelyett hogy abban bíznál, hogy tétlen marad. A maszkolt wg-quick-szolgáltatás vagy a törölt NetworkManager-profil egyértelmű; a kettőt engedélyezve hagyni és versenyeztetni nem az. Őrizd meg a működő hozzáférést, mielőtt bármit letiltasz, mert előfordulhat, hogy a távoli munkamenetedet vivő interfész az, amelyet éppen eltávolítani készülsz.

A módosítás után ellenőrizd a bevont és kizárt forgalmat, majd a DNS-t, majd indítsd újra egyszer. Ha az állapot egyetlen kezelővel túléli az újraindítást, tulajdonosod van a véletlen helyett.

Az általános szabály a WireGuardon túl is megjegyzendő: ha egy beállítás újra meg újra visszatér, ne az eredményt törölgesd, hanem keresd meg a folyamatot, amely folyamatosan előállítja.