Eng App duerch WireGuard: binden ass net routing
Eng App un wg0 binden setzt just hir Quelladress. De Kernel brauch nach ëmmer eng Tabell mat den Tunnelrouten an eng Regel, déi déi Quell dohinner schéckt.
D'Astellung gesäit aus wéi e Schalter pro Applikatioun, dofir binden d'Leit de Client un d'WireGuard-Interface a erwaarden, datt just dee Client den Tunnel benotzt. Wat d'Bannen tatsächlech mécht, ass eng Quelladress auswielen. Duerno sicht de Kernel eng Route fir den Destinatioun, fënnt déi gewéinlech Standardroute an schéckt de Pak iwwer de physikalesche Link eraus, mat der Tunneladress ugehaangen. Just eng Route, déi fir déi Quelladress gewielt gouf, erfëllt d'Absicht.
De Mechanismus huet zwou Hälften: eng Routingstabell, déi just den Trafic vum Tunnel soll benotzen, an eng Regel, déi déi passend Quell dohinner schéckt.
Binden setzt eng Quelladress, méi net
Linux wielt en Ausgangsinterface, andeem en den Destinatioun an enger Routingstabell sicht, nodeems d'Politiksregelen d'Geleeënheet haten, déi Sich ëmzeleeden. Regelen kënnen no der Quelladress, engem Firewall-Mark, dem agaangenen Interface, enger UID oder souguer engem Port auswielen; jidderee ass eng aner Manéier, dësen Trafic ze soen amplaz alles. D'Konfiguratioun vum VPN-Client wielt d'Tabell, déi d'Tunnelroute hält; d'Regel wielt, wéi en Trafic se konsultéiere däerf. Binden eleng liwwert keng vun den zwou.
Dofir gesäit de Feeler sou komesch aus. D'Applikatioun benotzt sécher d'Tunneladress, den Tunnel ass sécher erop, an den Trafic geet sécher iwwer dat falscht Interface eraus. All Ausso ass richteg, an zesumme beschreiwen si e System, an deem näischt d'Adress mat der Route verbonnen huet.
Gitt dem Tunnel seng eege Tabell
wg-quick installéiert Routen do, wou et de Profil seet. Table = 40 ënner [Interface] bäisetze beweegt se an d'Tabell 40 amplaz an d'Haapttabell. Hieft den Interface erop a bestätegt, datt se ukomm sinn: ip -4 route ls table 40 soll d'Tunnelroute weisen, an ip -4 route get 10.66.127.142 weist, wéi de Kernel momentan eng dovun opléist. Mat de Routen an hirer eegener Tabell schafft d'Haapttabell fir alles anescht weider.
Maacht datselwecht fir IPv6 amplaz e breedt Präfix ze vergläichen. ip -6 rule add from fd00::2/128 lookup 40 fixéiert eng Adress; fc00::/8 kann mat aneren Interfacen um Host kollidéieren an eng Regel produéieren, déi méi entsprécht wéi geduecht.
Setzt d'Quellregel derbäi a kuckt op d'Zähler
Dann verbënnt déi zwou Hälften: ip -4 rule add from 10.66.127.142/32 lookup 40, mat derselwechter Adress um WireGuard-Interface ugehaangen. Setzt béid Regelen an PostUp, sou datt eng Reconnect si restauréiert. Verifizéiert mat enger richteger Ufro amplaz enger Astellung: ip route get 1.1.1.1 from 10.66.127.142 soll den Tunnelapparat nennen, an curl --interface wg0 ifconfig.me soll d'Tunneladress mellamplaz vun der Heemadress.
Wann et nach ëmmer feelt, liest ip -s rule. Eng Regel, déi existéiert, awer ni entsprach huet, weist Null-Zähler, an dat ënnerscheet eng falsch Regel vun enger Tabell ouni Regel. Dee enze Befehl spuert vill Roten doriwwer, ob d'Applikatioun hir Interface-Astellung ignoréiert huet.
De ëmgedréinte Fall: hält SSH aus dem Tunnel eraus
De Géigendeel-Problem ass genee esou heefeg: wg-quick besëtzt d'Standardroute an d'SSH-Sessioun zum Server stierft mëttendran. Seng Regele sëtzen op enger niddereger Prioritéitsnummer, dofir muss eng Ausnam éischt bewäert ginn. ip rule add dport 22 ipproto tcp table main priority 123 mécht dat op engem neien iproute2; wou de Selekter net verfügbar ass, markéiert de Floss an nftables a passt de Mark un.
Kuckt och de Wee vun der Äntwert. Eng SSH-Sessioun, déi sech opbaut an duerno stëll gëtt, huet meeschtens asymmetresch Routing, woubäi eng Richtung duerch den Tunnel erausgeet an déi aner duerch dat physikalescht Interface. ip route get fir d'Serveradress seet Iech, wou d'Äntwert géif higoen.
Notéiert d'Tabellnummer, d'Quellregel an d'Ausnam am Profil selwer. Alleguer déi dräi gehéieren zu engem Entworf a ginn zesummen editéiert.