Bütün maşın olmadan bir tətbiqi VPN-dən necə keçirmək olar

VPN müştərisi qoşulur, brauzer işləyir, amma əslində vacib olan yeganə əmr hələ də ev bağlantınızdan çıxır. Ya da əksi olur: tunel standart marşrutu tutur və yerli fayl serveri masaüstündən yox olur. Bunu ofis LAN-da qalan hostla daxili artefakt güzgüsünə çatmalı olan bir build agenti ilə yaşadım və müştəri yalnız iki seçim təklif etdi: bütün trafik və ya heç nə. Hər iki tərəfdə tələb eynidir, bu proqram və bütün maşın deyil, və əksər müştərilərdə bunun üçün qeyd xanası yoxdur, çünki marşrut cədvəli heç vaxt proqramın nə olduğunu bilməyib.

Marşrut cədvəli niyə proqramınızı görə bilmir

Proses paket göndərdikdə, stek təyinat ünvanını marşrut cədvəlində axtarır. Nə icra olunan faylın adı, nə də port bu axtarışa daxil olur. Domen adları da eyni səbəbdən uğursuz olur: tunel trafiki ünvana aparır və ad ünvana çevrilənə qədər marşrutlaşdırma nüvənin hələ də malik olduğu yeganə qoldur. Buna görə “yalnız bu sayt üçün VPN” sonda proxy demək olur, “yalnız bu proqram üçün VPN” isə kiçik bir mexanizm dəstindən birini ifadə edir.

Bunların heç biri proses üzrə marşrut deyil. Hər biri qərarı proqramı, istifadəçini və ya tətbiqin öz konfiqurasiyasını görə bilən qata köçürür.

Tək bir təyinat hələ də marşrutdur, proqram qaydası deyil. macOS-da adi üsul “Bütün trafiki VPN üzərindən göndər” işarəsini götürmək və host marşrutu əlavə etməkdir: sudo route add -host internal-tuner.example -interface ppp0, sonra sudo route delete -host internal-tuner.example -interface ppp0 ilə silinir. İnterfeys adını əvvəlcə ifconfig çıxışından oxuyun, çünki ppp0 yalnız nümunədir. Host marşrutunda joker simvollar işləmir, ona görə bir neçə adla danışan xidmət hər ad üçün bir giriş tələb edir və qayda maşında olan hər prosesi əhatə edir, sizin nəzərdə tutduğunuzu deyil.

Soketi tunel ünvanına bağlayın

Müştəriyə nəzarət etdikdə, bağlama ən ucuz seçicidir. Tunelin yerli ünvanına bağlanmış soket, həmin interfeysdə təyinat üçün marşrut olduğu müddətcə oradan çıxır və maşındakı hər şey öz normal yolunu saxlayır. İncəlik ondadır ki, bağlama mənbə ünvanını seçir, marşrut cədvəli isə hələ də çıxışı seçir. Tək başına bağlama tunelə marşrutu olmayan trafiki köçürmür və “bağladım, yenə də yanlış yolla çıxır” şikayətlərinin çoxunun arxasında bu səhv dayanır.

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

Yüksək səviyyəli alətlər eyni fikri təqdim edir: curl --interface 10.8.0.2, PHP-də CURLOPT_INTERFACE və Python-un HTTP müştərilərində source_address arqumenti. Ünvan tunelə aid olmalıdır və burada bir yazı səhvi marşrut şikayəti kimi deyil, adi bağlantı xətası kimi uğursuz olur. Ünvan yerinə cihaz adına bağlamaq Linux-da imtiyazdır və Windows və ya macOS-a keçmir, buna görə portativ skriptlər ünvanı ötürür.

Linux: proqram adını deyil, sahibi uyğunlaşdırın

Nüvə soketin sahib istifadəçisini uyğunlaşdıra bilər, buna görə ayrılmış hesab seçiciyə çevrilir. Tuneli öz marşrut cədvəlinə qoyun və yalnız həmin hesabın trafikini ora göndərin:

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

Bu yalnız tunel artıq standart marşrut deyilsə işləyir. Müştərini --route-nopull ilə başladın və ya göndərilən yönləndirməni --pull-filter ignore "redirect-gateway" ilə OpenVPN 2.4 və sonrasında süzgəcdən keçirin, sonra cədvəl girişini özünüz əlavə edin. Əks halda hər iki standart mövcud olur və aşağı prioritetli olan qalib gəlir. Bunun qəsdən edilən versiyası standart marşrutu tunel şluzuna yönəltmək və ya bunu əlaqə kəsmə skriptindən etməkdir: tunel düşəndə trafiki internetdən kənarda saxlayır, amma bu seçici deyil, dayandırma açarıdır və kimsə silənə qədər qalır.

Daha güclü versiya şəbəkə ad məkanıdır. Onu yaradın, müştərini içəridə işlədin və tətbiqi ip netns exec ilə başladın. Ad məkanından kənarda heç nə tunel interfeysini görmür, buna görə tətbiq təsadüfən host marşrutuna qayıda bilməz. Xərc realdır: ad məkanı fiziki şəbəkəyə çatmaq üçün veth cütünə və öz həlledici faylına ehtiyac duyur, çünki montaj ad məkanı hostun həll ayarlarını paylaşmır.

