WireGuard-gazdaprefix: miért működik egy cím, a többi pedig nem

Az alagút él, a kézfogás kétpercenként megtörténik, és pontosan egy cím válaszol a túloldalon. A peer alagútcímére küldött pingek működnek; mögötte semmi. Valaki elolvassa az interfész konfigurációját, meglát egy gazdaprefixet, és arra jut, hogy a maszk rossz. A /24-re szélesítés egy ideig rendbe hozza a pinget, aztán elront valami mást. A prefix soha nem volt a hiba, és a hiányzó útvonal nem az, amit a maszk vezérel.

Mit hoz létre valójában az interfész prefix

Linuxon egy cím interfészhez rendelése kapcsolt útvonalat hoz létre ahhoz a prefixhez. Ha gazdaprefixet rendelsz hozzá, a kapcsolt útvonal egy címet fed le. Ha /24-et rendelsz hozzá, 256-ot fed le, és mindegyikük most elérhetőnek számít azon a linken.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

A gazdaprefix teljesen normális választás egy pont-pont alagúthoz, mert pontosan egy peer van a másik végén. A harmadik parancs az, amelyik megválaszolja a felhasználó kérdését: megmondja, melyik interfészt használná a kernel ahhoz a célhoz, és semmi hasznosat nem mutat, ha egyetlen útvonal sem illeszkedik.

Ez a teljes magyarázat a tünetre. Egy cím azért válaszol, mert létezik hozzá kapcsolt útvonal, vagy mert a peer engedélyezett listája véletlenül tartalmazza. Minden másnak nincs útvonala, és még azelőtt eldobják, hogy a WireGuard egyáltalán érintett lenne. Az alagút végig egészséges, ezért a kézfogásszámláló továbbra is megnyugtatónak tűnik.

Az AllowedIPs két szabály egyetlen név alatt

A WireGuard peerenkénti engedélyezett listája egyszerre két munkát végez, és a konfigurációs szintaxis egynek láttatja őket. Bejövő irányban engedélyezi, milyen forráscímeket mutathat be egy peer. Kimenő irányban kiválasztja, melyik peernek megy a csomag, a legpontosabb egyezés megkeresésével.

Egyik munka sem routing. A kernelnek továbbra is el kell döntenie, hogy a csomag az alagút interfészére tartozik, mielőtt a WireGuard ránézne, és ezt a döntést az útvonaltábla hozza. Egy széles engedélyezett listájú peer-bejegyzés önmagában nem telepít útvonalat.

Ezért tűnhet teljesnek egy konfiguráció, és viselkedhet mégis aszimmetrikusan. A kliens azért küld a túloldalra, mert létezik egy útvonal, a válaszok pedig azért nem érkeznek meg, mert a túloldal engedélyezett listája nem engedélyezi a kliens forrását, vagy mert a túloldalnak nincs visszaútja. Mindkét irány külön döntés, külön hibaformával. Leírni, melyiket teszteled, a diagnózis fele.

Honnan jön az útvonal

Ha wg-quicket használsz, az útvonalak helyetted, minden peer engedélyezett listájából generálódnak, kivéve ha beállítottad a Table = off opciót, és magad vetted át az irányítást. Ez a dokumentált viselkedés, és ez az oka, hogy egy kifejezett útvonal-direktívák nélküli konfiguráció is működik.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Hasonlítsd össze az engedélyezett listát a ténylegesen létező útvonalakkal. Ha egy peer egy egész alhálózatot engedélyez, de csak egy gazdaútvonalat hozott létre, az azt jelenti, hogy a segédprogram soha nem futott, vagy hogy te közvetlenül a wg és ip segítségével kezeled az interfészt, és akkor semmi nem generál útvonalakat neked.

Amikor kézzel kezeled, az útvonal egy sor, és az alakja kifejezett: a cél az interfészen keresztül, átjáró nélkül, mert a link pont-pont. Hozzáadni nem egy rossz prefix kerülőmegoldása; ez egy olyan terv hiányzó fele, amely szándékosan maga vállalta a routingot.

A szélesebb prefix nem adja hozzá a peer-bejegyzést

A csábító javítás az, hogy a címet /24-re változtatod, hogy a kapcsolt útvonal lefedje a szerver LAN-ját. Úgy tűnik, működik, és azért tűnik úgy, mert a kapcsolt útvonal most illeszkedik, nem azért, mert a WireGuard bármi újat tanult.

Amit szintén tettél: az egész tartományt közvetlenül elérhetőnek nyilvánítottad azon a linken, beleértve más peerekhez vagy egy valójában a szerver mögött lévő LAN-hoz tartozó címeket is. A forgalom ezekre a címekre most belép az alagútba, és hogy kijön-e a túloldalon, a szerver saját routingjától és engedélyezett listáitól függ.

A kriptográfiai oldalt ez semmilyen irányban nem érinti. A WireGuardnak továbbra is szüksége van egy engedélyezett listás bejegyzésre, amely lefedi a célt a peer kiválasztásához, a túloldalnak pedig továbbra is szüksége van egy bejegyzésre, amely lefedi a forrásodat az elfogadásához. Egy szélesebb interfészprefix egyiket sem tudja biztosítani.

Erősítsd meg mindkét irányt, mielőtt bármit változtatsz

Kezeld a két véget külön, és írd le, mit mond mindegyik. A kliensen az útvonal és a peer-bejegyzés; a szerveren a tükörkép plusz a saját visszaútja:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

A rögzítés az, ami eldönti az irányról szóló vitákat. Ha a kimenő csomagok megjelennek az alagút interfészén, és a szerver nem naplóz semmit, a távoli vég elutasítja őket, általában azért, mert a forrásod kívül esik az engedélyezett listáján. Ha egyáltalán semmi nem jelenik meg, az útvonal hiányzik, vagy máshová mutat.

Utána javítsd a szűkebb véget. Egy engedélyezett listás bejegyzés a szerver oldalán a klienscímedhez, és egy bejegyzés a kliens oldalán a cél alhálózathoz a normál forma, és békén hagyja az interfészprefixet. Csak akkor szélesítsd a prefixet, ha a címterv valóban közös alhálózatot akar azon a linken, és tedd ezt tervmódosításként, nem hibakeresési lépésként.