Bir Linux prosesini WireGuard tunelindən kənarda necə işlətmək olar

Bir proqramı tam tunelli WireGuard hostundan marşrutları redaktə etməklə azad etmək olmaz. Marşrutlar yolu təyinat üzrə seçir, sizin azad etmək istədiyiniz isə prosesdir, ona görə də nüvənin uyğunlaşdıracağı heç nə yoxdur. İşlək yanaşma həmin prosesə öz şəbəkə kontekstini verməkdir: öz interfeysi, ünvanları və standart marşrutu olan, veth cütü ilə hosta birləşdirilən adlar məkanı. Mən bunu Ubuntu 24.04 və wireguard-tools 1.0.20210914 üzərində işlətdim və adlar məkanı heç vaxt problem deyildi — hostun yönləndirmə siyasəti və tunelin işarələmə qaydaları idi.

Əvvəlcə hansı kontekst növünə ehtiyacınız olduğunu seçin

Təcrübədə iki forma görünür. Əgər host tam tunel işlədirsə və bir proqram provayder yolundan çıxmalıdırsa, ikinci adlar məkanı qurursunuz, onu hosta qoşursunuz və host onun üçün trafiki yönləndirib ünvanı dəyişir. Əgər adlar məkanı artıq VPN interfeysi daşıyırsa və sizə yalnız onun içində başladılan əmr lazımdırsa, bu, adi ip netns exec halıdır və marşrut işinin çoxu artıq görülüb.

Heç bir forma sizə tək proses ID-si ilə məhdudlaşan qayda vermir. Netfilter ünvanları, portları, işarələri və interfeysləri uyğunlaşdırır; hər proses üçün marşrut cədvəli yoxdur. İşarələmə trafiki yönəldə bilər, lakin işarə artıq müəyyən etdiyiniz paketlərə tətbiq edilməlidir, bu da eyni problemin bir qat aşağıda olmasıdır. Adlar məkanı həmin proses ağacı üçün bütün yığını ayırır və buna görə də adi cavab budur.

Əgər tələb həqiqətən tuneldən heç nəyin çıxmamasıdırsa, əvəzində tuneli dayandırın. Adlar məkanı qarışıq hal üçündür: bir proqram bayıra, qalan hər şey içəri, eyni maşında, eyni vaxtda.

İkinci konteksti qurun və hosta qoşun

İllüstrativ düzülüş: hostun standart marşrutu daşıyan WireGuard interfeysi və adı clearnet olan, veth cütü ilə hosta birləşdirilmiş şəbəkə adlar məkanı var. Aşağıdakı ünvanlar nümunədir.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

Bu adlar məkanı artıq hosta çata bilir və başqa heç nəyə yox. Host trafiki yönləndirməli və mənbə ünvanını yenidən yazmalıdır, çünki 192.168.100.0/24 şəbəkəsi özəldir və yuxarı axın routerinin ona geri marşrutu yoxdur:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

Davam etməzdən əvvəl adlar məkanı tərəfini təsdiqləyin.ip netns exec clearnet ip route veth marşrutunu və 192.168.100.1 üzərindən standart marşrutu göstərməli, həmin ünvana ping cavab verməlidir. Əgər host ünvanına ping uğursuz olarsa, ünvanlar və ya keçid vəziyyəti səhvdir və heç bir firewall qaydası kömək etməyəcək.

Adlar həll olunur, amma heç nə qayıtmırsa, FORWARD-ı oxuyun

Klassik uğursuzluq marşrut xətası kimi görünür: adlar məkanı adı həll edir, paket çıxır və heç vaxt cavab gəlmir. FORWARD siyasəti DROP olan hostlarda — bir neçə distributiv və sərtləşdirilmiş obrazlar belədir — paket keçid zamanı atılır və tətbiqin çap etdiyi xəta filtrasiya haqqında heç nə demir.

Bir şey əlavə etməzdən əvvəl zənciri oxuyun:

iptables -S FORWARD
nft list chain inet filter forward

Sonra trafiki hər iki istiqamətdə, sayğaclarla buraxın ki, qaydanın heç uyğunlaşıb-uyğunlaşmadığını biləsiniz:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

Paket sayğacı sıfır olan qayda yolda deyil. Ya interfeys adları fərz etdiyinizdən fərqlidir, ya da zəncirdəki əvvəlki qayda paketi birinci qəbul edib, atıb və ya qaytarıb. Sıranı düzəldin, qayda mətnini yox.

Cavab trafiki insanların unutduğu yarıdır. Qaytarma qaydasına eyni veth adı və əlaqə vəziyyəti uyğunluğu lazımdır, ya da siyasəti açıq saxlayırsınızsa, adi interfeys qəbulu. Yalnız giden qaydanı əlavə edin və orijinal simptom geri qayıdır, yeni qaydanız isə orada düzgün görünür.

Tunelin işarələmə qaydalarını yeni yoldan uzaq saxlayın

