WireGuard tinklo vardų erdvėje: kodėl lizdas liko užnugaryje

Sąsaja įtraukta į vardų erdvę, kurios norėjote, programa prie jos prijungta, o tunelio srauto vis tiek niekada nesimato. Tai Linux branduolio WireGuard įrenginio, sukurto vienoje vardų erdvėje ir perkeltas į kitą, požymis: sąsaja persikėlė, o jos šifruotas UDP lizdas – ne. Abu turi būti tinkamoje vietoje, kol vidinis srautas dar neturi reikšmės. Patikra greita, kai žinote, jog reikia žiūrėti į du kontekstus, o ne į vieną.

Simptomas: teisinga vardų erdvė, bet paketų nėra

Vardų erdvės viduje tunelis atrodo sveikas. Įrenginys yra, adresai priskirti, o partnerio konfigūracija yra. Iš išorės laukiamas UDP mainai niekada nepasireiškia sąsajoje, kurią stebėjote, o priešinga pusė praneša, kad rankos paspaudimo nebuvo.

Priežastis ta, kad vidiniai programos paketai pasiekia perkeltą įrenginį, o įrenginys bando juos siųsti per lizdą, kuris priklauso kitam tinklo kontekstui. Pagrindinis maršrutas, kurį jis naudoja, ir kiekviena ugniasienės taisyklė, kuri jam taikoma, yra tos, esančios vardų erdvėje, kurioje įrenginys buvo sukurtas.

Tai ne perkėlimo klaida ir ne neteisinga partnerio konfigūracija. Taip veikia branduolio realizacija, o WireGuard vardų erdvių dokumentacija tiesiogiai aprašo kūrimo taisyklę.

Kodėl lizdas turi gimimo vietą

WireGuard įrenginys turi vieną UDP lizdą savo šifruotam perdavimui, ir tas lizdas atidaromas toje vardų erdvėje, kurioje įrenginys sukuriamas. Sąsajos perkėlimas nuorodos komanda perkelia matomą įrenginį, bet perdavimą palieka ten, kur jis prasidėjo. Tada du objektai turi skirtingus savininkus.

Pasekmę lengva praleisti, nes abi pusės tikrinamos skirtingose vietose. Vidinis maršrutas nustatomas vardų erdvėje, kurioje veikia programa, o išorinis maršrutas nustatomas ten, kur gyvena lizdas. Patikrinus tik vieną, gaunama užtikrinta, bet klaidinga išvada. Patikrinus abu, tyrimas paprastai baigiamas per vieną ėjimą.

Sukurkite jį ten, kur norite lizdo

Sprendimas – sukurti įrenginį paskirties vardų erdvės viduje, o ne sukurti jį išorėje ir perkelti. Darant prielaidą, kad patvirtinta vardų erdvė jau egzistuoja, o vardas nenaudojamas:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Dabar ir sąsaja, ir jos lizdas priklauso tam kontekstui, todėl pagrindinis maršrutas ir taikomos filtravimo taisyklės yra ten sukonfigūruotos. Jei projektuojant reikia atviros pusės kitur, pirmiausia įdėkite pagrindinę sąsają į vardų erdvę, o po to sukurkite tunelį. Tvarka yra dizaino dalis, o ne įgyvendinimo detalė.

Traktuokite juos kaip tinklo administravimo komandas, o ne kaip receptą. Jie sukuria įrenginį ir parodo būseną; raktai, partneriai, adresai ir maršrutai vis tiek turi ateiti iš patvirtintos konfigūracijos, o esama gamybinė sąsaja niekada neturėtų būti pakeista pavyzdyje.

Skaitykite abi kelio puses

Kai įrenginys tinkamoje vietoje, patikrinkite du sprendimus atskirai. Pradėkite vidinę paiešką iš programos konteksto, tada patikrinkite išorinį kelią iš konteksto, kuriam priklauso lizdas:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Jei vidinė paieška išsprendžiama per tunelį ir išorinis įrašas rodo šifruotus mainus, abi pusės sutampa. Jei įrašas tuščias, lizdas vis dar kažkur kitur, arba pagrindinis maršrutas jo vardų erdvėje nepasiekia galinio taško.

Dar viena patikra priklauso įrašui: kaip įrenginys sukuriamas po paleidimo iš naujo. Tvarkyklė, kuri atkuria sąsają su kitu kūrimo kontekstu, pakeičia lizdo gimimo vietą. Rankinis perkėlimas, kuris vieną kartą pavyko, nėra įrodymas apie valdomą kelią.