Bir Linux proqramını UID qaydaları ilə VPN-ə bağlamaq

Bir proqramı Linuxda VPN-ə bağlamaq əsasən marşrut problemi, və firewall qaydası yalnız marşrut seçildikdən sonra nə baş verdiyini həll edir. Proqramın UID-nu tunel default marşruta sahib olmadan əvvəl OUTPUT-da uyğunlaşdırsanız, qayda qorumaq istədiyiniz trafiki özü atır. Eyni qayda proqramın DNS sorğularına cavab verən resolver prosesini də görə bilmir. Sıranı düzgün qurun və imtiyazsız bir hesab etibarlı split-tunnel seçicinə çevrilir.

Hesaba hökmdən əvvəl marşrut verin

Sahib uyğunluğu bir suala cavab verir: bu UID-ə aid yerli soket paketi qurubmu? O, interfeys seçmir və əsas cədvəlin artıq fiziki NIC-dən göndərdiyi trafiki dəyişə bilmir. Buna görə uyğun marşrutu olmayan UID qaydası proqramı yönləndirmək əvəzinə bloklayır.

Hesabı əvvəlcə öz cədvəlindən keçirin, sonra qoyun firewall nəticəni təsdiqləsin. Bu, iproute2-si uidrange anlayan hostda işləyir və bu ip rule help bir sətirdə bildirir. Cədvəl 100 tuneldən keçən default marşrut saxlayır və qayda yalnız UID 1000-i həmin cədvələ göndərir. Qalan hər şey əsas cədvəldə qalır və fiziki keçiddən istifadə etməyə davam edir.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

Fərqli tunelə ehtiyacı olan ikinci hesab cədvəl 101-i və öz qaydasını alır, çünki iki profil eyni cədvəldə default marşruta birlikdə sahib ola bilməz. NetworkManager profilləri sistem səviyyəsindədir, ona görə bu hissə əl ilə qalır və qaydalar yenidən başladıldıqda bərpa olunmasa yox olur. Cədvəlləri tunel tərifinin yanında yükləmə skriptinə yazın ki, yenidən qoşulma bir hesabı səhv yolda qoymasın.

Niyə loopback istisnası tuneli öldürür

Qaydanın kopyalanan versiyalarının çoxu loopback-dən çıxmayan hər paketi atır. Tunel loopback deyil, ona görə bu forma tunel trafikini də atır və nəticə firewall səhvi deyil, ölü VPN kimi görünür.

OUTPUT işləyəndə kernel artıq çıxış interfeysini seçmiş olur, buna görə -o paket başlığına deyil, marşrutun cavabına uyğunlaşdırılır. Sahib uyğunluğu yalnız OUTPUT və POSTROUTING-də nəzərə alınır və yönləndirilən paketlər onun oxuyacağı soket daşımır. Bu birləşmə o deməkdir ki, istisna loopback-i inkar etmək əvəzinə tunel interfeysini adlandırmalı və həmin uyğunluğu inkar etməlidir.

Loopback hələ də DROP-dan yuxarıda öz ACCEPT-inə layiqdir, çünki proqramdan ilk DNS paketi yerli stub-a lo. üzərindən gedir. İki qaydanı bu sıra ilə qoyun və hesab stub-a, sonra tunelə çatır, başqa heç yerə yox.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 ayrı qaydalar toplusudur və yalnız v4 üçün olan cüt ip6tables toxunulmadan qoyur. AAAA qeydlərinə üstünlük verən proqram o zaman DROP-a heç çatmadan fiziki keçiddən çıxır. Hər iki qaydanı ip6tables-də əks etdirin və ya tunel v6 ünvanı daşımırsa, hostda IPv6-nı söndürün. Əl ilə əlavə edilən qaydalar da yenidən başladıldıqda yox olur, ona görə onları netfilter-persistent save ilə saxlayın və ya eyni məntiqi yükləmə vahidinin yüklədiyi nftables cədvəli kimi yenidən qurun.

DNS cavabları başqa prosesdən gəlir

Proqramın 127.0.0.53 ünvanına sorğusu loopback ACCEPT-dən keçir və UID uyğunluğu məhz orada dayanır. Stub resolver sorğunu öz xidmət hesabından yuxarı ötürür, ona görə vpnapp-a bağlanmış qayda ikinci sorğunu heç vaxt görmür. Resolver keçid üçün LAN serveri seçirsə, cavablar fiziki NIC-dən qayıdır, proqramın öz paketləri isə tuneldə qalır. Görünən nəticə adları pozulmuş işlək tunel və ya seçmədiyiniz serverin cavab verdiyi adlardır.

Ad həllini tətbiqdə deyil, tunel keçidində düzəldin. Tunel profilinə DNS serveri və marşrut domeni verin, sonra resolvectl query və resolvectl status tun0 ilə resolverin vacib adlar üçün ondan istifadə etdiyini təsdiqləyin. Şəbəkə ad məkanı içində problem yox olur, çünki ad məkanı resolveri yalnız tuneli tanıyır.

Qaydayı hesabın özündən yoxlayın

Kerneldən UID-in hansı marşrutu aldığını soruşun, sonra həmin hesabla sorğu göndərin və çıxış ünvanını öz hesabınızınkı ilə müqayisə edin. İkisi də eyni ünvanı bildirirsə, qayda sınaqdan keçirdiyiniz trafikdən başqa bir şeylə uyğunlaşır. Aşağıdakı ilk əmr paket göndərmədən marşrut axtarışını göstərir və bununla marşrut səhvini firewall səhfindən ayırır.

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

Sayğaclar qaydanın heç işləyib-işləmədiyini göstərir. iptables -vnL OUTPUT əmrini işlədin, hər qaydanın yanındakı paket sayını oxuyun və real trafikdən sonra DROP-un yanındakı sıfırı uyğunluq səhvi kimi qəbul edin.

Yönləndirilən trafik bu dizaynın xaricindədir. Körpü arxasındakı konteyner və ya VM-in vpnapp-a aid yerli soketi yoxdur, ona görə sahib uyğunluğu heç vaxt işləmir və həmin paketlər əvəzinə FORWARD siyasətinə tabe olur. Əgər bu yükü əhatə etmək lazımdırsa, onu ayrıca sınaqdan keçirin və körpüyə və ya konteyner ünvanına bağlı siyasət yazın. Dizayn o zaman dayanır ki, cədvəl, interfeys istisnası, resolver və v6 qaydaları hamısı eyni tərəfi göstərsin; onlardan hər hansı birini buraxın və hesab ya sızacaq, ya da əlaqəni itirəcək.