WireGuard vasitəsilə bir tətbiq: bağlama marşrutlaşdırma deyil

Parametr tətbiq üzrə açar kimi görünür, ona görə insanlar klienti WireGuard interfeysinə bağlayır və yalnız həmin klientin tuneldən istifadə edəcəyini gözləyirlər. Bağlama əslində mənbə ünvanı seçir. Sonra yadro təyinat üçün marşrut axtarır, adi standart marşrutu tapır və paketi tunel ünvanını üzərinə əlavə edərək fiziki kanaldan göndərir. Yalnız həmin mənbə ünvanı üçün seçilmiş marşrut bu niyyəti tamamlayır.

Mexanizmin iki yarısı var: yalnız tunelin trafikinin istifadə etməli olduğu marşrut cədvəli və uyğun mənbəni ora göndərən qayda.

Bağlama mənbə ünvanı təyin edir, başqa heç nə

Linux çıxış interfeysini təyinatı marşrut cədvəlində axtararaq seçir; siyasət qaydaları bu axtarışı yönləndirmək imkanını əvvəlcə almış olur. Qaydalar mənbə ünvanına, firewall işarəsinə, daxil olan interfeysə, UID-ə və hətta porta görə seçim edə bilər; hər biri bütün trafik əvəzinə bu trafik deməyin başqa bir yoludur. VPN klientinin konfiqurasiyası tunel marşrutlarını saxlayan cədvəli seçir; qayda hansı trafikin ona müraciət edə biləcəyini seçir. Tək bağlama heç birini vermir.

Uğursuzluğun bu qədər qəribə görünməsinin səbəbi budur. Tətbiq mütləq tunel ünvanından istifadə edir, tunel mütləq işləyir və trafik mütləq səhv interfeysdən çıxır. Hər ifadə doğrudur və birlikdə ünvana marşrutu bağlayan heç nəyin olmadığı sistemi təsvir edir.

Tunelə öz cədvəlini verin

wg-quick marşrutları profil harada deyirsə orada quraşdırır. [Interface] altına Table = 40 əlavə etmək onları əsas cədvəl əvəzinə 40 nömrəli cədvələ köçürür. İnterfeysi qaldırın və onların gəldiyini təsdiqləyin: ip -4 route ls table 40 tunelin marşrutlarını göstərməlidir, ip -4 route get 10.66.127.142 isə yadronun onlardan birini hazırda necə həll etdiyini göstərir. Marşrutlar öz cədvəlində olduğu halda əsas cədvəl qalan hər şey üçün işləməyə davam edir.

Eyni şeyi geniş prefiks uyğunlaşdırmaq əvəzinə IPv6 üçün edin. ip -6 rule add from fd00::2/128 lookup 40 bir ünvanı sabitləyir; fc00::/8 hostdakı digər interfeyslərlə toqquşa və nəzərdə tutulandan çoxunu uyğunlaşdıran qayda yarada bilər.

Mənbə qaydasını əlavə edin və sayğacları izləyin

Sonra yarıları birləşdirin: ip -4 rule add from 10.66.127.142/32 lookup 40, həmin ünvan WireGuard interfeysinə bağlanmış halda. Hər iki qaydayı PostUp içinə qoyun ki, yenidən qoşulma onları bərpa etsin. Parametrlə deyil, real sorğu ilə yoxlayın: ip route get 1.1.1.1 from 10.66.127.142 tunel qurğusunu adlandırmalıdır, curl --interface wg0 ifconfig.me isə ev ünvanı əvəzinə tunelin ünvanını bildirməlidir.

Hələ də alınmırsa, ip -s rule oxuyun. Mövcud olub heç vaxt uyğunlaşmayan qayda sıfır sayğac göstərir və bu, səhv qaydayı qaydanın heç olmamasından ayırır. Bu tək əmr tətbiqin öz interfeys parametrini görməməzliyə vurub-vurmadığı barədə çoxlu təxmini aradan qaldırır.

Əks hal: SSH-ı tuneldən kənarda saxlayın

Əks problem də eyni dərəcədə geniş yayılıb: wg-quick standart marşruta sahibdir və serverə SSH sessiyası sessiya ortasında kəsilir. Onun qaydaları aşağı prioritet nömrəsində dayanır, ona görə istisna onlardan əvvəl qiymətləndirilməlidir. ip rule add dport 22 ipproto tcp table main priority 123 bunu yeni iproute2-də edir; selektor mövcud olmayan yerdə axını nftables-da işarələyin və əvəzində işarəni uyğunlaşdırın.

Cavab yolunu da yoxlayın. Qurulan, sonra səssizləşən SSH sessiyasında adətən asimmetrik marşrutlaşdırma olur: bir istiqamət tuneldən, digəri fiziki interfeysdən çıxır. Server ünvanı üçün ip route get cavabın hansı yolla gedəcəyini bildirir.

Cədvəl nömrəsini, mənbə qaydasını və istisnanı profilin özündə qeyd edin. Üçü də bir dizayna aiddir və birlikdə redaktə olunacaq.