Posta VPN olmadan sunucuya ulaşıyor: kural nerede uygulanmalı

Posta sormaya devam ediyor ve VPN kapalı, ama hesap hâlâ eşitleniyor. Uygulama yapılandırıldığı işi yapıyor; normal bir posta profilinde sunucuya yalnızca tünelden ulaşılabildiği yazmıyor. Bu, birbirine karıştırılması kolay iki farklı gereksinim bırakıyor: hizmet doğrudan istemcileri reddetmeli ya da Mac hiç denememeli.

Ürün seçmeden önce gereksinimi seçin. Sunucu kuralı ve istemci kuralı farklı yerlerde başarısız olur, farklı kanıtlar üretir ve farklı sahiplere aittir. İkisini birden uygulamak, iki ifade de doğruysa geçerlidir, ama biri diğerinin yerini tutmaz. İki gereksinim de meşrudur; sadece aynı kontrol değildir.

Belirti Mac gibi görünüyor, ama sızıntı sunucuda olabilir

Posta tünelin dışında eşitlendiğinde, sunucunun neyi kabul ettiğinden başlayın. Posta dinleyicisi internetten gelen doğrudan bağlantıya yanıt veriyorsa, istemci tarafındaki hiçbir kolaylık ayarı bu gerçeği değiştirmez. Mac, hâlâ açık olan bir hizmete karşı normal davranıyor.

Posta yöneticisine hizmetin hangi kaynak adresini gördüğünü sorun. Bir VPN geçidi, ters vekil sunucu veya yük dengeleyici istemci adresini çevirebilir, bu yüzden VPN yapılandırmasındaki adres havuzu posta sürecine ulaşanla eşleşmeyebilir. Yanlış kaynağa karşı yazılmış bir kural ya herkesi engeller ya da kimseyi.

Bu yanıt, hizmetin VPN istemcilerini hiç ayırt edip edemediğini de söyler. Her istemci aynı vekil adresten geliyorsa, kaynağa dayalı kabul onları ayıramaz ve gereksinim kimlik doğrulamaya ya da istemci tarafına taşınmalıdır.

Sunucuda kabul: uygulamayı değil, kaynağı reddedin

Bir ana makine veya ağ güvenlik duvarı, kimlik doğrulama ve TLS’yi değiştirmeden posta dinleyicisini onaylı kaynak aralıklarıyla sınırlayabilir. Uzak adresler, alt ağlar veya aralıklarla eşleşen kural koşulu olağan yapı taşıdır; tam sözdizimi sunucunun güvenlik duvarı ürününe aittir, posta uygulamasına değil.

Gereksinim «hizmet doğrudan istemcilere hizmet vermemeli» olduğunda en güçlü sınır budur. Kullanıcı başka bir posta istemcisi kursa bile dayanır, çünkü ret kimlik doğrulamadan önce gerçekleşir. VPN politikasını yok sayan bir Mac’e de dayanır.

Sınırı da aynı ölçüde önemlidir. Reddedilen bağlantı, hizmetin oturumu reddettiğini kanıtlar; Mac’in hiç denemediğini kanıtlamaz. DNS çözümlemesi, önceki bir yük dengeleyiciye TCP SYN ve hatadan sonra yeniden deneme, sunucu kuralına ulaşılmadan önce gerçekleşebilir. Gereksinim erişim değil de denemelerin açığa çıkmasıyla ilgiliyse, sunucuda kabul kontrolün yalnızca yarısıdır.

İstemcide uygulama: yalnızca tüneli değil, denemeyi engelleyin

İstemci tarafındaki kural trafiği yasaklamalı, yalnızca posta açıldığında tünel başlatmamalı. Bir posta alanı için etkinleştirme tetikleyicisi VPN’i doğru anda kaldırabilir, ama tünel kapalıyken ya da başarısız olduktan sonra ne olacağını tanımlamaz.

Uç nokta ürününün desteklediği engelleme politikasını kullanın ve kapsamını bilinçli olarak belirleyin. Uygulama düzeyindeki kural o posta uygulamasındaki her hesabı kapsar, kişisel olanlar dahil. Hedef düzeyindeki kural iş hesabının IMAP, gönderim ve kimlik doğrulama uç noktalarını adlandırmalı ve bu adresler değiştiğinde çalışmaya devam etmelidir.

Her iki adres ailesini ve mevcut oturumları kapsayın. Yeni IPv4 bağlantılarını engelleyip IPv6’yı ya da kurulmuş bir soketi rahat bırakan politika, rastgele görünen aralıklı eşitlemeler üretir. Ağ değişiklikleri ve uyku döngüleri aynı testin parçasıdır.

Uygulama ve hedef düzeyindeki kuralların etki kapsamı farklıdır

Uygulama düzeyindeki engellemeyi düşünmek kolaydır: tünel olmadan Posta’dan hiçbir trafik çıkmaz. Aynı zamanda kabadır, çünkü aynı uygulamada politikayla ilgisi olmayan kişisel bir hesap bulunabilir. Kullanıcılar bunu ilk fark eder ve bozuk posta uygulaması olarak bildirir.

Hedef düzeyindeki engelleme daha dardır ve bakımı daha zordur. Hesabın kullandığı uç noktaların tamamına, keşif ve kimlik doğrulama hizmetleri dahil, ve bunları güncelleme sürecine ihtiyaç duyar. Bir tanesi eksik olursa hesap yarım çalışır; fazla dahil ederseniz ilgisiz posta durur.

Gereksinimin ifadesine göre seçin. «Bu iş hesabı doğrudan bağlanmamalı» hedef kapsamına işaret eder. «Bu Mac VPN dışında posta çalıştırmamalı» daha geniş uygulama kuralını gerekçelendirir, sahibi kişisel hesaptaki yan etkiyi kabul ederse.

Ret ve yokluğu ayrı ayrı test edin

Özel bir test hesabıyla VPN üzerinden bağlanın ve normal çalışmayı doğrulayın. Sonra bağlantıyı kesin ve iki kez test edin: bir kez sunucunun oturum açmayı reddedip etmediğini, bir kez Mac’in herhangi bir bağlantı deneyip denemediğini görmek için. Bunlar farklı gözlemlerdir ve farklı günlüklere aittir.

Bağlantı kesikken SYN veya DNS sorgusu için istemci tarafındaki kanıtlara, reddedilen veya kabul edilen oturum için sunucu günlüğüne bakın. Sunucu reddediyor ama istemci hâlâ deniyorsa, sunucu kuralı çalışıyor ve istemci kuralı eksik. İstemci hiç denemiyor ama sunucu başka istemcileri kabul ediyorsa, sınır tam olarak koyduğunuz yerdedir.

Uygulamanın sahibini, sunucunun gerçekten gördüğü kaynak adresi ve kullanılan test hesabını kaydedin. Sonraki ağ veya vekil değişikliği o kaynağı kaydırabilir; gözlenen değeri adlandıran bir not, bir tur daha tahmin etmekten daha hızlı denetlenir.