WireGuard tīkla vārdu telpā: kāpēc ligzda palika aiz muguras

Saskarne ir iekļauta vārdu telpā, kuru vēlējāties, lietotne ir tai piesaistīta, un tomēr tuneļa trafiks nekad neparādās. Tā ir Linux kodola WireGuard ierīces pazīme, kas izveidota vienā vārdu telpā un pārvietota uz citu: saskarne pārvietojās, bet tās šifrētā UDP ligzda ne. Abiem jābūt pareizajā vietā, pirms iekšējam trafikam ir nozīme. Pārbaude ir ātra, tiklīdz zināt, ka jāskatās divi konteksti, nevis viens.

Simptoms: pareiza vārdu telpa, bet nav pakešu

Vārdu telpas iekšpusē tunelis izskatās vesels. Ierīce pastāv, adreses ir piešķirtas, un partnera konfigurācija ir klāt. Ārpusē gaidītā UDP apmaiņa nekad neparādās saskarnē, kuru novērojāt, un pretējā puse ziņo, ka rokas spiediens nav noticis.

Iemesls ir tāds, ka lietotnes iekšējās paketes sasniedz pārvietoto ierīci, un ierīce mēģina tās sūtīt pa ligzdu, kas pieder citam tīkla kontekstam. Pamata maršruts, ko tā izmanto, un katrs ugunsmūra noteikums, kas uz to attiecas, ir tie, kas atrodas vārdu telpā, kurā ierīce tika izveidota.

Tā nav pārvietošanas kļūda un nav nepareiza partnera konfigurācija. Tā darbojas kodola implementācija, un WireGuard vārdu telpu dokumentācija tieši apraksta izveides noteikumu.

Kāpēc ligzdai ir dzimšanas vieta

WireGuard ierīcei pieder viena UDP ligzda tās šifrētajam transportam, un šī ligzda tiek atvērta vārdu telpā, kurā ierīce tiek izveidota. Saskarnes pārvietošana ar saites komandu pārvieto redzamo ierīci, bet transportu atstāj tur, kur tas sākās. Tad abiem objektiem ir dažādi īpašnieki.

Sekas ir viegli palaist garām, jo abas puses tiek pārbaudītas dažādās vietās. Iekšējais maršruts tiek noteikts vārdu telpā, kurā darbojas lietotne, un ārējais maršruts tiek noteikts tur, kur dzīvo ligzda. Pārbaudot tikai vienu, iegūst pārliecinātu, bet nepareizu secinājumu. Pārbaudot abus, izmeklēšana parasti beidzas vienā piegājienā.

Izveidojiet to tur, kur vēlaties ligzdu

Risinājums ir izveidot ierīci mērķa vārdu telpas iekšpusē, nevis izveidot to ārpusē un pārvietot. Pieņemot, ka apstiprināta vārdu telpa jau pastāv un nosaukums nav izmantots:

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

Tagad gan saskarne, gan tās ligzda pieder šim kontekstam, tāpēc pamata maršruts un piemērojamie filtrēšanas noteikumi ir tie, kas tur konfigurēti. Ja dizainam vajadzīga atvērtā puse citur, vispirms ievietojiet pamata saskarni vārdu telpā un pēc tam izveidojiet tuneli. Secība ir dizaina daļa, nevis ieviešanas detaļa.

Uztveriet tos kā tīkla administrēšanas komandas, nevis recepti. Tie izveido ierīci un parāda stāvokli; atslēgām, partneriem, adresēm un maršrutiem joprojām jānāk no apstiprinātas konfigurācijas, un esošo ražošanas saskarni nekad nevajadzētu aizstāt piemērā.

Lasiet abas ceļa puses

Kad ierīce ir pareizajā vietā, pārbaudiet abus lēmumus atsevišķi. Sāciet ar iekšējo meklēšanu no lietotnes konteksta, pēc tam pārbaudiet ārējo ceļu no konteksta, kuram pieder ligzda:

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

Ja iekšējā meklēšana atrisinās caur tuneli un ārējais ieraksts rāda šifrēto apmaiņu, abas puses sakrīt. Ja ieraksts ir tukšs, ligzda joprojām ir citur, vai pamata maršruts tās vārdu telpā nesasniedz galapunktu.

Vēl viena pārbaude pieder ierakstam: kā ierīce tiek izveidota pēc restartēšanas. Pārvaldnieks, kas atkārtoti izveido saskarni ar citu izveides kontekstu, maina ligzdas dzimšanas vietu. Manuāla pārvietošana, kas vienreiz nostrādāja, nav pierādījums par pārvaldīto ceļu.