Jedna aplikace přes WireGuard: navázání není směrování

Nastavení vypadá jako přepínač pro jednotlivou aplikaci, a tak lidé navážou klienta na rozhraní WireGuard a čekají, že tunel bude používat jen ten klient. Navázání ve skutečnosti vybere zdrojovou adresu. Jádro pak vyhledá cestu k cíli, najde obvyklou výchozí cestu a pošle paket fyzickým spojem s přiřazenou adresou tunelu. Záměr splní jen cesta vybraná pro tuto zdrojovou adresu.

Mechanismus má dvě poloviny: směrovací tabulku, kterou má používat jen provoz tunelu, a pravidlo, které tam odpovídající zdroj pošle.

Navázání určuje zdrojovou adresu, nic víc

Linux vybírá výstupní rozhraní vyhledáním cíle ve směrovací tabulce poté, co pravidla zásad dostala šanci toto vyhledání přesměrovat. Pravidla mohou vybírat podle zdrojové adresy, značky firewallu, příchozího rozhraní, UID nebo dokonce portu; každé je jiný způsob, jak říct tento provoz místo všeho. Konfigurace VPN klienta vybírá tabulku, která drží cesty tunelu; pravidlo vybírá, který provoz ji smí použít. Samotné navázání nedodá ani jedno.

Proto selhání vypadá tak podivně. Aplikace rozhodně používá adresu tunelu, tunel rozhodně běží a provoz rozhodně odchází špatným rozhraním. Každé tvrzení je pravdivé a dohromady popisují systém, ve kterém nic nespojilo adresu s cestou.

Dejte tunelu vlastní tabulku

wg-quick instaluje cesty tam, kam mu profil řekne. Přidání Table = 40 pod [Interface] je přesune do tabulky 40 místo hlavní tabulky. Zvedněte rozhraní a ověřte, že dorazily: ip -4 route ls table 40 má ukázat cesty tunelu a ip -4 route get 10.66.127.142 ukazuje, jak jádro právě jednu z nich řeší. Když jsou cesty ve vlastní tabulce, hlavní tabulka dál funguje pro všechno ostatní.

Udělejte totéž pro IPv6, místo abyste porovnávali široký prefix. ip -6 rule add from fd00::2/128 lookup 40 připne jednu adresu; fc00::/8 se může srazit s jinými rozhraními na hostiteli a vytvořit pravidlo, které odpovídá víc, než je zamýšleno.

Přidejte pravidlo zdroje a sledujte čítače

Pak spojte obě poloviny: ip -4 rule add from 10.66.127.142/32 lookup 40, s tou samou adresou přiřazenou rozhraní WireGuard. Dejte obě pravidla do PostUp, aby je opětovné připojení obnovilo. Ověřte skutečným požadavkem, ne nastavením: ip route get 1.1.1.1 from 10.66.127.142 má uvést zařízení tunelu a curl --interface wg0 ifconfig.me má hlásit adresu tunelu, ne domácí.

Když to pořád nefunguje, přečtěte si ip -s rule. Pravidlo, které existuje, ale nikdy se netrefilo, ukazuje nulové čítače, což odliší špatné pravidlo od žádného pravidla. Ten jediný příkaz ušetří spoustu hádání o tom, zda aplikace ignorovala nastavení rozhraní.

Opačný případ: držte SSH mimo tunel

Opačný problém je stejně častý: wg-quick vlastní výchozí cestu a SSH relace na server umírá uprostřed. Jeho pravidla sedí na nízkém čísle priority, takže výjimka se musí vyhodnotit dřív než ona. ip rule add dport 22 ipproto tcp table main priority 123 to dělá v novějším iproute2; kde selektor není k dispozici, označte tok v nftables a porovnávejte značku.

Zkontrolujte i cestu odpovědi. SSH relace, která se naváže a pak ztichne, má obvykle asymetrické směrování: jeden směr odchází tunelem a druhý fyzickým rozhraním. ip route get pro adresu serveru vám řekne, kudy by odpověď šla.

Zapište číslo tabulky, pravidlo zdroje a výjimku do samotného profilu. Všechny tři patří k jednomu návrhu a budou se editovat společně.