WireGuard handshake radi, ali uredska podmreža ne odgovara
WireGuard je aktivan i pinga server, ali ništa na njegovoj LAN mreži ne odgovara. Provjerite prefiks klijenta, prosljeđivanje na serveru i putanju odgovora.
Rukovanje se završava, wg show izvještava o nedavnom prenosu, a tunelska adresa servera odgovara na ping. Host na LAN mreži servera ne odgovara. Tri uslova moraju vrijediti istovremeno: klijent mora usmjeriti prefiks LAN mreže u tunel, server mora proslijediti pakete, a odgovoru treba put nazad. Kada jedno od tri nedostaje, simptom je identičan.
AllowedIPs je i lista pristupa i tabela rutiranja
Na klijentu lista AllowedIPs odlučuje i šta se smije poslati tom peeru i koje rute WireGuard instalira. Unos peera koji navodi samo tunelsku adresu servera instalira jednu rutu do hosta, pa LAN odredišta nikada ne ulaze u tunel. Dodavanje prefiksa LAN mreže prvo je što treba provjeriti, a to je i promjena koja najčešće nedostaje nakon kopirane konfiguracije. Peer proširen na zadanu rutu je drugačiji dizajn i premjestit će i internet saobraćaj klijenta.
Držite rutu do hosta i prefiks LAN mreže kao odvojene unose. Ako ured ima dvije podmreže, obje pripadaju na listu, a prefiks druge koja nedostaje stvara kvar koji izgleda selektivno, a ne potpuno.
[Peer] PublicKey = <server public key> Endpoint = vpn.example.net:51820 AllowedIPs = 10.66.0.1/32, 192.168.50.0/24
Prosljeđivanje i prevođenje pripadaju serveru
Serveru treba omogućeno IP prosljeđivanje, pravilo prosljeđivanja koje prihvata saobraćaj koji dolazi iz tunela i pravilo prevođenja prema njegovom LAN interfejsu. Prevođenje je ono što dizajn čini funkcionalnim bez diranja svakog hosta na uredskoj mreži. Odgovori se tada vraćaju na server, a ne na adresu za koju LAN nikada nije čuo. Bez toga svakom hostu treba ruta za podmrežu tunela i firewall pravilo koje je dozvoljava, što je rijetko prihvatljivo na mreži kojom upravlja neko drugi.
sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i wg0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Pravila dodana ručno nestaju pri ponovnom pokretanju, pa ih vežite za interfejs hook komandama u konfiguraciji servera. Skup pravila koji nadživi svoj interfejs je način na koji mašina završi prevodeći saobraćaj za tunel koji više ne postoji.
Kada se LAN preselio, a pravilo nije
Zamjena rutera koja prenumeriše uredsku podmrežu klasična je verzija ovog kvara. Tunel ostaje aktivan, rukovanje ostaje svježe, a ništa iza servera ne odgovara, jer pravilo prevođenja još navodi staru adresu. Instalacijske skripte često ugrađuju LAN adresu servera u POSTROUTING pravilo, a nakon prenumeracije ta adresa ne postoji ni na jednom interfejsu. Paketi se tada prepisuju na odredište koje ne može odgovoriti.
iptables -t nat -n -L POSTROUTING ip -br addr show
Uporedite dva izlaza. Cilj prevođenja koji se ne pojavljuje na listi interfejsa jeste greška, a ispravljanje je promjena u jednom redu kad je jednom vidite. Pravilo može živjeti u generiranoj jedinici, a ne u WireGuard konfiguraciji, pa ponovo učitajte tu jedinicu nakon uređivanja i potvrdite da sljedeće pokretanje neće prepisati vašu promjenu.
Dvije lokacije iza NAT-a trebaju mjesto susreta
Kada nijedna strana ne prihvata dolazne veze, praktičan odgovor je mali host s javnom adresom i dva WireGuard interfejsa. Svaka lokacija se povezuje prema van, srednji host navodi LAN svakog peera u svom AllowedIPs, a prosljeđivanje prenosi pakete između dva tunela. Ništa na firewallu nijedne lokacije ne mora se mijenjati, zato se ovaj dizajn lako širi.
Rutiranje između lokacija zadržava izvorne adrese i time zadržava smisao evidentiranja po hostu. Prevođenje na srednjem hostu jednostavnije je kada se dvije LAN mreže preklapaju, ali po cijeni gubljenja identiteta izvora u zapisima. Odlučite koja je osobina važna prije nego što izaberete.
Odvojite slojeve s četiri provjere
Radite jednu provjeru po sloju umjesto da mijenjate tri stvari i nadate se. Prva pokazuje starost rukovanja i brojače za svaki peer. Druga pokazuje usmjerava li klijent to odredište zaista u tunel. Treća i četvrta govore je li zahtjev stigao i je li ga neka politika odbacila nakon dolaska.
wg show ip route get 192.168.50.20 tcpdump -ni wg0 icmp iptables -vnL FORWARD --line-numbers
Zahtjev koji stigne i ne izazove odgovor upućuje na putanju odgovora ili na host na LAN mreži. Zahtjev koji nikada ne stigne upućuje na AllowedIPs ili na rutu klijenta. Ta dva ishoda traže različite ispravke, a snimak je ono što ih razlikuje.