WireGuard-peer utilgjengelig mens en annen virker: sjekkliste

Én WireGuard-peer sender trafikk gjennom og en andre fullfører håndtrykket men når aldri noe bak tunnelen. Peeren som fungerer forteller deg at grensesnittet, UDP-porten og servernøkkelen sannsynligvis er i orden. Den sier ingenting om den andre peerens AllowedIPs, dens indre kildeadresse eller videresendingsreglene imellom. Gå gjennom listen i rekkefølge og stopp ved det første trinnet der betingelsen ikke holder.

Trinn 1: Skriv ned veien pakken skal ta

To klienter på samme hub når ikke hverandre automatisk. I et hub-og-spoke-design mottar serveren pakken på wg0 og må videresende den ut av wg0 igjen til den andre peeren, noe som krever IP-videresending og en videresendingsregel. I et direkte peer-til-peer-design trenger hver side den andres endepunkt og den andres tunneladresse inne i AllowedIPs. Bestem deg for hvilket design du feilsøker før du leser noen konfigurasjon.

Den forventede veien forteller deg også hvor du skal se. Hvis pakken skal krysse huben, er det feilende hoppet enten avsenderens AllowedIPs, videresendingen i huben eller mottakerens AllowedIPs. Hvis den skal gå direkte, er huben irrelevant og endepunktfeltene på begge peerene er de som teller.

Trinn 2: Sammenlign AllowedIPs på begge sider, ikke bare én

WireGuard bruker AllowedIPs både som rutetabell og som tilgangsliste. Ved sending slås måladdressen opp i peerens AllowedIPs for å velge tunnelen; ved mottak må den indre kildeadressen ligge innenfor AllowedIPs til peeren som sender, ellers forkastes pakken. Et manglende område på en av sidene gir samme symptom: transporten virker, lasten forsvinner.

Les den levende tilstanden i stedet for filen, fordi en omlasting kan ha feilet stille: sudo wg show wg0 allowed-ips. På serveren må oppføringen til peeren som feiler inneholde tunneladressen dens, for eksempel 10.90.0.3/32. På klienten må oppføringen til server-peeren inneholde målet du tester, enten det er tunneladressen til huben eller det eksterne subnettet. Overlappende områder gjør oppslaget tvetydig og kan velge en peer du ikke mente, så hold dem atskilt.

Trinn 3: Sjekk den indre kildeadressen

En klient som ruter 10.90.0.3 gjennom wg0 men sender pakker fra Wi-Fi-adressen sin, vil bli avvist av mottakeren fordi kilden ikke samsvarer med peerens AllowedIPs. Bekreft hva kjernen faktisk velger med ip route get 10.90.0.3 from 10.90.0.2, og bekreft adressen som er tildelt tunnelgrensesnittet med ip -brief addr show wg0.

På mottakervertens Linux er reversert stisjekk en andre port. En streng rp_filter på grensesnittet som eier returveien kan forkaste tunneltrafikk der returveien ikke samsvarer med grensesnittet den kom inn på. Sjekk den effektive verdien før du slår den av; i mange topologier er den riktige rettelsen en rute, ikke et slappere filter.

Trinn 4: Gå gjennom videresendingen i huben og returveien

Hvis huben må videresende mellom peers, trenger kjernen net.ipv4.ip_forward=1, og brannmuren må godta den videresendte strømmen: inn på wg0, ut på wg0, fra avsenderens tunneladresse til mottakerens. En vanlig feil er en inngangsregel som godtar UDP 51820 men ingen videresendingsregel], slik at håndtrykket lykkes og lasten dør. List de gjeldende reglene med sudo nft list ruleset eller tilsvarende for din brannmurbehandler.

Sjekk deretter svaret. Destinasjonsverten må ha en rute tilbake til avsenderen, enten gjennom huben eller gjennom sin egen gateway. Hvis huben også NAT-er tunnelsubnettet, må du bekrefte at oversettelsen gjelder for den videresendte strømmen og at svaret når huben før tilstanden utløper. En enveis feil som ser ut som et nøkkelproblem er ofte bare denne returveien.

Til slutt, skill håndtrykket fra dataene. En peer som fullfører håndtrykket men stopper på store overføringer har vanligvis et MTU- eller MSS-problem på nettopp den veien, ikke et AllowedIPs-problem. Test først med en liten ping, deretter med en i full størrelse, og sammenlign de to peerene.

Trinn 5: Endre én ting og hold den fungerende peeren intakt

Gjør én enkelt endring på veien som feiler og test begge peerene på nytt. Å erstatte hver peers AllowedIPs med 0.0.0.0/0 er den raskeste måten å ødelegge peeren som allerede virket, fordi det endrer rutingsbeslutningen for all trafikk på det grensesnittet. Rediger den ene oppføringen, last på nytt og les den levende tilstanden tilbake.

Noter hvilken vei som lyktes, hvilken som feilet og den nøyaktige kommando utskriften for hver. Den sammenligningen er verdt mer enn en generell rapport om at VPN-en er ødelagt, og det er det første den neste personen vil spørre om.