WireGuard AllowedIPs: az útvonal, amelyet a NetworkManager soha nem adott hozzá

A kézfogás-számláló frissül, az interfész megtartja a címét, és a túloldalra küldött ping sehová nem érkezik meg. Ez a kombináció összezavarja az embereket, mert a működő kézfogás bizonyítéknak tűnik arra, hogy az alagút kész. Pedig nem az: egy alagút lehet teljesen egyeztetett, és mégsem vezet bele semmilyen útvonal, ami forgalmat irányítana rá, és ez két külön feladat, amelyet két külön állapotrész lát el. A javítás teljesen attól függ, melyik hiányzik a kettő közül, ezért az első lépés ennek kiderítése.

A wg-quick mindkettőt elvégzi, anélkül hogy kérnék. A NetworkManager beépített WireGuard-támogatása alapértelmezés szerint peer-útvonalakat is telepít, ami a gyanúsítottakat egy letiltott beállításra, egy másik útválasztási táblára vagy valami máson keresztül importált konfigurációra szűkíti.

Erősítse meg az alagutat, mielőtt az útvonal után ered

A wg show kiírja az interfészt, a peert, a végpontot és a legutóbbi kézfogás korát, a ip addr show pedig megerősíti, hogy a cím jelen van. A friss kézfogás azt jelenti, hogy a kulcsok, a végpont és az UDP-útvonal működnek. Minden hibás dolog ezek alatt van: útválasztás, szűrés vagy névfeloldás.

Ezután kérdezze meg a kernelt, mit tenne egy valódi célponttal egy hipotetikus helyett: ip route get 10.42.7.9. A válasz megnevezi a kimenő interfészt és azt a forrás-címet, amelyet a csomag vinne. Amikor a fizikai adaptert nevezi meg, a csomag soha nem lép be az alagútba, akármilyen egészségesnek is tűnik a kézfogás.

Az AllowedIPs szűrő és útvonallista

Az AllowedIPs előtagjai két dolgot végeznek. Kiválasztják, melyik peer viszi a kimenő célpontot, és ellenőrzik a bejövő csomagok forrás-címét, ami a titkosított kulcsos útválasztás határa. A wg-quickben emellett az útvonalak automatikus telepítését is vezérlik, és éppen ez a plusz viselkedés az oka, hogy ugyanaz a konfiguráció működik terminálból, és nem működik asztali kliensből.

A cikk mögötti esetben a profilt harmadik féltől származó bővítményen keresztül importálták, nem a beépített támogatással, és az interfész az előtag-útvonal nélkül jött fel. A tábla listázása azonnal megmutatja: az ip route show csak az interfész címének csatlakoztatott útvonalát tartalmazza, a távoli tartományra semmit.

Kérdezze meg, egyáltalán engedélyezve vannak-e a peer-útvonalak

Olvassa el a beállítást, mielőtt bármit módosít: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Amikor a peer-routes no értéket mutat, a támogatott javítás a nmcli connection modify work-wg wireguard.peer-routes yes, majd újracsatlakozás. Helyette statikus útvonalat hozzáadni a következő aktiválásig működik, aztán csendben eltűnik. Ez az eltűnés a nyom: azt az útvonalat, amely minden reggel rejtélyként visszatér, nem a profil telepíti.

Ha a beállítás már engedélyezve van, ellenőrizze a ip route show table all | grep 10 segítségével, hogy az előtag másik táblában él-e. A nem fő táblában lévő útvonal nem hiányzik, csak láthatatlan egy olyan keresés számára, amely kizárólag a fő táblát nézi. Javítsa a szabályalapú útválasztást, ahelyett hogy egy duplikált bejegyzést halmozna rá.

Az előtagot a kapcsolathoz adja, ne a futó rendszerhez

A kapcsolatszerkesztőben a WireGuard-oldal tartja a peert és az AllowedIPs listáját, az IPv4-oldal pedig további útvonalakat. Az ott hozzáadott útvonal túléli az újracsatlakozásokat, mert a profilhoz tartozik. Parancssorban ennek megfelelője, hogy üres átjárós formában útvonalat fűzünk a kapcsolathoz, majd le- és felvisszük a kapcsolatot, hogy a változás életbe lépjen.

Válassza a legszűkebb előtagot, amely lefedi a szükséges hosztokat. A szolgáltató /8 példájának másolása elnyelhet olyan helyi tartományokat, amelyek véletlenül benne vannak, és az így keletkező hibák inkább törött alagútnak, mint túl széles útvonalnak tűnnek.

Az osztott alagutazást az előtaglista dönti el

Nincs kapcsoló az osztott alagúthoz; az előtaglista a döntés. Egy peer, amelynek egy tartomány jut az irodai LAN-ra és egy a laborhálózatra, pontosan azokat a célpontokat küldi az alagúton, és minden mást békén hagy. Egyetlen hosztnak /32 kell, a két helyen átfedő tartományoknak pedig hoszt-előtagok, amíg valaki újraszámoz egy alhálózatot.

Ha úgy dönt, hogy semmit nem küld az alagúton, ugyanazt a döntést viszi a végletekig: egy minimális lista nyitva tartja a kapcsolatot, míg a szokásos forgalom a megszokott útvonalán marad. Írja le a szándékot, mert különben a következő olvasó a rövid listát mulasztásnak veszi, és segítőkészen kibővíti.

Egyetlen gazda az útválasztási táblának

A wg-quick és a NetworkManager egyaránt azt hiszi, hogy az interfész útvonalai az övéi. Importáljon egy wg-quickhez írt konfigurációt, majd indítsa el a wg-quick szolgáltatást is, és duplikált vagy ütköző bejegyzéseket kap, amelyek viselkedése attól függ, melyik futott utoljára. Válasszon egyetlen gazdát, és távolítsa el a másikat: ha a NetworkManager kezeli a kapcsolatot, kapcsolja ki az adott interfész wg-quick egységét, és soha ne adjon hozzá második profilt ugyanahhoz az eszközhöz.

Amikor a felosztásnak fizikai adaptert kell követnie célpont helyett, átlépett a szabályalapú útválasztásba, és a szabályalapú útválasztáshoz is egyetlen szerző kell. Ellenőrizze a ip route get megismétlésével, majd egy hoszt elérésével a távoli előtagon belül olyasmivel, ami kiírja a választott forrás-címet. Ha a profil bármelyiket hordozza, ellenőrizze külön az IPv6-ot és a DNS-t.