E-mel sampai ke pelayan tanpa VPN: di mana peraturan perlu dikuatkuasakan

E-mel terus bertanya dan VPN mati, namun akaun masih disegerakkan. Aplikasi melakukan apa yang dikonfigurasikan; tiada apa dalam profil mel biasa yang mengatakan pelayan hanya boleh dicapai melalui terowong. Itu meninggalkan dua keperluan berbeza, dan mudah dikelirukan: perkhidmatan harus menolak klien terus, atau Mac tidak sepatutnya mencuba sama sekali.

Pilih keperluan sebelum memilih produk. Peraturan pelayan dan peraturan klien gagal di tempat berbeza, menghasilkan bukti berbeza dan dimiliki oleh pemilik berbeza. Menggunakan kedua-duanya sah apabila kedua-dua kenyataan benar, tetapi satu bukan pengganti yang lain. Kedua-dua keperluan itu sah; ia cuma bukan kawalan yang sama.

Gejalanya kelihatan seperti Mac, tetapi pelayan mungkin punca kebocoran

Apabila e-mel disegerakkan di luar terowong, mulakan dengan apa yang pelayan terima. Jika pendengar mel menjawab sambungan terus dari internet, tiada tetapan kemudahan di pihak klien mengubah fakta itu. Mac berkelakuan normal terhadap perkhidmatan yang masih terbuka.

Tanya pentadbir mel alamat sumber mana yang dilihat oleh perkhidmatan. Gerbang VPN, proksi songsang atau pengimbang beban boleh menterjemah alamat klien, jadi kumpulan alamat dalam konfigurasi VPN mungkin tidak sepadan dengan apa yang tiba di proses mel. Peraturan yang ditulis terhadap sumber yang salah sama ada menyekat semua orang atau tidak menyekat sesiapa.

Jawapan itu juga memberitahu sama ada perkhidmatan boleh membezakan klien VPN sama sekali. Jika setiap klien tiba melalui alamat proksi yang sama, kemasukan berasaskan sumber tidak dapat memisahkan mereka, dan keperluan itu mesti beralih kepada pengesahan atau ke pihak klien.

Kemasukan di pelayan: tolak sumber, bukan aplikasi

Tembok api hos atau rangkaian boleh mengehadkan pendengar mel kepada julat sumber yang diluluskan sambil membiarkan pengesahan dan TLS tidak berubah. Syarat peraturan yang sepadan dengan alamat jauh, subrangkaian atau julat ialah blok binaan biasa; sintaks tepat milik produk tembok api pelayan, bukan aplikasi mel.

Ini sempadan paling kukuh apabila keperluannya ialah «perkhidmatan tidak boleh melayani klien terus». Ia kekal walaupun pengguna memasang klien mel lain, kerana penolakan berlaku sebelum pengesahan. Ia juga bertahan dengan Mac yang mengabaikan dasar VPNnya.

Hadnya sama penting. Sambungan yang ditolak membuktikan perkhidmatan menolak sesi; ia tidak membuktikan Mac tidak mencuba. Penyelesaian DNS, TCP SYN ke pengimbang beban terdahulu dan cubaan semula selepas kegagalan semuanya boleh berlaku sebelum peraturan pelayan dicapai. Jika keperluan itu tentang pendedahan cubaan dan bukan akses, kemasukan di pelayan hanyalah separuh kawalan.

Penguatkuasaan di klien: sekat cubaan, bukan hanya terowong

Peraturan di pihak klien mesti melarang trafik, bukan sekadar memulakan terowong apabila mel dibuka. Pencetus pengaktifan untuk domain mel boleh menaikkan VPN pada masa yang tepat, tetapi ia tidak menentukan apa yang berlaku semasa terowong mati atau selepas ia gagal.

Gunakan dasar penyekatan yang disokong produk titik akhir dan tetapkan skopnya dengan sengaja. Peraturan peringkat aplikasi meliputi setiap akaun dalam aplikasi mel itu, termasuk akaun peribadi. Peraturan peringkat destinasi mesti menamakan titik akhir IMAP, penghantaran dan pengesahan akaun kerja, dan ia mesti terus berfungsi apabila alamat itu berubah.

Liputi kedua-dua keluarga alamat dan sesi sedia ada. Dasar yang menyekat sambungan IPv4 baharu sambil membiarkan IPv6 atau soket yang sudah terbentuk menghasilkan penyegerakan berselang-seli yang kelihatan rawak. Perubahan rangkaian dan kitaran tidur adalah sebahagian daripada ujian yang sama.

Peraturan peringkat aplikasi dan destinasi mempunyai skop kesan berbeza

Penyekatan peringkat aplikasi mudah difikirkan: tiada trafik dari E-mel keluar tanpa terowong. Ia juga kasar, kerana aplikasi yang sama mungkin menyimpan akaun peribadi yang tiada kaitan dengan dasar itu. Pengguna menyedarinya dahulu dan melaporkannya sebagai aplikasi mel yang rosak.

Penyekatan peringkat destinasi lebih sempit dan lebih sukar diselenggara. Ia memerlukan set lengkap titik akhir yang digunakan akaun, termasuk perkhidmatan penemuan dan pengesahan, serta proses untuk mengemas kininya. Satu tertinggal dan akaun bekerja separuh; terlalu banyak dimasukkan dan mel tidak berkaitan terhenti.

Pilih mengikut rumusan keperluan. «Akaun kerja ini tidak boleh bersambung terus» menunjuk kepada skop destinasi. «Mac ini tidak boleh menjalankan mel di luar VPN» mewajarkan peraturan aplikasi yang lebih luas, dengan syarat pemilik menerima kesan sampingan pada akaun peribadi.

Uji penolakan dan ketiadaan secara berasingan

Dengan akaun ujian khusus, sambung melalui VPN dan sahkan operasi normal. Kemudian putuskan sambungan dan uji dua kali: sekali untuk melihat sama ada pelayan menolak log masuk, dan sekali untuk melihat sama ada Mac mencuba sambungan sama sekali. Itu pemerhatian berbeza dan kedua-duanya masuk ke log berbeza.

Perhatikan bukti di pihak klien untuk SYN atau pertanyaan DNS semasa terputus, dan log pelayan untuk sesi yang ditolak atau diterima. Jika pelayan menolak tetapi klien masih mencuba, peraturan pelayan berfungsi dan peraturan klien tiada. Jika klien tidak mencuba tetapi pelayan masih menerima klien lain, sempadan itu tepat di tempat anda meletakkannya.

Catat pemilik penguatkuasaan, alamat sumber yang benar-benar dilihat pelayan dan akaun ujian yang digunakan. Perubahan rangkaian atau proksi seterusnya boleh mengalihkan sumber itu, dan nota yang menamakan nilai yang diperhatikan lebih cepat diperiksa daripada satu lagi pusingan tekaan.