WireGuard-peer utilgængelig, mens en anden virker: tjekliste

Én WireGuard-peer sender trafik igennem, og en anden gennemfører håndtrykket men når aldrig noget bag tunnelen. Den peer, der virker, fortæller dig, at grænsefladen, UDP-porten og serverens nøgle sandsynligvis er i orden. Den fortæller dig intet om den anden peers AllowedIPs, dens indre kildeadresse eller videresendelsesreglerne imellem. Gå listen igennem i rækkefølge, og stop ved det første trin, hvis betingelse ikke holder.

Trin 1: Skriv den vej ned, pakken bør tage

To klienter på samme hub når ikke automatisk hinanden. I et hub-og-spoke-design modtager serveren pakken på wg0 og skal videresende den ud af wg0 igen til den anden peer, hvilket kræver IP-videresendelse og en videresendelsesregel. I et direkte peer-til-peer-design skal hver side have den andens endpoint og den andens tunneladresse inde i AllowedIPs. Beslut, hvilket design du fejlfinder, før du læser nogen konfiguration.

Den forventede vej fortæller dig også, hvor du skal kigge. Hvis pakken skal krydse hubben, er det fejlende hop enten afsenderens AllowedIPs, hubbens videresendelse eller modtagerens AllowedIPs. Hvis den skal gå direkte, er hubben irrelevant, og endpoint-felterne på begge peers er det, der betyder noget.

Trin 2: Sammenlign AllowedIPs på begge sider, ikke kun på én

WireGuard bruger AllowedIPs både som routingtabel og som adgangsliste. Ved afsendelse slås destinationsadressen op i peerens AllowedIPs for at vælge tunnelen; ved modtagelse skal den indre kildeadresse ligge inden for den sendende peers AllowedIPs, ellers kasseres pakken. Et manglende interval på en af siderne giver det samme symptom: transporten virker, lasten forsvinder.

Læs den levende tilstand i stedet for filen, fordi en genindlæsning kan være fejlet lydløst: sudo wg show wg0 allowed-ips. På serveren skal den fejlende peers post indeholde dens tunneladresse, for eksempel 10.90.0.3/32. På klienten skal serverpeeriens post indeholde den destination, du tester, uanset om det er hubbens tunneladresse eller det fjerne subnet. Overlappende intervaller gør opslaget tvetydigt og kan vælge en peer, du ikke havde tænkt på, så hold dem adskilt.

Trin 3: Kontrollér den indre kildeadresse

En klient, der router 10.90.0.3 gennem wg0, men sender pakker fra sin Wi-Fi-adresse, vil blive afvist af modtageren, fordi kilden ikke matcher peerens AllowedIPs. Bekræft, hvad kernen faktisk vælger, med ip route get 10.90.0.3 from 10.90.0.2, og bekræft den adresse, der er tildelt tunnelgrænsefladen, med ip -brief addr show wg0.

På den modtagende Linux-vært er reverse-path-filtrering en anden port. En streng rp_filter på den grænseflade, der ejer returruten, kan kassere tunneltrafik, hvis returvej ikke matcher den grænseflade, den ankom på. Kontrollér den effektive værdi, før du deaktiverer den; i mange topologier er den rigtige løsning en rute, ikke et lempet filter.

Trin 4: Gennemgå hubbens videresendelse og returvejen

Hvis hubben skal videresende mellem peers, har kernen brug for net.ipv4.ip_forward=1, og firewallen skal acceptere den videresendte strøm: ind på wg0, ud på wg0, fra afsenderens tunneladresse til modtagerens. En hyppig fejl er en indgangsregel, der accepterer UDP 51820, men ingen videresendelsesregel], så håndtrykket lykkes, og lasten dør. List de gældende regler med sudo nft list ruleset eller det tilsvarende for din firewall-manager.

Kontrollér derefter svaret. Destinationsværten skal have en rute tilbage til afsenderen, enten gennem hubben eller gennem sin egen gateway. Hvis hubben også NAT’er tunnelsubnettet, skal du bekræfte, at oversættelsen gælder for den videresendte strøm, og at svaret når hubben, før tilstanden udløber. En ensrettet fejl, der ligner et nøgleproblem, er ofte blot denne returrute.

Adskil til sidst håndtryk fra data. En peer, der gennemfører et håndtryk, men går i stå ved store overførsler, har normalt et MTU- eller MSS-problem på netop den vej, ikke et AllowedIPs-problem. Test først med en lille ping, derefter med en i fuld størrelse, og sammenlign de to peers.

Trin 5: Ændr én ting og hold den fungerende peer intakt

Foretag én enkelt ændring på den fejlende vej, og test begge peers igen. At erstatte hver peers AllowedIPs med 0.0.0.0/0 er den hurtigste måde at ødelægge den peer, der allerede virkede, fordi det ændrer routingbeslutningen for al trafik på den grænseflade. Rediger den ene post, genindlæs, og læs den levende tilstand tilbage.

Notér, hvilken vej der lykkedes, hvilken der fejlede, og den præcise kommandoudskrift for hver. Den sammenligning er mere værd end en generel rapport om, at VPN’en er i stykker, og det er det første, den næste person vil spørge om.