İki tətbiq eyni ofis serverinə bağlantı açır və yalnız biri tuneldən istifadə etməlidir. Marşrut bu istəyi ifadə edə bilmir, çünki marşrutlaşdırma cədvəlləri təyinatlar üzərində qurulur və soketi hansı prosesin açdığı barədə heç bir anlayışı yoxdur. İnsanların istədiyi ilə onlara lazım olan çox vaxt fərqli şeylərdir. Hər hansı konfiqurasiyanı dəyişməzdən əvvəl ikisini ayırın.

Seçici təyinatdır, heç vaxt proses deyil

Hər marşrutlaşdırma qərarı təyinat ünvanı ilə başlayır və interfeyslə bitir. Nüvə heç vaxt paketi hansı proqramın göndərdiyini soruşmur və macOS-də pf də proses üzrə marşrutlaşdırmır, ona görə də firewall qaydası bir tətbiqi başqa yola qoya bilməz. Buna görə də eyni serverə həm brauzerdən, həm də hesabat alətindən müraciət edilsə, ikisi üçün bir yol istifadə olunur. Tətbiq səviyyəsində ayrılma buna görə marşrutdan başqa bir şeydən gəlməlidir: soketə sahib VPN plaqini, bağlantını tətbiqin adından götürən proxy və ya ayrı şəbəkə steki. Bunların heç biri marşrut dəyişikliyi deyil.

Bir ünvanla danışan iki tətbiq dizaynın ən təmiz sınağıdır. Cavab onların arasında fərqlənə bilmirsə, dizayn adı nə olursa olsun, təyinat əsaslıdır.

Adi split tunnel həqiqətən nə verir

Split tunnel özəl prefikslər üçün marşrutlar qurur və qalan hər şeyi fiziki yolda saxlayır. Adətən sorğunun mənası budur: ofis serverinə tunel vasitəsilə çatmaq, ictimai gəzintini birbaşa saxlamaq. Sadədir, hər adi müştəri onu dəstəkləyir və hər hansı marşrut kimi eyni mexanizmlə tətbiq olunur. Konkret təyinatı route -n get ilə yoxlayın, standart marşrutu oxumaq əvəzinə, çünki split tunnel standart marşrutu çox vaxt toxunulmaz qoyur.

Standart marşrutu əl ilə redaktə etmək heç nəyə keçid deyil. O, müştərinin öz marşrut bərpası ilə mübarizə aparır və mühafizə siyasəti quraşdıran müştərilərdə maşını nə sizin, nə də müştərinin gözlədiyi vəziyyətdə qoya bilər. Əvəzində split tunnel-i müştərinin dəstəklənən parametrlərində konfiqurasiya edin.

macOS-də tətbiq üzrə VPN nə tələb edir

macOS-də əsl tətbiq üzrə VPN konfiqurasiya profili ilə idarə olunan Network Extension funksiyasıdır. İdarəetmə yükü seçilmiş tətbiqləri VPN konfiqurasiyasına bağlayır və sistem sonra həmin tətbiqlərin trafikini uyğun olaraq yönləndirir. Bu, idarə olunan yerləşdirmədir, yəni MDM, imzalanmış profil və hər ikisinə sahib administrator tələb edir.

Müştərini əl ilə quraşdırmaq bu uyğunlaşdırmanı yaratmır və adi parametrlər paneli tətbiqləri ayrı-ayrılıqda seçilə bilən etmir. Təchizatçı öz tətbiq qaydalarını təqdim edə bilər və onlar ümumi qaydaya deyil, onun sənədlərinə uyğun gəlir.

MDM olmadan tətbiq üzrə ayrılmanın üç yolu

İdarəetmənin mövcud olmadığı yerdə proxy praktik cavabdır. Tətbiqin öz proxy konfiqurasiyasını qurun və ya yalnız həmin tətbiq üçün təyinat və protokol üzrə seçim edən PAC faylından istifadə edin.

Yerli proxy bağlantını bitirir və onu tunel vasitəsilə yenidən qurur, beləliklə tətbiqə heç vaxt marşrut lazım olmur. İkinci variant ayrı şəbəkə stekidir: öz standart marşrutu olan virtual maşın və ya konteyner, ona tətbiq yerli ünvan vasitəsilə çatır. Üçüncüsü təyinat əsaslı marşrutlaşdırmanı qəbul edib tələbdən imtina etməkdir ki, bu, hər iki tətbiq tuneldən istifadə edə bildikdə dürüstdür. Üçü də yoxlanıla bilər və heç biri marşrutun prosesləri bildiyini iddia etmir.

Sorğunu cavab birmənalı olacaq şəkildə yazın

Mexanizmi deyil, iş axınını təsvir edin: hansı tətbiqə hansı xidmət lazımdır, başqa tətbiqi həmin xidmətdən uzaq saxlamaq lazımdırmı və tunel söndürülmüşkən nə baş verməlidir. Bu üç cavab dizaynı seçir. Onlar administratora sorğunun marşrut dəyişikliyi, yoxsa yerləşdirmə layihəsi olduğunu da deyir.

Kənarlaşdırılmış tətbiq halını açıq şəkildə daxil edin. Qorunan yolu mövcud olmadıqda tətbiqi dayandıran müştəri, onun fiziki interfeysə qayıtmasına imkan verən müştəridən fərqli davranır və istifadəçilər bu fərqi dərhal görür. Gözləntini biletdə adlandırın. Sonra real maşında yoxlayın, çünki eyni məhsul macOS-də Windows-dakından fərqli davranır və onun macOS sənədləri parametrlərinin nə etdiyi barədə yeganə etibarlı mənbədir.

Əlaqəli məqalələr