WireGuard test koji nosi zadanu rutu, LAN prefiks, DNS i izuzetak u firewallu ne može vam reći koja je od tih stvari pukla. Svedite ga na dva peera, jedan par adresa i jednu dozvoljenu uslugu i kvar nema gdje se sakriti. Dosadna osnova je dijagnostika. Izgradite je prvo; traje petnaest minuta i štedi poslijepodne koje biste inače potrošili na nagađanje.

Ono što osnova dokazuje uže je nego što većina ljudi očekuje. Dokazuje da se dva identiteta slažu, da UDP stiže do porta na kojem se sluša i da jedna dozvoljena destinacija nosi zahtjev. Forwarding, NAT, LAN rute i DNS su odvojene funkcije koje se dodaju kasnije, jedna po jedna.

Ključevi, adrese i jedan endpoint

Generirajte par ključeva na svakom sistemu i prenesite između njih samo javne polovine. wg genkey | tee privatekey | wg pubkey > publickey je dokumentovana jednolinijska komanda i ostavlja privatni ključ u datoteci koju zatim možete zaštititi. Odaberite adrese tunela iz raspona koji se ne pojavljuje ni u jednoj drugoj vašoj konfiguraciji, kao što su 10.99.0.1/24 i 10.99.0.2/24. Zapišite koja adresa pripada kojem računaru, jer svaka kasnija provjera zavisi od tog mapiranja.

Privatni ključevi nikada ne putuju. Ako testu treba jedan kopiran na drugu stranu, test je već pošao po zlu. Kada su dva sistema iza NAT-a, bar jednom treba dostupan UDP port dok drugi nosi Endpoint koji pokazuje na njega, a javna adresa i port pripadaju vašim bilješkama, a ne pretpostavkama o 51820.

Prosljeđivanje porta koje mapira drugi vanjski port radi dobro dok god mu Endpoint odgovara. Nepodudarnosti ovdje proizvode tišinu, a ne greške, zato ih vrijedi provjeriti na papiru prije otklanjanja grešaka na žici.

Polja koja pripadaju wg i ona koja ne

Osnovni skup polja je mali: PrivateKey i ListenPort pod Interface, PublicKey, AllowedIPs i Endpoint pod Peer. Address i DNS pripadaju wg-quick, a ne samom wg, i ta razlika ugrize onog trenutka kada ista konfiguracija pređe u drugi alat.

[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

AllowedIPs nosi dva posla odjednom. Odabire koje destinacije idu u tunel i ovlašćuje peera da te izvorne adrese koristi po dolasku. Zbog toga ogledni unos na drugoj strani mora tačno navesti adresu vašeg tunela; /32 za pogrešnog peera čita se kao problem rutiranja i ponaša se kao problem autorizacije. WireGuard brzi početak pokazuje isti oblik s dva peera s kanonskom formulacijom ako želite uporediti nazive polja.

Čitanje handshakea umjesto ikone

Podignite interfejs kroz ono što ga posjeduje, a zatim čitajte stanje, a ne statusno svjetlo. wg show ispisuje najnoviji handshake po peeru zajedno s brojačima bajtova, a handshake u posljednjih nekoliko minuta znači da ključevi, endpoint i UDP put svi rade. Brojač koji raste samo u jednom smjeru sam je sebi odgovor i nije ista greška kao handshake koji se nikada ne dogodi.

Dvije greške impliciraju različite istrage. Potpuno odsustvo handshakea ukazuje na nepodudarnost ključeva, pogrešan Endpoint, blokiran UDP ili firewall koji odbacuje sam handshake. Handshake koji uspije dok podaci ne idu nikuda ukazuje na AllowedIPs, uslugu koja ne sluša na adresi tunela ili firewall hosta koji prima port za LAN, ali ne za interfejs tunela. To su različite polovine sistema, a osnova ih razdvaja prije nego što počnete mijenjati pravila.

Dokazivanje jedne dozvoljene usluge, zatim obrnuto

Upućivanje zahtjeva na adresu tunela drugog peera na usluzi koja treba da odgovori, i odaberite nešto bolje od pinga. ICMP odgovor koji izostane može biti filtriranje hosta, a ne kvar tunela, pa tihi ping ne dokazuje ni jedan smjer. TCP veza na port za koji znate da je otvoren, ili zahtjev koji vraća podatke, daje vam odgovor koji možete protumačiti.

Pokrenite obrnuti smjer kao odvojen test s vlastitim rezultatom, jer dva smjera imaju odvojene unose firewalla i AllowedIPs i mogu nezavisno pasti. Ako handshake radi, a zahtjev ne, problem je u putu podataka, a ne u tunelu: AllowedIPs, usluga koja sluša ili firewall hosta. Popravite to prije dodavanja forwardinga, NAT-a ili DNS-a, inače ćete provesti poslijepodne otklanjajući greške u funkciji koja nikada nije bila kriva.

Očuvanje osnove kao referentne točke

Sačuvajte radnu topologiju i izvor profila na mjestu s kojeg možete obnoviti i držite ih izvan svakog direktorija koji se sinhronizuje s javnom uslugom. Zatim dodajte jednu funkciju po jednu, ponavljajući izvorni zahtjev nakon svake: forwarding, NAT, LAN ruta i tek onda DNS. Svaki dodatak koji pokvari test sada je prepoznatljiv, jer se ništa drugo nije pomaklo.

Osnova koja samo oboji ikonu zelenom nije vam rekla ništa o tome koji je dodatak izazvao sljedeći kvar. Držite jedinu dozvoljenu putanju radnom kao referencu i svaka kasnija promjena mjeri se prema njoj.

Povezani članci