Adi Linux tətbiqi TUN-a toxunmadan VPN-dən istifadə edir

Qurulmuş Linux VPN-dən istifadə edən brauzer /dev/net/tun açmır. O, soket açır və paketlərin hansı interfeysdən çıxacağına yadro qərar verir. Tuneli yaradan proses, onun daşıdığı trafikin prosesindən fərqli iş görür. Bu iki rolu ayrı saxlamaq, icazə suallarının çoxuna soruşulmadan cavab verir.

Bir paketi soketdən tunelə qədər izləyin

Adi tətbiq connect və ya send çağırır, yadro isə təyinat üçün marşrut axtarır. Seçilmiş marşrut tunel interfeysinə işarə edirsə, paket VPN daemonunun oxuduğu cihazın növbəsinə düşür. Daemon onu şifrələyir və fiziki interfeysdən çölə göndərir. Bu təsvirdəki hər ox icazə sualının cavablandırıla biləcəyi bir yerdir.

Bu yolda heç nə tətbiqin cihaz haqqında bilməsini tələb etmir. Fayl deskriptorunu daemon saxlayır və interfeys əməliyyatlarını yerinə yetirir, tətbiq isə yalnız adi şəbəkə API-si görür.

İki yarısını bir dəfə çəkin, icazə suallarını yerləşdirmək asanlaşar. Yuxarı yarı tətbiq dünyasıdır, aşağı yarı isə daemona aiddir.

Cihaza kimin ehtiyacı olduğunu və kimin olmadığını müəyyənləşdirin

TUN interfeysi yaratmaq və ya ona qoşulmaq cihaza giriş və əlavə olaraq onu konfiqurasiya etmək səlahiyyəti tələb edir, buna görə dəstəklənən VPN xidməti şəbəkə idarəetmə səlahiyyəti ilə başlayır və ya imtiyazlı köməkçi istifadə edir. Bu tələb daemona aiddir. O, brauzer, verilənlər bazası müştərisi və ya fayl ötürmə aləti haqqında heç nə demir. Səlahiyyətə ehtiyacı olan xidmət onu öz quraşdırma addımı üçün istəyir, müştəriləri üçün deyil.

Marşrut və siyasət yerində olduqdan sonra adi proses nəticə yolunu adi soket çağırışları ilə istifadə edir. Ona cihaz qovşağı lazım deyil və root da lazım deyil.

Cihaz icazələrini dəyişmək tətbiqə təyinat girişi verməyin yolu deyil. Bu, yalnız cihaz sərhədini başqa yerə köçürür.

Tətbiqin həqiqətən hansı ad məkanında işlədiyini yoxlayın

Konteyner və ya ikinci şəbəkə ad məkanı öz proseslərinə ayrı interfeys dəsti və marşrut cədvəli verir. Hostdakı tunel orada avtomatik görünmür və heç bir cihaz icazəsi dəyişikliyi bunu dəyişdirə bilməz. Tətbiq sadəcə həmin ad məkanının təqdim etdiyi yoldan keçəcək. Buna görə konteyner obrazı host tunelini təsadüfən miras ala bilməz.

ip netns list və ip -n NAME route ilə və ya prosesin ad məkanı keçidini yoxlamaqla yoxlayın. Cavab adətən bir əmrdə görünür.

Eyni hostdakı iki istifadəçiyə siyasətlə fərqli yollar da verilə bilər. Bu, cihaz sahibliyinə dair sübut deyil, şəbəkə qərarıdır.

Səlahiyyətləri şəbəkə siyasətindən ayırın

Bəzi alətlərə soketdən çoxu lazımdır. Paket tutmaq üçün xam soket, marşrutları dəyişmək üçün idarəetmə səlahiyyəti lazımdır. Bunlar ayrı icazələrlə ayrı əməliyyatlardır və birinin verilməsi VPN-dən istifadə üçün ümumi tələb kimi oxunmamalıdır.

Öz tunelini həyata keçirən proqram üçüncü haldır. O, həqiqətən TUN açır, çünki daemonun rolunu öz üzərinə götürür, buna görə də daemonun imtiyazlarına ehtiyacı var.

İmtiyazı adlandırmadan əvvəl əməliyyatı adlandırın. İkisini ayırmaq adətən göründüyündən asandır.

Bölgünü iki hesabla yoxlayın

Tuneli xidmət kimi qoşun, sonra tətbiqi adi istifadəçi kimi işə salın və şəxsi resursa çatdığını təsdiqləyin. Həmin istifadəçinin qabığından təyinat üçün ip route get yoxlayın ki, hansı interfeysin seçildiyini görəsiniz. Marşrut düzdürsə və bağlantı yenə də alınmırsa, problem imtiyazda deyil, siyasətdədir.

Nəticədə yaranan dizayn açıq sərhədlə minimum imtiyazdır: bir komponent quraşdırmaya və tunel resurslarına sahibdir, iş yükləri adi hesablarını saxlayır, şəbəkə siyasəti isə nəyin keçəcəyinə qərar verir. Hər şeyi root kimi işə salmaq bu rolları izah etmədən yığcamlaşdırır.