WireGuard-peer utilgjengeleg medan ein annan verkar: sjekkliste

Éin WireGuard-peer sender trafikk gjennom og ein andre fullfører handtrykket men når aldri noko bak tunnelen. Peeren som fungerer fortel deg at grensesnittet, UDP-porten og servernøkkelen truleg er i orden. Han seier ingenting om AllowedIPs til den andre peeren, den indre kjeldeadressa eller videresendingsreglane imellom. Gå gjennom lista i rekkjefølgje og stopp ved det første trinnet der vilkåret ikkje held.

Trinn 1: Skriv ned vegen pakken skal ta

To klientar på same hub når ikkje kvarandre automatisk. I eit hub-og-spoke-design tek serveren imot pakken på wg0 og må videresende han ut av wg0 igjen til den andre peeren, noko som krev IP-videresending og ein videresendingsregel. I eit direkte peer-til-peer-design treng kvar side endepunktet til den andre og tunneladressa til den andre inne i AllowedIPs. Bestem deg for kva design du feilsøkjer før du les nokon konfigurasjon.

Den venta vegen fortel deg òg kvar du skal sjå. Viss pakken skal krysse huben, er det feilande hoppet anten AllowedIPs til sendaren, videresendinga i huben eller AllowedIPs til mottakaren. Viss han skal gå direkte, er huben irrelevant og endepunktfelta på begge peerane er dei som tel.

Trinn 2: Samanlikn AllowedIPs på begge sider, ikkje berre éi

WireGuard brukar AllowedIPs både som rutetabell og som tilgangsliste. Ved sending blir måladdressa slått opp i AllowedIPs til peeren for å velje tunnelen; ved mottak må den indre kjeldeadressa liggje innanfor AllowedIPs til peeren som sender, elles blir pakken forkasta. Eit manglande område på ei av sidene gir same symptom: transporten verkar, lasta forsvinn.

Les den levande tilstanden i staden for fila, fordi ei omlasting kan ha feila stille: sudo wg show wg0 allowed-ips. På serveren må oppføringa til peeren som feilar innehalde tunneladressa hans, til dømes 10.90.0.3/32. På klienten må oppføringa til server-peeren innehalde målet du testar, anten det er tunneladressa til huben eller det eksterne subnettet. Overlappande område gjer oppslaget tvitydig og kan velje ein peer du ikkje meinte, så hald dei fråskilde.

Trinn 3: Sjekk den indre kjeldeadressa

Ein klient som rutar 10.90.0.3 gjennom wg0 men sender pakkar frå Wi-Fi-adressa si, blir avvist av mottakaren fordi kjelda ikkje samsvarar med AllowedIPs til peeren. Stadfest kva kjernen faktisk vel med ip route get 10.90.0.3 from 10.90.0.2, og stadfest adressa som er tildelt tunnelgrensesnittet med ip -brief addr show wg0.

På mottakarverten med Linux er reversert stisjekk ei andre port. Ein streng rp_filter på grensesnittet som eig returvegen kan forkaste tunneltrafikk der returvegen ikkje samsvarar med grensesnittet han kom inn på. Sjekk den effektive verdien før du slår han av; i mange topologiar er den rette rettinga ei rute, ikkje eit slappare filter.

Trinn 4: Gå gjennom videresendinga i huben og returvegen

Viss huben må videresende mellom peers, treng kjernen net.ipv4.ip_forward=1, og brannmuren må godta den videresende straumen: inn på wg0, ut på wg0, frå tunneladressa til sendaren til adressa til mottakaren. Ein vanleg feil er ein inngangsregel som godtek UDP 51820 men ingen videresendingsregel], slik at handtrykket lukkast og lasta døyr. List dei gjeldande reglane med sudo nft list ruleset eller tilsvarande for brannmurhandsamaren din.

Sjekk deretter svaret. Mottakarverten må ha ei rute tilbake til sendaren, anten gjennom huben eller gjennom sin eigen gateway. Viss huben òg NAT-ar tunnelsubnettet, må du stadfeste at omsetjinga gjeld for den videresende straumen og at svaret når huben før tilstanden går ut. Ein einvegsfeil som ser ut som eit nøkkelproblem er ofte berre denne returvegen.

Til slutt, skil handtrykket frå dataa. Ein peer som fullfører handtrykket men stoppar på store overføringar har vanlegvis eit MTU- eller MSS-problem på nettopp den vegen, ikkje eit AllowedIPs-problem. Test først med ein liten ping, deretter med ein i full storleik, og samanlikn dei to peerane.

Trinn 5: Endre éin ting og hald den fungerande peeren intakt

Gjer éi enkel endring på vegen som feilar og test begge peerane på nytt. Å byte ut AllowedIPs til kvar peer med 0.0.0.0/0 er den raskaste måten å øydeleggje peeren som allereie virka, fordi det endrar rutingsavgjerda for all trafikk på det grensesnittet. Rediger den eine oppføringa, last på nytt og les den levande tilstanden tilbake.

Noter kva veg som lukkast, kva veg som feila og den nøyaktige kommando-utskrifta for kvar. Den samanlikninga er verdt meir enn ein generell rapport om at VPN-en er øydelagd, og det er det første den neste personen vil spørje om.