A WireGuard csak akkor működik, ha a kiszolgáló küld először: végpont-ismeret

Az alagút csak akkor látszik működni, ha a kiszolgáló először küld valamit. Indítsa az ügyfél felől, és semmi sem történik, várjon néhány másodpercet, próbálja újra, és sikerül. A szokásos diagnózis a törött NAT, és a szokásos diagnózis téves. Ami megváltozott, hogy az egyik fél megtanulta, hol lakik a másik.

Végpont-ismeret, nem elérhetőség

Egy WireGuard-fél nem kezd kézfogást, amíg nem tudja, hova küldje. A konfiguráció ezt címből és portból álló végpontként adja, és a futó állapot azt a végpontot követi, amelyben éppen hisz.

wg show a kép mindkét oldalát kiírja, és a kimenetben végpont nélküli fél semmit sem indíthat, bármennyire helyes a nyilvános kulcsa és az engedélyezett előtagjai. Hasonlítsa össze az ügyfél nézetét a kiszolgálóéval, mielőtt bármely szabályt módosítana, mert a kettő gyakran nem ért egyet abban, ki mit tud.

Hogyan tanul meg egy fél egy végpontot

A WireGuard szándékosan csendes. Amikor egy helyesen hitelesített csomag olyan címről érkezik, amelyet a fél nem várt, a megvalósítás frissíti a fél végpontját az új forrásra, és így működik a barangolás egy hálózatot váltó hordozható gépen. Ez a viselkedés magyarázza az irányfüggést: ha a kiszolgáló küld először, és a csomagja eléri az ügyfelet, az ügyfél megtanulja a kiszolgáló jelenlegi címét, és válaszolhat. Addig nincs hova küldenie. A mechanizmus hitelesített barangolás, nem az első használatkor adott bizalom rövidítése, mert a csomagnak érvényesnek kellett lennie, mielőtt a végpont elmozdult.

A wg eszközdokumentációja leírja ezt a frissítést, és érdemes egyszer elolvasni, ha köré tervez.

Az állapottartó fordítás saját irányt ad hozzá

Ahol az UDP fordító átjárón halad át, az átjáró állapotot hoz létre az első látott csomaghoz. A RFC 4787 leírja ezt a viselkedést és azokat az időkorlátokat, amelyek végül eltávolítják a leképezést. Egy tétlen leképezés lejár, és a távoli oldalról érkező bejövő csomagot az átjáró akkor eldobja, mielőtt elérné a gazdagépet. Egy egész délelőtt működő alagút pontosan ezért hagy fel a válaszolással délután.

Ez egy második és független mechanizmus, amely ugyanazt az irányfüggő tünetet okozza. Mind a végpont-ismeretnek, mind a fordítási állapotnak helyesnek kell lennie, és az egyik javítása nem javítja a másikat.

Állítsa be az irányt, amelyet valóban szeretne

Egy ügyfélnél, amelynek kapcsolatot kell kezdenie, tegye a kiszolgáló végpontját az ügyfél társ-szakaszába, és hagyja ott. Ha abban bízik, hogy a kiszolgáló küld először, akkor a forgalom sorrendjének egy véletlenjében bízik, amely csendes hálózaton megváltozik. A konfigurációnak a szándékolt irányt kell megadnia, nem felfedeznie azt.

Egy fordítás mögötti félnél, amelynek elérhetőnek kell maradnia, kapcsoljon be állandó keepalive-ot azon az oldalon. A 25 másodpercenkénti keepalive a szokásos kezdőérték, célja pedig a leképezés nyitva tartása, nem az alagút tesztelése. Válasszon egy oldalt, amely hordozza, mert mindkét oldalon bekapcsolva megduplázza a forgalmat és a naplózajt anélkül, hogy javítaná az eredményt.

Hasonlítsa össze az állapotot a kiváltó előtt és után

Rögzítse a két nézetet abban a pillanatban, amikor meghibásodik, majd újra, miután a kiszolgáló küld. Az első parancs a végpontokat és a kézfogás korát mutatja. A második azt mutatja, létezik-e fordítási bejegyzés a porthoz. A rögzítés megmutatja, melyik irány haladt át valóban a vezetéken, és az útvonal-ellenőrzés megerősíti, hogy az ügyfél nem egészen máshova küldi ezt a forgalmat.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Jegyezze fel a végpont oszlopát és a fordítási bejegyzést együtt. A végpont nélküli fél és a leképezés nélküli átjáró két különböző hiba. Csak az egyiket javítja a keepalive.