Jedna aplikácia cez WireGuard: naviazanie nie je smerovanie

Nastavenie vyzerá ako prepínač pre jednotlivú aplikáciu, a tak ľudia naviažu klienta na rozhranie WireGuard a očakávajú, že tunel bude používať len ten klient. Naviazanie v skutočnosti vyberie zdrojovú adresu. Jadro potom vyhľadá cestu k cieľu, nájde obvyklú predvolenú cestu a pošle paket fyzickým spojom s priradenou adresou tunela. Zámer splní len cesta vybraná pre túto zdrojovú adresu.

Mechanizmus má dve polovice: smerovaciu tabuľku, ktorú má používať len prevádzka tunela, a pravidlo, ktoré tam pošle zodpovedajúci zdroj.

Naviazanie určuje zdrojovú adresu, nič viac

Linux vyberá výstupné rozhranie vyhľadaním cieľa v smerovacej tabuľke po tom, čo pravidlá politiky dostali šancu toto vyhľadanie presmerovať. Pravidlá môžu vyberať podľa zdrojovej adresy, značky firewallu, prichádzajúceho rozhrania, UID alebo dokonca portu; každé je iný spôsob, ako povedať táto prevádzka namiesto všetkej. Konfigurácia VPN klienta vyberá tabuľku, ktorá drží cesty tunela; pravidlo vyberá, ktorá prevádzka ju smie použiť. Samotné naviazanie nedodá ani jedno.

Preto zlyhanie vyzerá tak zvláštne. Aplikácia rozhodne používa adresu tunela, tunel rozhodne beží a prevádzka rozhodne odchádza nesprávnym rozhraním. Každé tvrdenie je pravdivé a spolu opisujú systém, v ktorom nič nespojilo adresu s cestou.

Dajte tunelu vlastnú tabuľku

wg-quick inštaluje cesty tam, kam mu profil povie. Pridanie Table = 40 pod [Interface] ich presunie do tabuľky 40 namiesto hlavnej tabuľky. Zdvihnite rozhranie a overte, že dorazili: ip -4 route ls table 40 má ukázať cesty tunela a ip -4 route get 10.66.127.142 ukazuje, ako jadro práve jednu z nich rieši. Keď sú cesty vo vlastnej tabuľke, hlavná tabuľka ďalej funguje pre všetko ostatné.

Urobte to isté pre IPv6 namiesto porovnávania širokého prefixu. ip -6 rule add from fd00::2/128 lookup 40 pripne jednu adresu; fc00::/8 sa môže zraziť s inými rozhraniami na hostiteľovi a vytvoriť pravidlo, ktoré zodpovedá viac, než je zamýšľané.

Pridajte pravidlo zdroja a sledujte počítadlá

Potom spojte obe polovice: ip -4 rule add from 10.66.127.142/32 lookup 40, s tou istou adresou priradenou rozhraniu WireGuard. Dajte obe pravidlá do PostUp, aby ich opätovné pripojenie obnovilo. Overte skutočnou požiadavkou, nie nastavením: ip route get 1.1.1.1 from 10.66.127.142 má uviesť zariadenie tunela a curl --interface wg0 ifconfig.me má hlásiť adresu tunela, nie domácu.

Keď to stále nefunguje, prečítajte si ip -s rule. Pravidlo, ktoré existuje, ale nikdy sa netrafilo, ukazuje nulové počítadlá, a to odlíši nesprávne pravidlo od žiadneho pravidla. Ten jediný príkaz ušetrí veľa hádania o tom, či aplikácia ignorovala svoje nastavenie rozhrania.

Opačný prípad: držte SSH mimo tunela

Opačný problém je rovnako častý: wg-quick vlastní predvolenú cestu a SSH relácia na server zomiera uprostred. Jeho pravidlá sedia na nízkom čísle priority, takže výnimka sa musí vyhodnotiť skôr ako ony. ip rule add dport 22 ipproto tcp table main priority 123 to robí v novšom iproute2; kde selektor nie je k dispozícii, označte tok v nftables a porovnávajte značku.

Skontrolujte aj cestu odpovede. SSH relácia, ktorá sa nadviaže a potom stíchne, má zvyčajne asymetrické smerovanie: jeden smer odchádza tunelom a druhý fyzickým rozhraním. ip route get pre adresu servera vám povie, kadiaľ by odpoveď išla.

Zapíšte číslo tabuľky, pravidlo zdroja a výnimku do samotného profilu. Všetky tri patria k jednému návrhu a budú sa upravovať spolu.