WireGuard-eweknie vertrek deur die verkeerde WAN: vyf kontroles in volgorde

Twee uplinks, een poort, en 'n WireGuard-eweknie wie se verkeer aanhou opduik op die rugsteunlyn. Die handdruk bly deurgaans gesond. Daarom is die simptoom maklik om verkeerd te lees as 'n WireGuard-fout eerder as 'n routeringsfout.

Werk die kontroles hieronder in volgorde deur. Elkeen het 'n stoptoestand, en om vooruit te spring lewer gewoonlik 'n selfversekerde verkeerde antwoord.

Skei die handdruk van die deurgevoerde vloei

Die geënkripteerde eweknie-uitruiling het 'n eindpuntroete na die bediener se publieke adres. Deurgevoerde kliëntverkeer het 'n ander bestemming en kan deur merke of beleidsreëls gekies word. Dit is twee routeringsbesluite wat 'n koppelvlak deel. Om die een as bewys oor die ander te behandel, is die eerste fout.

Stop sodra jy jouself daarop betrap dat jy uit die handdruk redeneer. Dit is slegs bewys oor die eindpuntpad.

Lees die beleidsreël, nie die verstektafel nie

Die verstektafel wys wat gebeur wanneer geen beleidsreël pas nie. Op 'n poort wat volgens bron, merk of bestemming routeer, woon die beslissende reël elders. Die gewone tabel kan heeltemal redelik lyk terwyl die werklike keuse bo dit gemaak word.

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

Lees die beleidsreëls en die tabelle waarna hulle wys. Bevestig dan watter reël by jou toetsvloei pas. 'n Reël wat na 'n koppelvlak verwys wat nie meer die beoogde uplink dra nie, is 'n bevinding, nie 'n detail nie. Die roetesoektog aan die einde wys die antwoord baie vinniger as om 'n tabel te lees en te raai.

Kontroleer die merk en die vertaling saam

Beleidsroetering sleutel op 'n pakkiesmerk wat vroeër in die ketting gestel is. As die merkingsreël jou verkeer mis, val die vloei deur na die hooftabel en vertrek deur watter verstek daar ook al is. Deurgevoerde pakkies slaan dikwels kettings oor wat vir plaaslik gegenereerde verkeer geskryf is.

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

Vertaling moet ooreenstem met die uplink wat die vloei dra. 'n Reël wat na die primêre adres vertaal terwyl die pakkie deur die rugsteunlyn vertrek, lewer antwoorde geadresseer aan 'n koppelvlak wat die vloei nooit gebruik het nie. Kontroleer die vertaalreël se eie koppelvlaktoestand. 'n Onvoorwaardelike reël werk totdat die tweede uplink gebruik word, en faal dan op 'n manier wat wisselvallig lyk.

Let op watter koppelvlak die antwoord dra

Vang op beide uplinks terwyl een versoek loop. Let op watter koppelvlak die versoek dra en watter die antwoord dra. Asimmetriese paaie is baie makliker om te sien as om te voorspel.

As die antwoord op die verkeerde uplink aankom, het die probleem van WireGuard na verbindingsnasporing of vertaling verskuif. Geen verandering aan die eweknie-konfigurasie sal dit regstel nie.

Verander een ding met 'n weg terug

Hou konsol- of buitebandtoegang voordat jy beleidsreëls op 'n poort wysig. Maak een verandering, toets dieselfde gemagtigde bestemming, herverbind dan en bevestig dat die handdruk steeds die beoogde eindpuntpad gebruik. Voeg 'n numeriese toets op die tweede adresfamilie by, want 'n bloot v4-beleid laat dieselfde fout beskikbaar.

Teken aan watter uplink elke vloei gebruik het. Daardie rekord maak die volgende verslag 'n kontrole van twee minute in plaas van 'n middag. WireGuard se notas oor naamruimtes en routering beskryf hoe om die eindpuntpad doelbewus van tonnelverkeer te skei, wat gewoonlik skoner is as om 'n verstekroete-omweg te kopieer.