Eén app door WireGuard: binden is geen routering

De instelling ziet eruit als een schakelaar per toepassing, dus mensen binden de client aan de WireGuard-interface en verwachten dat alleen die client de tunnel gebruikt. Wat de binding werkelijk doet, is een bronadres kiezen. De kernel zoekt dan een route voor de bestemming, vindt de gewone standaardroute en stuurt het pakket de fysieke link uit met het tunneladres eraan vast. Alleen een route die voor dat bronadres is gekozen, voltooit de bedoeling.

Het mechanisme heeft twee helften: een routingtabel die alleen het verkeer van de tunnel zou moeten gebruiken, en een regel die de bijpassende bron daarheen stuurt.

Binden stelt een bronadres in, meer niet

Linux kiest een uitgaande interface door de bestemming in een routingtabel op te zoeken, nadat beleidsregels de kans hebben gehad die opzoeking om te leiden. Regels kunnen selecteren op het bronadres, een firewallmarkering, de inkomende interface, een UID of zelfs een poort; elk is een andere manier om dit verkeer in plaats van alles te zeggen. De configuratie van de VPN-client kiest de tabel met de tunnelroutes; de regel kiest welk verkeer die mag raadplegen. Alleen binden levert geen van beide.

Daarom ziet de fout er zo vreemd uit. De toepassing gebruikt beslist het tunneladres, de tunnel staat beslist omhoog, en het verkeer verlaat beslist de verkeerde interface. Elke uitspraak is waar, en samen beschrijven ze een systeem waarin niets het adres met de route verbond.

Geef de tunnel zijn eigen tabel

wg-quick installeert routes waar het profiel het zegt. Door Table = 40 onder [Interface] toe te voegen, verhuizen ze naar tabel 40 in plaats van de hoofdtabel. Breng de interface omhoog en bevestig dat ze zijn aangekomen: ip -4 route ls table 40 zou de routes van de tunnel moeten tonen, en ip -4 route get 10.66.127.142 laat zien hoe de kernel er nu een daarvan oplost. Met de routes in hun eigen tabel blijft de hoofdtabel voor al het andere werken.

Doe hetzelfde voor IPv6 in plaats van een breed prefix te matchen. ip -6 rule add from fd00::2/128 lookup 40 pint één adres vast; fc00::/8 kan botsen met andere interfaces op de host en een regel opleveren die meer matcht dan bedoeld.

Voeg de bronregel toe en kijk naar de tellers

Verbind dan de helften: ip -4 rule add from 10.66.127.142/32 lookup 40, met datzelfde adres aan de WireGuard-interface gekoppeld. Zet beide regels in PostUp zodat een herverbinding ze herstelt. Controleer met een echt verzoek in plaats van met een instelling: ip route get 1.1.1.1 from 10.66.127.142 zou het tunnelapparaat moeten noemen, en curl --interface wg0 ifconfig.me zou het adres van de tunnel moeten melden in plaats van dat van thuis.

Als het nog steeds mislukt, lees ip -s rule. Een regel die bestaat maar nooit heeft gematcht, toont tellers van nul, en dat onderscheidt een verkeerde regel van helemaal geen regel. Dat ene commando bespaart veel giswerk over de vraag of de toepassing haar interface-instelling heeft genegeerd.

Het omgekeerde geval: houd SSH buiten de tunnel

Het tegenovergestelde probleem komt net zo vaak voor: wg-quick bezit de standaardroute en de SSH-sessie naar de server sterft midden in de sessie. De regels ervan staan op een laag prioriteitsnummer, dus een uitzondering moet eerder worden geëvalueerd dan zij. ip rule add dport 22 ipproto tcp table main priority 123 doet dat op een recente iproute2; waar de selector niet beschikbaar is, markeer de flow in nftables en match in plaats daarvan de markering.

Controleer ook het antwoordpad. Een SSH-sessie die tot stand komt en daarna stil wordt, heeft meestal asymmetrische routering, waarbij de ene richting via de tunnel naar buiten gaat en de andere via de fysieke interface. ip route get voor het serveradres vertelt je welke kant het antwoord op zou gaan.

Noteer het tabelnummer, de bronregel en de uitzondering in het profiel zelf. Alle drie horen bij één ontwerp en worden samen bewerkt.