WireGuard hálózati névtérben: miért maradt le a socket

A felület abban a névtérben szerepel, amelyet akart, az alkalmazás hozzá van kötve, és mégsem jelenik meg soha alagútforgalom. Ez a Linux-kernel WireGuard-eszközének ismertetőjele, amelyet egy névtérben hoztak létre, majd egy másikba helyeztek át: a felület átkerült, a titkosított UDP socketje viszont nem. Mindkettőnek a megfelelő helyen kell lennie, mielőtt a belső forgalom számít. Az ellenőrzés gyors, amint tudja, hogy két kontextust kell nézni egy helyett.

A tünet: megfelelő névtér, mégis nincsenek csomagok

A névtéren belül az alagút egészségesnek látszik. Az eszköz létezik, a címek ki vannak osztva, és a partner konfigurációja jelen van. Kívülről a várt UDP-csere soha nem jelenik meg azon a felületen, amelyet figyelt, és a túloldal azt jelenti, hogy nem történt kézfogás.

Az ok az, hogy az alkalmazás belső csomagjai elérik az áthelyezett eszközt, és az eszköz egy olyan socketen próbálja elküldeni őket, amely egy másik hálózati kontextushoz tartozik. Az általa használt alapszintű útvonal és minden rá vonatkozó tűzfal-szabály az abban a névtérben található, ahol az eszköz létrejött.

Ez nem hiba az áthelyezésben, és nem a partner hibás konfigurációja. A kernel implementációja így működik, és a WireGuard névtereiről szóló dokumentáció közvetlenül leírja a létrehozási szabályt.

Miért van a socketnek születési helye

Egy WireGuard-eszköz egy UDP socketet birtokol a titkosított átviteléhez, és ez a socket abban a névtérben nyílik meg, ahol az eszköz létrejön. A felület hivatkozási paranccsal történő áthelyezése átviszi a látható eszközt, de az átvitelt ott hagyja, ahol elkezdődött. Ekkor a két objektumnak különböző a tulajdonosa.

A következmény könnyen elkerüli a figyelmet, mert a két felet különböző helyeken vizsgálják. A belső útvonal abban a névtérben dől el, ahol az alkalmazás fut, a külső útvonal pedig ott, ahol a socket él. Ha csak az egyiket ellenőrzi, magabiztos, de téves következtetésre jut. Ha mindkettőt, a vizsgálat általában egyetlen menetben véget ér.

Ott hozza létre, ahol a socketet akarja

A megoldás az, hogy az eszközt a cél-névtéren belül hozza létre, nem pedig kívül, majd áthelyezi. Feltételezve, hogy egy jóváhagyott névtér már létezik, és a név nem használt:

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

Most már a felület és a socketje is ehhez a kontextushoz tartozik, tehát az alapszintű útvonal és az alkalmazandó szűrési szabályok az ott beállítottak. Ha a terv a tiszta oldalt máshol igényli, először tegye a mögöttes felületet a névtérbe, és utána hozza létre az alagútat. A sorrend a terv része, nem implementációs részlet.

Kezelje őket hálózati adminisztrációs parancsokként, nem receptként. Eszközt hoznak létre és állapotot mutatnak; a kulcsoknak, partnereknek, címeknek és útvonalaknak továbbra is jóváhagyott konfigurációból kell származniuk, és egy meglévő éles felületet soha nem szabad egy példába behelyettesíteni.

Olvassa el az útvonal mindkét oldalát

Amikor az eszköz a megfelelő helyen van, ellenőrizze a két döntést külön. Kezdje a belső kereséssel az alkalmazás kontextusából, majd ellenőrizze a külső utat abból a kontextusból, amely a socketet birtokolja:

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

Ha a belső keresés az alagúton keresztül oldódik meg, és a külső rögzítés mutatja a titkosított cserét, a két fél egyetért. Ha a rögzítés üres, a socket még máshol van, vagy a névterében lévő alapszintű útvonal nem éri el a végpontot.

Még egy ellenőrzés tartozik a feljegyzésbe: hogyan jön létre az eszköz újraindítás után. Az a kezelő, amely más létrehozási kontextussal alkotja újra a felületet, megváltoztatja a socket születési helyét. Egy egyszer működő kézi áthelyezés nem bizonyíték a kezelt útvonalról.