İki uğursuzluq rejimi sızmaların çoxunu izah edir. Ad həlli hələ də hostun həlledicisində baş verir, buna görə TCP bağlantısı içəri getsə də sorğu tuneldən kənara çıxır. Və IPv6 öz ip -6 rule qaydasına ehtiyac duyur, çünki v4 qaydası onu əhatə etmir.

Windows və macOS: firewall-u məhdudlaşdırın və ya proxy verin

Windows-da da tətbiq üzrə marşrut seçicisi yoxdur, amma firewall qaydaları profilə görə məhdudlaşdırıla bilər və VPN adapteri Public kimi təsnif edilə bilər, ev LAN-ı isə Private qalır. Proqram üçün Private və Domain profillərində gedən bloklama qaydaları yaradın, Public-i açıq buraxın, beləliklə tətbiq şəbəkəyə yalnız tunel vasitəsilə çata bilər. Əvvəlcə bağlantının şəbəkə kateqoriyasını təyin edin, sonra qaydanın firewall-un monitor panelində uyğunlaşdığını təsdiqləyin. Bu marşrut deyil, bloklamadır: tunel düşəndə qapalı şəkildə uğursuz olur və firewall-a məhəl qoymayan tətbiqi dayandıra bilmir.

macOS fərqli alətlərlə eyni məntiqi izləyir. SSH üzərindən əldə edilən SOCKS dinləyicisi ən az müdaxilə edən seçimdir, çünki ssh -D 1080 user@host bir yerli port yaradır və yalnız ondan istifadə etmək üçün konfiqurasiya edilmiş tətbiqlər bu yolla gedir. pf qaydası proqramı istifadəçi və ya qrup üzrə bloklaya bilər, amma hələ də yalnız həmin proqram üçün tuneli seçə bilmir. Tunnelblick ümumiyyətlə domen üzrə süzgəc tətbiq edə bilmir, çünki marşrutlar ünvanlarla işləyir; OpenConnect istifadəçiləri server çox geniş prefiks siyahısı göndərdikdə vpn-slice alətinə əl atır.

İki alternativ platform alətlərinin qaçırdığını örtür. Proksini domen üzrə dəyişən brauzer genişlənmələri “yalnız bu sayt” üçün praktik cavabdır, çünki adların hələ də mövcud olduğu tətbiq qatında işləyirlər; bir brauzeri əhatə edir, başqa heç nəyi. Kobud variant satıcı müştərisini virtual maşında işlətməkdir ki, qonaq marşrut dəyişikliyinin sahibi olsun, host isə öz yolunu saxlasın; bunun xərci baxım tələb edən iki şəbəkə stekidir.

Bağlama seçimi olmayan alətlər üçün SOCKS atlaması

Əksər tətbiqlər interfeyslər haqqında heç nə bilməsələr də HTTP və ya SOCKS proksisinə yönəldilə bilər. SSH müştərisi server tərəfində heç bir dəyişiklik olmadan birini təqdim edir:

ssh -N -D 127.0.0.1:9999 [email protected]

Həmin portdan istifadə etmək üçün konfiqurasiya edilmiş hər şey bastionda çıxır, masaüstün qalanı isə öz normal bağlantısını saxlayır. Tunel ünvanına bağlanmış yerli 3proxy nüsxəsi SSH olmadan bir port üçün eyni şeyi edir və stunnel tək bir TLS ilə bükülmüş portu əhatə edir. Məhdudiyyətlər praktikdir: proxy yalnız ondan istifadə etməyi bilən protokolları daşıyır, UDP üçün bir çox müştərinin “SOCKS5” ayarı ilə aktivləşdirilməyən SOCKS5 UDP assosiasiyası lazımdır, və DNS proxy tərəfindən həll olunmalıdır (curl-da socks5h), əks halda ad yerli həllediciyə sızır.

Başqa maşın ehtiyac duymursa, dinləyicini loopback-də saxlayın.

Yolu status mesajı ilə deyil, tutma ilə yoxlayın

Tətbiqin status pəncərələri parametri təsvir edir, paketi yox. Hər iki interfeysdə tutun və müqayisə edin:

tcpdump -i any -n port 443
ss -tnp | grep 443

Bağlantı fiziki interfeysdə görünürsə və tuneldə uyğun giriş yoxdursa, müştəri nə deyirsə desin, seçici işləmir. IPv6-nı və həlledicini ayrıca yoxlayın, həmçinin köməkçi proses və ya miras qalmış sistem proksisi kimi ikinci yol olub-olmadığını yoxlayın.

Sonra tələbə uyğun sərhədi seçin: bir sayt üçün proxy kifayətdir, bir hesab üçün UID qaydası kifayətdir, bağlantı qapalı şəkildə uğursuz olmalı olduqda firewall profili kifayətdir, və ad məkanı tuneli ondan kənardakı hər şeydən gizlədən yeganə seçimdir.