Email mencapai server tanpa VPN: di mana aturan harus ditegakkan

Email terus melakukan polling dan VPN mati, tetapi akun tetap tersinkron. Aplikasi melakukan apa yang dikonfigurasi untuknya; tidak ada apa pun di profil email normal yang menyatakan server hanya bisa dijangkau lewat terowongan. Itu menyisakan dua persyaratan berbeda, dan keduanya mudah dicampur: layanan harus menolak klien langsung, atau Mac tidak boleh mencoba sama sekali.

Pilih persyaratannya sebelum memilih produk. Aturan server dan aturan klien gagal di tempat berbeda, menghasilkan bukti berbeda, dan milik pemilik berbeda. Menerapkan keduanya sah bila kedua pernyataan benar, tetapi yang satu bukan pengganti yang lain. Kedua persyaratan itu sah; keduanya saja bukan kontrol yang sama.

Gejalanya tampak seperti Mac, tetapi server bisa menjadi kebocorannya

Saat email tersinkron di luar terowongan, mulailah dari apa yang diterima server. Jika pendengar email menjawab koneksi langsung dari internet, tidak ada pengaturan kenyamanan di sisi klien yang mengubah fakta itu. Mac berperilaku normal terhadap layanan yang masih terbuka.

Tanyakan kepada admin email alamat sumber mana yang dilihat layanan. Gerbang VPN, proksi terbalik, atau penyeimbang beban dapat menerjemahkan alamat klien, jadi kumpulan alamat di konfigurasi VPN mungkin tidak cocok dengan yang tiba di proses email. Aturan yang ditulis terhadap sumber yang salah entah memblokir semua orang atau tidak memblokir siapa pun.

Jawaban itu juga memberi tahu apakah layanan sanggup membedakan klien VPN. Jika setiap klien datang melalui alamat proksi yang sama, penerimaan berbasis sumber tidak dapat memisahkan mereka, dan persyaratannya harus pindah ke autentikasi atau ke sisi klien.

Penerimaan di server: tolak sumbernya, bukan aplikasinya

Firewall host atau jaringan dapat membatasi pendengar email ke rentang sumber yang disetujui sambil membiarkan autentikasi dan TLS tidak berubah. Kondisi aturan yang mencocokkan alamat jauh, subnet, atau rentang adalah blok bangunan yang lazim; sintaksis persisnya milik produk firewall server, bukan aplikasi email.

Ini batas terkuat bila persyaratannya adalah «layanan tidak boleh melayani klien langsung». Ini bertahan bahkan jika pengguna memasang klien email lain, karena penolakan terjadi sebelum autentikasi. Ini juga bertahan pada Mac yang mengabaikan kebijakan VPN-nya.

Batasnya sama pentingnya. Koneksi yang ditolak membuktikan layanan menolak sesi; itu tidak membuktikan Mac tidak mencoba. Resolusi DNS, TCP SYN ke penyeimbang beban sebelumnya, dan percobaan ulang setelah kegagalan semuanya bisa terjadi sebelum aturan server tercapai. Jika persyaratannya tentang pengungkapan percobaan dan bukan akses, penerimaan di server hanya separuh kontrol.

Penegakan di klien: blokir percobaannya, bukan hanya terowongannya

Aturan di sisi klien harus melarang lalu lintas, bukan hanya memulai terowongan saat email dibuka. Pemicu aktivasi untuk domain email dapat menaikkan VPN pada saat yang tepat, tetapi tidak menentukan apa yang terjadi saat terowongan mati atau setelah gagal.

Gunakan kebijakan pemblokiran yang didukung produk titik akhir dan tentukan cakupannya dengan sengaja. Aturan tingkat aplikasi mencakup setiap akun di aplikasi email itu, termasuk akun pribadi. Aturan tingkat tujuan harus menyebut titik akhir IMAP, pengiriman, dan autentikasi akun kerja, dan harus tetap bekerja saat alamat itu berubah.

Cakup kedua keluarga alamat dan sesi yang sudah ada. Kebijakan yang memblokir koneksi IPv4 baru sementara membiarkan IPv6 atau soket yang sudah terbentuk menimbulkan sinkronisasi terputus-putus yang tampak acak. Perubahan jaringan dan siklus tidur adalah bagian dari pengujian yang sama.

Aturan tingkat aplikasi dan tingkat tujuan punya dampak berbeda

Pemblokiran tingkat aplikasi mudah dicerna: tidak ada lalu lintas dari Email yang keluar tanpa terowongan. Ini juga kasar, karena aplikasi yang sama mungkin menyimpan akun pribadi yang tidak ada hubungannya dengan kebijakan. Pengguna menyadarinya lebih dulu dan melaporkannya sebagai aplikasi email rusak.

Pemblokiran tingkat tujuan lebih sempit dan lebih sulit dirawat. Ini membutuhkan seluruh titik akhir yang dipakai akun, termasuk layanan penemuan dan autentikasi, serta proses untuk memperbaruinya. Satu terlewat dan akun bekerja separuh; terlalu banyak dimasukkan dan email tak terkait berhenti.

Pilih menurut rumusan persyaratannya. «Akun kerja ini tidak boleh terhubung langsung» menunjuk cakupan tujuan. «Mac ini tidak boleh menjalankan email di luar VPN» membenarkan aturan aplikasi yang lebih luas, asalkan pemilik menerima efek samping pada akun pribadi.

Uji penolakan dan ketiadaan secara terpisah

Dengan akun uji khusus, hubungkan lewat VPN dan pastikan operasi normal. Lalu putuskan dan uji dua kali: sekali untuk melihat apakah server menolak login, dan sekali untuk melihat apakah Mac mencoba koneksi sama sekali. Itu pengamatan berbeda dan keduanya masuk ke log berbeda.

Perhatikan bukti di sisi klien untuk SYN atau kueri DNS saat terputus, dan log server untuk sesi yang ditolak atau diterima. Jika server menolak tetapi klien masih mencoba, aturan server bekerja dan aturan klien hilang. Jika klien tidak mencoba tetapi server masih menerima klien lain, batasnya persis di tempat yang Anda pasang.

Catat pemilik penegakan, alamat sumber yang benar-benar dilihat server, dan akun uji yang dipakai. Perubahan jaringan atau proksi berikutnya dapat menggeser sumber itu, dan catatan yang menyebut nilai yang teramati lebih cepat diperiksa daripada satu putaran tebakan lagi.