Poçt VPN olmadan serverə çatır: qaydanı harada tətbiq etməli

Poçt sorğu göndərməyə davam edir və VPN söndürülüb, amma hesab yenə də sinxronlaşır. Tətbiq konfiqurasiya edildiyi işi görür; adi poçt profilində serverin yalnız tunel vasitəsilə əlçatan olduğunu deyən heç nə yoxdur. Bu, iki fərqli tələb qoyur və onları qarışdırmaq asandır: xidmət birbaşa müştəriləri rədd etməlidir, ya da Mac heç cəhd etməməlidir.

Məhsul seçməzdən əvvəl tələbi seçin. Server qaydası və müştəri qaydası müxtəlif yerlərdə uğursuz olur, müxtəlif sübutlar verir və müxtəlif sahiblərə aiddir. Hər ikisini tətbiq etmək, hər iki ifadə doğru olduqda qüvvədədir, lakin biri digərinin əvəzi deyil. Hər iki tələb qanunidir; sadəcə eyni nəzarət deyillər.

Simptom Mac kimi görünür, amma sızma server ola bilər

Poçt tuneldən kənarda sinxronlaşdıqda, serverin nə qəbul etdiyindən başlayın. Poçt dinləyicisi internetdən birbaşa bağlantıya cavab verirsə, müştəri tərəfindəki heç bir rahatlıq parametri bu faktı dəyişmir. Mac hələ açıq olan xidmətə qarşı normal davranır.

Poçt administratorundan xidmətin hansı mənbə ünvanını gördüyünü soruşun. VPN şlüzü, tərs proxy və ya yük balanslaşdırıcısı müştəri ünvanını dəyişə bilər, buna görə VPN konfiqurasiyasındakı ünvan hovuzu poçt prosesinə çatanla uyğun gəlməyə bilər. Səhv mənbəyə yazılmış qayda ya hamını bloklayır, ya heç kimi.

Bu cavab həm də xidmətin VPN müştərilərini ümumiyyətlə ayırd edib-edə bilmədiyini göstərir. Hər müştəri eyni proxy ünvanından gəlirsə, mənbəyə əsaslanan qəbul onları ayıra bilməz və tələb autentifikasiyaya və ya müştəri tərəfinə keçməlidir.

Server qəbulu: tətbiqi deyil, mənbəyi rədd edin

Host və ya şəbəkə firewallu poçt dinləyicisini təsdiqlənmiş mənbə diapazonları ilə məhdudlaşdıra bilər, autentifikasiya və TLS isə dəyişməz qalır. Uzaq ünvanları, alt şəbəkələri və ya diapazonları uyğunlaşdıran qayda şərti adi tikinti blokudur; dəqiq sintaksis serverin firewall məhsuluna aiddir, poçt tətbiqinə yox.

Tələb «xidmət birbaşa müştərilərə xidmət etməməlidir» olduqda bu, ən güclü sərhəddir. İstifadəçi başqa poçt tətbiqi quraşdırsa belə davam edir, çünki rədd autentifikasiyadan əvvəl baş verir. VPN siyasətini görməzdən gələn Mac-da da işləyir.

Onun həddi də eyni dərəcədə vacibdir. Rədd edilmiş bağlantı xidmətin sessiyanı rədd etdiyini sübut edir; Mac-ın heç cəhd etmədiyini sübut etmir. DNS həlli, əvvəlki yük balanslaşdırıcısına TCP SYN və uğursuzluqdan sonra təkrar cəhd hamısı server qaydasına çatmazdan əvvəl baş verə bilər. Tələb girişdən çox cəhdlərin açıqlanmasına aiddirsə, server qəbulu nəzarətin yalnız yarısıdır.

Müştəri tərəfində icra: yalnız tuneli deyil, cəhdi bloklayın

Müştəri tərəfindəki qayda trafiki qadağan etməlidir, sadəcə poçt açılanda tunel başlatmamalıdır. Poçt domeni üçün aktivləşdirmə tetiqi VPN-i lazımi anda qaldıra bilər, lakin tunel söndürkən və ya uğursuz olduqdan sonra nə baş verdiyini müəyyən etmir.

Son nöqtə məhsulunun dəstəklənən bloklama siyasətindən istifadə edin və əhatəsini qəsdən müəyyənləşdirin. Tətbiq səviyyəsində qayda həmin poçt tətbiqindəki hər hesabı, o cümlədən şəxsi hesabları əhatə edir. Təyinat səviyyəsində qayda iş hesabının IMAP, göndərmə və autentifikasiya son nöqtələrini adlandırmalı və bu ünvanlar dəyişdikdə işləməyə davam etməlidir.

Hər iki ünvan ailəsini və mövcud sessiyaları əhatə edin. Yeni IPv4 bağlantılarını bloklayan, IPv6-nı və ya qurulmuş soketi toxunulmaz qoyan siyasət təsadüfi görünən fasiləli sinxronlaşmalar yaradır. Şəbəkə dəyişiklikləri və yuxu dövrləri eyni testin hissəsidir.

Tətbiq və təyinat səviyyəli qaydaların təsir dairəsi fərqlidir

Tətbiq səviyyəsində blok sadə düşünülür: tunel olmadan Poçtdan heç bir trafik çıxmır. O həm də kobuddur, çünki eyni tətbiqdə siyasətlə heç bir əlaqəsi olmayan şəxsi hesab ola bilər. İstifadəçilər bunu ilk növbədə görür və pozulmuş poçt tətbiqi kimi bildirir.

Təyinat səviyyəsində blok daha dardır və saxlanması çətindir. Hesabın istifadə etdiyi son nöqtələrin tam dəstini, o cümlədən kəşfiyyat və autentifikasiya xidmətlərini və onların yenilənməsi üçün prosesi tələb edir. Birini qaçırın — hesab yarım işləyir; artıq daxil edin — əlaqəsiz poçt dayanır.

Tələbin ifadəsinə görə seçin. «Bu iş hesabı birbaşa qoşulmamalıdır» təyinat əhatəsinə işarə edir. «Bu Mac poçtu VPN-dən kənarda işlətməməlidir» daha geniş tətbiq qaydasını əsaslandırır, bir şərtlə ki, sahib şəxsi hesab yan təsirini qəbul etsin.

Rəddi və olmamasını ayrı-ayrılıqda sınaqdan keçirin

Xüsusi test hesabı ilə VPN vasitəsilə qoşulun və normal işləməni təsdiqləyin. Sonra ayrılın və iki dəfə sınaqdan keçirin: bir dəfə serverin girişi rədd edib-etmədiyini, bir dəfə Mac-ın ümumiyyətlə bağlantı cəhd edib-etmədiyini görmək üçün. Bunlar fərqli müşahidələrdir və fərqli jurnallara aiddir.

Ayrılmış vəziyyətdə SYN və ya DNS sorğusu üçün müştəri tərəfindəki sübutlara, rədd edilmiş və ya qəbul edilmiş sessiya üçün server jurnalına baxın. Server rədd edirsə, amma müştəri hələ də cəhd edirsə, server qaydası işləyir və müştəri qaydası yoxdur. Müştəri heç cəhd etmirsə, amma server başqa müştəriləri hələ də qəbul edirsə, sərhəd tam qoyduğunuz yerdədir.

İcra sahibini, serverin həqiqətən gördüyü mənbə ünvanını və istifadə olunan test hesabını qeyd edin. Növbəti şəbəkə və ya proxy dəyişikliyi bu mənbəni dəyişə bilər və müşahidə olunan dəyəri adlandıran qeyd yeni təxmin raundundan daha tez yoxlanılır.