Két WireGuard peer osztozik egy tartományon: melyik kapja a csomagot
Az átfedő tartományokat a legkonkrétabb előtag dönti el, nem a sorrend. Először az útvonalat ellenőrizze, aztán a peer-listát, mielőtt bármit szélesítene.
Két peer olyan tartományokat sorol fel, amelyek érintkeznek, és a forgalom a rosszhoz érkezik. Semmi sem sérült: a WireGuard úgy választ peert, hogy a célt a beállított tartományokhoz illeszti, és a legkonkrétabb egyezés nyer. Mielőtt bármit szélesítene, döntse el, melyik peer melyik előtagot birtokolja.
A leghosszabb előtag nyer a WireGuardon belül
Minden peer-bejegyzés cél-előtagok halmazát hordozza. Amikor egy csomagot az interfészbe irányítanak, a megvalósítás a legkonkrétabb egyező előtagú bejegyzést keresi — ugyanazt a szabályt alkalmazza, mint egy útválasztási tábla. Ezért a /24 legyőzi az őt tartalmazó /16-ot, és a szűkebb peer kapja a forgalmat.
A road-warrior beállítások ezt szándékosan használják. Egy peer széles tartományt birtokol egy telephelyhez, az egyes hostokat pedig más peerekhez tartozó /32 bejegyzésekkel választják ki. A minta azért működik, mert a kiválasztások konkrétabbak, nem a sorrend miatt.
Írja le a tulajdonjogot előtag és peer táblázataként. Ha két bejegyzés ugyanazt az előtagot írja le, a konfiguráció már nem szándékot fejez ki, hanem versenyt.
Az operációs rendszer először az interfészt választja ki
A WireGuard csak egy interfész peerjei közül választ. Hogy melyik interfész kapja a csomagot, korábban dől el, a host útválasztási táblája által, és egy második alapértelmezett útvonal vagy egy elavult útvonal olyan helyre küldheti a forgalmat, ahol a peer-lista soha nem látja. Ezért a peer szintű diagnózis lehet helyes, és mégsem magyarázza a hibát. Ellenőrizze a cél útvonalát, mielőtt elolvassa a peer konfigurációját, mert a fizikai interfészre mutató útvonal megkerüli az egész kérdést.
Az eszköz általában a peer-tartományokból telepíti ezeket az útvonalakat, ami azt jelenti, hogy az egyik peer listájának módosítása csendben átirányíthatja a korábban máshoz tartozó forgalmat. A peer szerkesztése tehát álcázott útvonalváltozás. Tekintse át mindkettőt egyszerre, különben az egyiket megjavítja, a másikat elrontja.
A bejövő csomagokat forrás szerint ellenőrzik
A tartománylista kettős feladatot lát el. A kimenő forgalomhoz cél szerint választ peert, a bejövő forgalomhoz pedig forrás-címet engedélyez. Az adott peer tartományain kívüli címről érkező csomagot eldobják, mielőtt bármely tűzfal látná.
Ezt az aszimmetriát könnyű figyelmen kívül hagyni, amikor a konfiguráció egyik oldalát olvassa. Egy peer, amely elér egy alhálózatot, ettől még nem jogosult arra, hogy abból az alhálózatból küldjön, és a két irányt különböző ellenőrzések kényszerítik ki.
A szűk forrás-tulajdonlás előnnyé változtatja ezt. Adjon minden peernek egy /32-t a saját címéhez, és a lejjebbi tűzfalnak megbízható forrása lesz az illesztéshez, ahelyett hogy egy csoportszintű tartományt bárki tagja igényelhetne.
Az ismétlődő tartományok nem failoverek
Ugyanazon előtag két peernek való hozzárendelése nem hoz létre terheléselosztót vagy tartalék útvonalat. Nincs állapotellenőrzés és nincs munkamenet-affinitás: a nyertes bejegyzést a megvalósítás belső sorrendje dönti el, ami nem szerződés, amelyre tervezni kellene. Ha alternatív kijáratokra van szüksége, azokat ott fejezze ki, ahol a kiválasztás definiálva van. Egy útválasztási szabályzat, egy metrika, vagy két különböző előtag, mindegyiknél dokumentált tulajdonossal, olyan viselkedést ad, amelyet előre jelezhet és tesztelhet.
Egy tartomány szélesítése egy független hiba javítására a másik gyakori hiba. Eltávolítja a forgalmat a működő peertől, és az új tünet a régi megértése előtt érkezik meg.
A szerkesztés előtt ellenőrizze a kiválasztást
Három parancs válaszolja meg a három kérdést sorrendben. Az első felsorolja azokat a tartományokat, amelyeket az egyes peerek igényelnek. A második megmutatja, melyik interfészt használná a host egy célhoz. A harmadik a peerek élő állapotát mutatja, miután a forgalom átfolyt.
wg show wg0 allowed-ips ip route get 10.66.8.20 wg show wg0 ip rule show
Futtassa őket a változás előtt és után, és hasonlítsa össze. Ha az útvonal kimenete megváltozott, de a forgalom továbbra is a rossz peerhez érkezik, az előtaglisták olyan módon fedik egymást, amelyet még nem írt le. Ha az útvonal kimenete nem változott, a peer konfigurációja soha nem az volt, amit kérdeztek.
Jegyezze fel a jegybe a célt, a kiválasztott interfészt és a kiválasztott peert. Ez a hármas teszi később átvizsgálhatóvá az átfedést, és sokkal hasznosabb, mint a konfiguráció képernyőképe.