Aplikazio bat WireGuard bidez: lotzeak ez du bideratzen

Ezarpenak aplikazioko etengailu baten itxura du, beraz jendeak bezeroa WireGuard interfazera lotzen du eta bezero horrek bakarrik erabiliko duela tunela espero du. Lotzeak benetan egiten duena iturburu-helbide bat hautatzea da. Ondoren, kernelak ibilbide bat bilatzen du helmugarako, ohiko lehenetsitako ibilbidea aurkitzen du eta paketea esteka fisikotik bidaltzen du tunelaren helbidea erantsita. Iturburu-helbide horretarako hautatutako ibilbide batek soilik betetzen du asmoa.

Mekanismoak bi erdi ditu: tunelaren trafikoak soilik erabili behar duen bideratze-taula bat, eta iturburu egokia hara bidaltzen duen arau bat.

Lotzeak iturburu-helbide bat ezartzen du, ez besterik

Linuxek irteerako interfazea hautatzen du helmuga bideratze-taula batean bilatuz, politika-arauak bilaketa hori berbideratzeko aukera izan ondoren. Arauek iturburu-helbidearen, suebaki-markaren, sarrerako interfazearen, UID baten edo are portu baten arabera hauta dezakete; bakoitza trafiko hau eta ez guztia esateko beste modu bat da. VPN bezeroaren konfigurazioak tunelaren ibilbideak dituen taula hautatzen du; arauak zein trafikok kontsulta dezakeen hautatzen du. Lotzeak berak ez du bat ere ematen.

Horregatik dirudi hutsegiteak hain arraro. Aplikazioak tunelaren helbidea erabiltzen du zalantzarik gabe, tunela martxan dago zalantzarik gabe, eta trafikoak interfaze okerretik irteten du zalantzarik gabe. Baieztapen bakoitza egia da, eta elkarrekin helbidea ibilbidearekin lotu ez zuen sistema bat deskribatzen dute.

Eman tunelari bere taula propioa

wg-quick-ek ibilbideak profilean esaten zaion tokian instalatzen ditu. [Interface] azpian Table = 40 gehitzeak taula 40ra eramaten ditu taula nagusiaren ordez. Altxatu interfazea eta egiaztatu iritsi direla: ip -4 route ls table 40-ek tunelaren ibilbideak erakutsi beharko lituzke, eta ip -4 route get 10.66.127.142-ek kernelak orain nola ebazten duen horietako bat erakusten du. Ibilbideak beren taulan daudenean, taula nagusiak gainerako guztiarentzat funtzionatzen jarraitzen du.

Egin gauza bera IPv6rako, aurrizki zabal bat parekatu beharrean. ip -6 rule add from fd00::2/128 lookup 40-ek helbide bat finkatzen du; fc00::/8-ek hosteko beste interfaze batzuekin talka dezake eta asmoa baino gehiago parekatzen duen arau bat sortu.

Gehitu iturburuaren araua eta begiratu kontagailuak

Ondoren lotu bi erdiak: ip -4 rule add from 10.66.127.142/32 lookup 40, helbide bera WireGuard interfazera erantsita. Jarri bi arauak PostUp barruan, berriz konektatzeak berrezar ditzan. Egiaztatu benetako eskaera batekin, ez ezarpen batekin: ip route get 1.1.1.1 from 10.66.127.142-ek tunelaren gailua izendatu beharko luke, eta curl --interface wg0 ifconfig.me-ek tunelaren helbidea jakinarazi beharko luke, etxekoarena eman beharrean.

Oraindik huts egiten badu, irakurri ip -s rule. Badagoen baina inoiz bat etorri ez den arau batek zero kontagailu erakusten ditu, eta horrek arau okerra araurik ez egotetik bereizten du. Komando bakar horrek asko aurrezten du aplikazioak bere interfaze-ezarpena alde batera utzi ote zuen asmatzeko.

Alderantzizko kasua: eduki SSH tunelaz kanpo

Aurkako arazoa bezain ohikoa da: wg-quick-ek lehenetsitako ibilbidea dauka eta zerbitzariko SSH saioa sesioaren erdian hiltzen da. Bere arauak lehentasun-zenbaki baxuan daude, beraz salbuespen bat haiek baino lehenago ebaluatu behar da. ip rule add dport 22 ipproto tcp table main priority 123-ek hori egiten du iproute2 berri batean; hautatzailea erabilgarri ez dagoen tokian, markatu fluxua nftables-en eta parekatu marka.

Egiaztatu erantzunaren bidea ere. Ezarri eta gero isiltzen den SSH saio batek bideratze asimetrikoa izaten du normalean: norabide bat tunelatik irteten da eta bestea interfaze fisikotik. ip route get-ek zerbitzariaren helbiderako esango dizu norantz joango litzatekeen erantzuna.

Idatzi taularen zenbakia, iturburuaren araua eta salbuespena profilean bertan. Hirurak diseinu bakarrekoak dira eta elkarrekin editatu beharko dira.