Egy alkalmazás WireGuardon át: a hozzárendelés nem útválasztás

A beállítás alkalmazásonkénti kapcsolónak tűnik, ezért az emberek a klienst a WireGuard-interfészhez rendelik, és azt várják, hogy csak az a kliens használja az alagutat. A hozzárendelés valójában forrás-címet választ. A kernel ezután útvonalat keres a célhoz, megtalálja a szokásos alapértelmezett útvonalat, és a csomagot a fizikai kapcsolaton küldi ki, az alagút címét hozzákapcsolva. Csak az ehhez a forrás-címhez választott útvonal teljesíti a szándékot.

A mechanizmusnak két fele van: egy útválasztási tábla, amelyet csak az alagút forgalmának szabadna használnia, és egy szabály, amely a megfelelő forrást odaküldi.

A hozzárendelés forrás-címet ad, semmi többet

A Linux a kimenő interfészt úgy választja ki, hogy a célt egy útválasztási táblában keresi, miután a házirend-szabályok lehetőséget kaptak erre a keresésre való átirányításra. A szabályok választhatnak a forrás-cím, egy tűzfal-jelölés, a bejövő interfész, egy UID vagy akár egy port alapján; mindegyik más módja annak, hogy ezt a forgalmat mondjuk a teljes helyett. A VPN-kliens konfigurációja választja ki az alagút útvonalait tartalmazó táblát; a szabály választja ki, hogy melyik forgalom tekinthet bele. A hozzárendelés önmagában egyiket sem adja.

Ezért tűnik olyan furcsának a hiba. Az alkalmazás biztosan az alagút címét használja, az alagút biztosan fent van, és a forgalom biztosan a rossz interfészen megy ki. Minden állítás igaz, és együtt olyan rendszert írnak le, amelyben semmi nem kapcsolta a címet az útvonalhoz.

Adj az alagútnak saját táblát

A wg-quick oda telepíti az útvonalakat, ahová a profil mondja. A Table = 40 hozzáadása a [Interface] alatt a fő tábla helyett a 40-es táblába mozgatja őket. Hozd fel az interfészt, és ellenőrizd, hogy megérkeztek: a ip -4 route ls table 40-nak meg kellene mutatnia az alagút útvonalait, a ip -4 route get 10.66.127.142 pedig megmutatja, hogyan oldja fel a kernel jelenleg az egyiket. Ha az útvonalak a saját táblájukban vannak, a fő tábla minden másra tovább működik.

Tedd ugyanezt az IPv6-tal, ahelyett hogy széles előtagot egyeztetnél. A ip -6 rule add from fd00::2/128 lookup 40 egy címet rögzít; a fc00::/8 ütközhet a hoszt más interfészeivel, és olyan szabályt hozhat létre, amely a szándékosnál többre illeszkedik.

Add hozzá a forrásszabályt, és figyeld a számlálókat

Aztán kösd össze a két felet: ip -4 rule add from 10.66.127.142/32 lookup 40, ugyanazzal a címmel a WireGuard-interfészhez kapcsolva. Tedd mindkét szabályt a PostUp alá, hogy egy újracsatlakozás helyreállítsa őket. Valódi kéréssel ellenőrizd, ne beállítással: a ip route get 1.1.1.1 from 10.66.127.142-nak meg kellene neveznie az alagút eszközét, a curl --interface wg0 ifconfig.me-nak pedig az alagút címét kellene jelentenie az otthoni helyett.

Ha még mindig nem megy, olvasd el a ip -s rule-t. Egy létező, de soha nem illeszkedő szabály nulla számlálókat mutat, és ez különbözteti meg a rossz szabályt a szabály hiányától. Az az egy parancs sok találgatást spórol meg arról, hogy az alkalmazás figyelmen kívül hagyta-e az interfész beállítását.

A fordított eset: tartsd az SSH-t az alagúton kívül

Az ellenkező probléma ugyanolyan gyakori: a wg-quick birtokolja az alapértelmezett útvonalat, és a szerver felé menő SSH-munkamenet menet közben meghal. A szabályai alacsony prioritási számon ülnek, ezért egy kivételt előbb kell kiértékelni, mint őket. A ip rule add dport 22 ipproto tcp table main priority 123 ezt teszi egy újabb iproute2-n; ahol a szelektor nem elérhető, jelöld meg a folyamot az nftables-ben, és illeszkedj a jelölésre.

Ellenőrizd a válasz útját is. Az a SSH-munkamenet, amely felépül, majd elhallgat, általában aszimmetrikus útválasztással rendelkezik: az egyik irány az alagúton, a másik a fizikai interfészen megy ki. A ip route get a szerver címére megmondja, merre indulna a válasz.

Jegyezd fel a tábla számát, a forrásszabályt és a kivételt magában a profilban. Mindhárom egyetlen tervezéshez tartozik, és együtt lesz szerkesztve.