Üks rakendus läbi WireGuardi: sidumine ei ole marsruutimine

Säte näeb välja nagu rakendusepõhine lüliti, seega seotakse klient WireGuardi liidesega ja eeldatakse, et tunnelit kasutab ainult see klient. Sidumine valib tegelikult lähteaadressi. Seejärel otsib kernel sihtkohale tee, leiab tavalise vaiketee ja saadab paketi füüsilisest lingist välja, tunneliaadress sellele lisatud. Ainult sellele lähteaadressile valitud tee täidab kavatsuse.

Mehhanismil on kaks poolt: marsruutimistabel, mida peaks kasutama ainult tunneli liiklus, ja reegel, mis saadab sobiva lähtekoha sinna.

Sidumine määrab lähteaadressi ja ei midagi enamat

Linux valib väljuva liidese, otsides sihtkohta marsruutimistabelist pärast seda, kui poliitikareeglitel on olnud võimalus seda otsingut ümber suunata. Reeglid võivad valida lähteaadressi, tulemüürimärgi, sissetuleva liidese, UID-i või isegi pordi järgi; igaüks on teine viis öelda see liiklus, mitte kogu liiklus. VPN-kliendi konfiguratsioon valib tabeli, mis hoiab tunneli teekondi; reegel valib, millisel liiklusel on lubatud seda vaadata. Üksi sidumine ei anna kumbagi.

Seetõttu näeb tõrge nii kummaline välja. Rakendus kasutab kindlasti tunneliaadressi, tunnel on kindlasti üleval ja liiklus väljub kindlasti vale liidese kaudu. Iga väide on tõene ja koos kirjeldavad need süsteemi, kus miski ei sidunud aadressi teega.

Anna tunnelile oma tabel

wg-quick paigaldab teed sinna, kuhu profiil ütleb. Table = 40 lisamine [Interface] alla viib need põhitabeli asemel tabelisse 40. Tõsta liides üles ja kinnita, et need kohale jõudsid: ip -4 route ls table 40 peaks näitama tunneli teid ja ip -4 route get 10.66.127.142 näitab, kuidas kernel ühte neist praegu lahendab. Kui teed on omas tabelis, jätkab põhitabel kõige muu jaoks töötamist.

Tee sama IPv6 jaoks, selle asemel et sobitada laia prefiksit. ip -6 rule add from fd00::2/128 lookup 40 kinnitab ühe aadressi; fc00::/8 võib hosti teiste liidestega kokku põrgata ja anda reegli, mis sobib rohkemaga kui kavatsetud.

Lisa lähtekoha reegel ja jälgi loendureid

Seejärel ühenda pooled: ip -4 rule add from 10.66.127.142/32 lookup 40, sama aadress on WireGuardi liidese küljes. Pane mõlemad reeglid PostUp sisse, et taasühendamine need taastaks. Kontrolli päris päringuga, mitte sättega: ip route get 1.1.1.1 from 10.66.127.142 peaks nimetama tunneli seadme ja curl --interface wg0 ifconfig.me peaks teatama tunneli aadressi, mitte koduse.

Kui see ikka ei õnnestu, loe ip -s rule. Reegel, mis on olemas, aga ei ole kunagi sobinud, näitab null-loendureid ja see eristab vale reeglit reegli puudumisest. See üks käsk säästab palju oletusi selle kohta, kas rakendus eiras oma liidese sätet.

Vastupidine juhtum: hoia SSH tunnelist väljas

Vastupidine probleem on sama tavaline: wg-quick omab vaiketeed ja SSH-sessioon serverisse sureb keset sessiooni. Selle reeglid asuvad madalal prioriteedinumbril, seega tuleb erandit hinnata neist varem. ip rule add dport 22 ipproto tcp table main priority 123 teeb seda uuemas iproute2-s; kus valija pole saadaval, märgi voog nftablesis ja sobi märgiga.

Kontrolli ka vastusteekonda. SSH-sessioon, mis luuakse ja siis vaikib, on tavaliselt asümmeetrilise marsruutimisega: üks suund väljub tunnelist ja teine füüsilisest liidesest. ip route get serveri aadressi jaoks ütleb, kuhu vastus läheks.

Kirjuta tabeli number, lähtekoha reegel ja erand profiili enda sisse. Kõik kolm kuuluvad ühe kavandi juurde ja neid muudetakse koos.