WireGuard-peer verlaat via de verkeerde WAN: vijf controles in volgorde

Twee uplinks, één gateway en een WireGuard-peer waarvan het verkeer steeds op de back-uplijn opduikt. De handshake blijft de hele tijd gezond. Daarom is het symptoom makkelijk verkeerd te lezen als een WireGuard-storing in plaats van een routeringsfout.

Voer de onderstaande controles in volgorde uit. Elk heeft een stopvoorwaarde, en vooruit springen levert meestal een zelfverzekerd verkeerd antwoord op.

Scheid de handshake van de doorgestuurde stroom

De versleutelde peer-uitwisseling heeft een eindpuntroute naar het openbare adres van de server. Doorgestuurd clientverkeer heeft een andere bestemming en kan door markeringen of policyregels worden gekozen. Het zijn twee routeringsbeslissingen die één interface delen. De ene als bewijs over de andere behandelen is de eerste fout.

Stop zodra je jezelf erop betrapt vanuit de handshake te redeneren. Die is alleen bewijs over het eindpuntpad.

Lees de policyregel, niet de standaardtabel

Een standaardtabel laat zien wat er gebeurt als geen enkele policyregel past. Op een gateway die routeert op bron, markering of bestemming, woont de beslissende regel elders. De gewone tabel kan er volkomen redelijk uitzien terwijl de echte keuze erboven wordt gemaakt.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Lees de policyregels en de tabellen waarnaar ze verwijzen. Bevestig daarna welke regel bij je teststroom past. Een regel die verwijst naar een interface die de bedoelde uplink niet meer draagt, is een bevinding, geen detail. De routeopzoeking aan het einde toont het antwoord veel sneller dan een tabel lezen en gissen.

Controleer de markering en de vertaling samen

Policyrouting leunt op een pakketmarkering die eerder in de keten is gezet. Als de markeringsregel je verkeer mist, valt de stroom door naar de hoofdtabel en verlaat die via wat daar standaard is. Doorgestuurde pakketten slaan vaak ketens over die voor lokaal gegenereerd verkeer zijn geschreven.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

De vertaling moet overeenkomen met de uplink die de stroom draagt. Een regel die naar het primaire adres vertaalt terwijl het pakket via de back-uplijn vertrekt, levert antwoorden die geadresseerd zijn aan een interface die de stroom nooit gebruikte. Controleer de eigen interfacevoorwaarde van de vertaalregel. Een onvoorwaardelijke regel werkt tot de tweede uplink wordt gebruikt, en faalt dan op een manier die periodiek lijkt.

Let op welke interface het antwoord draagt

Leg vast op beide uplinks terwijl één verzoek loopt. Noteer welke interface het verzoek en welke het antwoord draagt. Asymmetrische paden zijn veel makkelijker te zien dan te voorspellen.

Als het antwoord via de verkeerde uplink binnenkomt, is het probleem van WireGuard naar verbindingstracking of vertaling verschoven. Geen enkele wijziging aan de peer-configuratie lost dat op.

Verander één ding met een weg terug

Houd console- of out-of-band-toegang achter de hand voordat je policyregels op een gateway aanpast. Doe één wijziging, test dezelfde geautoriseerde bestemming, verbind daarna opnieuw en bevestig dat de handshake nog steeds het bedoelde eindpuntpad gebruikt. Voeg een numerieke test toe op de tweede adresfamilie, want een beleid dat alleen voor v4 geldt laat dezelfde fout beschikbaar.

Noteer welke uplink elke stroom gebruikte. Dat overzicht maakt het volgende rapport een controle van twee minuten in plaats van een hele middag. WireGuards notities over namespaces en routering beschrijven hoe je het eindpuntpad bewust van getunneld verkeer scheidt, wat meestal schoner is dan een omweg met standaardroute kopiëren.