Een app deur WireGuard: binding is nie roetebepaling nie

Die instelling lyk soos 'n skakelaar per toepassing, so mense bind die kliënt aan die WireGuard-koppelvlak en verwag dat net daardie kliënt die tonnel sal gebruik. Wat die binding werklik doen, is om 'n bronadres te kies. Die kernel soek dan 'n roete vir die bestemming, vind die gewone verstekroete en stuur die pakkie oor die fisiese skakel met die tonneladres daaraan geheg. Net 'n roete wat vir daardie bronadres gekies is, voltooi die bedoeling.

Die meganisme het twee helftes: 'n roetertabel wat net die tonnel se verkeer moet gebruik, en 'n reël wat die ooreenstemmende bron daarheen stuur.

Binding stel 'n bronadres, niks meer nie

Linux kies 'n uitgangskoppelvlak deur die bestemming in 'n roetertabel op te soek, nadat beleidsreëls die kans gehad het om daardie opsoek te herlei. Reëls kan op die bronadres, 'n vuurmuurmerk, die inkomende koppelvlak, 'n UID of selfs 'n poort kies; elkeen is 'n ander manier om te sê hierdie verkeer eerder as alles. Die VPN-kliënt se konfigurasie kies die tabel wat die tonnelroetes bevat; die reël kies watter verkeer dit mag raadpleeg. Binding alleen lewer nie een van die twee nie.

Dit is waarom die mislukking so vreemd lyk. Die toepassing gebruik beslis die tonneladres, die tonnel is beslis op, en die verkeer verlaat beslis die verkeerde koppelvlak. Elke stelling is waar, en saam beskryf hulle 'n stelsel waar niks die adres met die roete verbind het nie.

Gee die tonnel sy eie tabel

wg-quick installeer roetes waar die profiel dit ook al sê. Om Table = 40 onder [Interface] by te voeg, skuif hulle na tabel 40 in plaas van die hoofdtabel. Bring die koppelvlak op en bevestig dat hulle daar aangekom het: ip -4 route ls table 40 behoort die tonnel se roetes te wys, en ip -4 route get 10.66.127.142 wys hoe die kernel tans een daarvan oplos. Met die roetes in hul eie tabel, bly die hoofdtabel vir alles anders werk.

Doen dieselfde vir IPv6 eerder as om 'n breë voorvoegsel te pas. ip -6 rule add from fd00::2/128 lookup 40 pen een adres vas; fc00::/8 kan met ander koppelvlakke op die gasheer bots en 'n reël lewer wat meer pas as wat bedoel is.

Voeg die bronreël by en kyk na die tellers

Verbind dan die helftes: ip -4 rule add from 10.66.127.142/32 lookup 40, met daardie selfde adres aan die WireGuard-koppelvlak geheg. Sit albei reëls in PostUp sodat 'n herverbinding hulle herstel. Verifieer met 'n werklike versoek eerder as met 'n instelling: ip route get 1.1.1.1 from 10.66.127.142 behoort die tonneltoestel te noem, en curl --interface wg0 ifconfig.me behoort die tonnel se adres te rapporteer eerder as die tuisadres.

Wanneer dit steeds misluk, lees ip -s rule. 'n Reël wat bestaan maar nooit gepas het nie, wys 'n telling van nul, wat 'n verkeerde reël van geen reël onderskei. Daardie een opdrag spaar baie raaiwerk oor of die toepassing sy koppelvlakinstelling geïgnoreer het.

Die omgekeerde geval: hou SSH uit die tonnel

Die teenoorgestelde probleem is net so gewoon: wg-quick besit die verstekroete en die SSH-sessie na die bediener sterf middelsessie. Sy reëls sit by 'n lae prioriteitsnommer, so 'n uitsondering moet vroeër as hulle geëvalueer word. ip rule add dport 22 ipproto tcp table main priority 123 doen dit op 'n onlangse iproute2; waar die kieser nie beskikbaar is nie, merk die vloei in nftables en pas die merk eerder toe.

Kyk ook na die antwoordpad. 'n SSH-sessie wat tot stand kom en dan stil word, het gewoonlik asimmetriese roetebepaling, met een rigting wat deur die tonnel verlaat en die ander deur die fisiese koppelvlak. ip route get vir die bedieneradres sê watter kant toe die antwoord sou gaan.

Teken die tabelnommer, die bronreël en die uitsondering in die profiel self aan. Al drie behoort aan een ontwerp en sal saam geredigeer word.