Hogyan építs két peerrel WireGuard-tesztet, amely egyetlen útvonalat bizonyít

Egy WireGuard-teszt, amely alapértelmezett útvonalat, LAN-előtagot, DNS-t és tűzfal-kivételt hordoz, nem tudja megmondani, melyikük tört el. Szűkítsd két peerre, egy cím párra és egyetlen engedélyezett szolgáltatásra, és a hiba nem tud hova bújni. Az unalmas alap a diagnózis. Ezt építsd meg először; tizenöt percet vesz igénybe, és megspórolja a délutánt, amelyet különben találgatással töltenél.

Amit az alap bizonyít, szűkebb, mint amire a legtöbb ember számít. Azt bizonyítja, hogy két identitás egyetért, hogy az UDP eléri a figyelő portot, és hogy egy engedélyezett cél egy kérést szállít. A továbbítás, a NAT, a LAN-útvonalak és a DNS külön szolgáltatások, amelyeket utána adunk hozzá, egyenként.

Kulcsok, címek és az egyetlen endpoint

Generálj kulcspárt minden rendszeren, és csak a nyilvános feleket mozgasd közöttük. wg genkey | tee privatekey | wg pubkey > publickey az dokumentált egysoros parancs, és a privát kulcsot olyan fájlban hagyja, amelyet utána védhetsz. Válassz alagútcímeket olyan tartományból, amely nem szerepel más konfigurációidban, például 10.99.0.1/24 és 10.99.0.2/24. Írd le, melyik cím melyik géphez tartozik, mert minden későbbi ellenőrzés ezen a leképezésen múlik.

A privát kulcsok soha nem utaznak. Ha egy tesztnek kell egyet a másik oldalra másolni, a teszt már elrontotta magát. Amikor a két rendszer NAT mögött ül, legalább az egyiknek elérhető UDP-portra van szüksége, miközben a másik olyan Endpointot hordoz, amely rá mutat, és a nyilvános cím és port a jegyzeteidbe tartozik, nem az 51820-ról szóló feltételezéseidbe.

Az a porttovábbítás, amely másik külső portot képez le, jól működik, amíg az Endpoint illeszkedik hozzá. Az eltérések itt csendet keltenek hibák helyett, ezért érdemes papíron ellenőrizni őket, mielőtt a vezetéken hibakeresnél.

A wg-hez tartozó mezők és azok, amelyek nem

A központi mezőkészlet kicsi: PrivateKey és ListenPort az Interface alatt, PublicKey, AllowedIPs és Endpoint a Peer alatt. Az Address és a DNS a wg-quickhez tartozik, nem magához a wg-hez, és ez a különbség abban a pillanatban harap, amikor ugyanaz a konfiguráció másik eszközbe kerül.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

Az AllowedIPs egyszerre két feladatot lát el. Kiválasztja, mely célok kerülnek az alagútba, és feljogosítja a peert, hogy ezeket a forráscímeket érkezéskor használja. Ezért a másik oldali tükörbejegyzésnek pontosan meg kell neveznie az alagútcímedet; egy /32 a rossz peerhez útválasztási problémaként olvasódik, és engedélyezési problémaként viselkedik. A WireGuard gyorsindítás ugyanazt a kétpeeres formát mutatja a kanonikus megfogalmazással, ha össze akarod hasonlítani a mezőneveket.

A kézfogás olvasása az ikon helyett

Hozd fel az interfészt azon keresztül, ami birtokolja, aztán állapotot olvass, ne státuszfényt. wg show peerenként kinyomtatja a legutóbbi kézfogást a bájtszámlálókkal együtt, és az elmúlt néhány percen belüli kézfogás azt jelenti, hogy a kulcsok, az endpoint és az UDP-útvonal mind működnek. Az a számláló, amely csak egy irányban nő, maga a válasz, és nem ugyanaz a hiba, mint a soha létre nem jövő kézfogás.

A két hiba különböző vizsgálatokat sugall. A teljes kézfogás-hiány kulcseltérésre, rossz Endpointra, blokkolt UDP-re vagy a kézfogást magát eldobó tűzfalra mutat. Az a kézfogás, amely sikerül, miközben az adatok sehova nem mennek, az AllowedIPs-re, az alagútcímen nem figyelő szolgáltatásra vagy olyan gazdatűzfalra mutat, amely a portot a LAN számára elfogadja, az alagút interfészé számára nem. Ezek a rendszer különböző felei, és az alap szétválasztja őket, mielőtt elkezdenéd módosítani a szabályokat.

Egy engedélyezett szolgáltatás bizonyítása, majd a fordított irány

Küldj kérést a másik peer alagútcímére egy olyan szolgáltatásra, amelynek válaszolnia kell, és válassz jobbat a pingnél. A hiányzó ICMP-válasz gazdaszűrés is lehet, nem alagúthiba, ezért a csendes ping egyik irányt sem bizonyítja. Egy TCP-kapcsolat egy általad nyitottnak ismert portra, vagy egy adatot visszaadó kérés olyan választ ad, amelyet értelmezni tudsz.

A fordított irányt külön tesztként futtasd, saját eredménnyel, mert a két iránynak külön tűzfal- és AllowedIPs-bejegyzései vannak, és egymástól függetlenül is elbukhatnak. Ha a kézfogás működik és a kérés nem, a probléma az adatútvonalban van, nem az alagútban: AllowedIPs, a figyelő szolgáltatás vagy egy gazdatűzfal. Javítsd ezt, mielőtt továbbítást, NAT-ot vagy DNS-t adsz hozzá, különben azzal töltöd a délutánt, hogy egy olyan szolgáltatást hibakeresel, amely soha nem volt hibás.

Az alap referenciaként tartása

Mentsd el a működő topológiát és a profil forrását olyan helyre, ahonnan vissza tudod állítani, és tartsd távol minden olyan könyvtártól, amely nyilvános szolgáltatással szinkronizál. Aztán egyszerre egy szolgáltatást adj hozzá, minden után megismételve az eredeti kérést: továbbítás, NAT, LAN-útvonal, és csak utána DNS. Minden kiegészítés, amely elrontja a tesztet, most azonosítható, mert semmi más nem mozdult.

Egy alap, amely csak zöldre vált egy ikont, semmit nem mondott arról, melyik kiegészítés okozta a következő hibát. Tartsd működésben az egyetlen engedélyezett útvonalat referenciaként, és minden későbbi változást hozzá mérünk.