Bu addım işlək adlar məkanını sızdıran birinə çevirir. WireGuard quraşdırmaları adətən firewall işarəsi siyasəti ilə öz marşrut qaydalarını və ayrı cədvəl quraşdırır, belə ki işarələnməmiş paketlər əsas cədvələ düşür, işarələnmiş paketlər isə tunel cədvəlindən istifadə edir. Adlar məkanından yönləndirilən trafik çıxarkən siyasət marşrutlaşdırmasına görə qiymətləndirilir və bu qaydaların necə yazıldığından asılı olaraq tunel cədvəlinə düşə bilər.

İki əlavə yolları ayırır. Adlar məkanı alt şəbəkəsi üçün mangle zəncirində erkən qayıdın və həmin alt şəbəkəni əsas cədvələ qoyan mənbə əsaslı qayda əlavə edin:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

Prioritet 100 mənim hostumda tunel qaydalarından əvvəl sıralanır, ona görə həmin mənbə üçün adi cədvəl qərar verir. Rəqəmi kor-koranə kopyalamayın:wg-quick quraşdırdığı prioritetlər versiyalar arasında və IPv4 ilə IPv6 qurulumları arasında fərqlənir, ona görə ip rule show işlədin və maşınınızda tunel qaydalarının önünə düşən prioritet seçin.

Yoxlayın mənbəyə xas axtarış ilə, qaydalar siyahısına güvənmək əvəzinə:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

Əgər birinci əmr WireGuard interfeysini bildirirsə, yeni qayda hələ tunel siyasətinin qarşısında deyil. Əgər WAN interfeysini bildirir, ikinci isə hələ də veth standart marşrutunu göstərirsə, host və adlar məkanı razılaşmır və hər iki marşrut cədvəlini yenidən oxumalısınız.

Bağlantını açan prosesi başladın

Əmri başlatmaq bir sətirdir, amma soketi həqiqətən yaradan prosesi başladın.ip netns exec clearnet curl -s https://ifconfig.me ən kiçik dürüst testdir: adlar məkanının dünyaya təqdim etdiyi ünvanı göstərir, hostun istifadə edəcəyini yox.

Bir xidmət üçün adlar məkanını yol ilə qoşun ki, proses bütün ömrü boyu orada qalsın:

[Service]
NetworkNamespacePath=/run/netns/clearnet

Qrafik tətbiqlər bir sətirlik yanaşmanın səssizcə uğursuz olduğu yerdir. Menyudan başladılan brauzer sorğunu çox vaxt artıq adlar məkanından kənarda işləyən nüsxəyə ötürür, ona görə yeni pəncərə görünür və trafik hələ də tuneldən çıxır. Ona ayrı profil verin ki, həqiqətən yeni nüsxə yaradılsın, sonra təxmin etmək əvəzinə proses kontekstinə baxın:

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

İki çıxış uyğun olmalıdır. Eyni yoxlama istənilən uzunmüddətli proqram üçün işləyir və başladıcının nəzərdə tutduğunuzu etdiyini fərz etmək əvəzinə hər tətbiq üçün bir dəfə etməyə dəyər.

Ad həlli öz qərarını tələb edir. Adlar məkanı yaratmaq ona rezolver konfiqurasiyası vermir; hər adlar məkanı üçün fayllar /etc/netns/<name>/resolv.conf vasitəsilə dəstəklənir və onsuz asanlıqla səhv oxunan davranışı miras alırsınız. IPv6 eyni münasibət tələb edir: əgər adlar məkanının v6 standart marşrutu yoxdursa və tətbiq v6-ya üstünlük verirsə, sorğular geri çəkilməzdən əvvəl dayana bilər, bu da qırıq tunel kimi görünür.

Çərçivəni yoxlayın, yalnız çıxış ünvanını yox

İşlək ictimai ünvan marşrutu sübut edir, bütün tələbi yox. Qalanını bu sıra ilə keçin:

• ip netns exec clearnet ip route get 1.1.1.1 veth standart marşrutunu göstərir, WireGuard interfeysini yox.
• Hər iki qaydadakı FORWARD sayğacları sorğu işləyərkən artır.
• Tətbiq prosesi gözlədiyiniz adlar məkanı inode-unu bildirir.
• Yenidən başlatmadan sonra adlar məkanı xidmət başlamazdan əvvəl mövcuddur; daha əvvəl işləyən unit uğursuz olur, ya da daha pisi, adlar məkanından kənarda işləyir.

Sonra tunel düşdükdə nə olması lazım olduğuna qərar verin. Adlar məkanı işləməyə davam edir, bu məşqin məqsədi və eyni zamanda riskidir: azad edilmiş proqram bağlı qalır, qalan hər şey dayanır. Bunu siyasət seçimi kimi qeyd edin və azadetmənin nəyi əhatə etmədiyini aydınlaşdırın — hesab kimliyi, yadda saxlanmış brauzer vəziyyəti və DNS provayderiniz hamısı şəbəkə adlar məkanının əhatəsindən kənarda oturur və azadetməni anonimlik kimi qəbul etmək konfiqurasiyadan uzun yaşayan səhvdir.