Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Özet
Bu makale, Azure Güvenlik Duvarı ile ilgili bilinen güncel sorunları ve sınırlamaları anlamanıza yardımcı olur. Microsoft, sorunları çözdükçe bu bilgileri güncelleştirir, bu nedenle en son durum için düzenli olarak tekrar kontrol edin.
Azure Güvenlik Duvarı dağıtmadan veya mevcut dağıtımları gidermeden önce, yaygın sorunları önlemek ve uygun geçici çözümleri planlamak için bu bilinen sorunları gözden geçirin.
Azure Güvenlik Duvarı hizmet sınırları için bkz. Azure abonelik ve hizmet sınırları, kotalar ve kısıtlamalar.
Geçerli kapasite kısıtlamaları
Şu anda aşağıdaki bölgelerin kapasite kısıtlamaları vardır:
| Bölge/Bölgeler | SKU | Restrictions | Tavsiye |
|---|---|---|---|
| Doğu ABD 2 EUAPfiziksel bölge 1 ve fiziksel bölge 4 | Temel, Standart ve Premium | - Bölge 1 ve bölge 4'te yeni bir Azure Güvenlik Duvarı dağıtamazsınız. | Kalan kullanılabilirlik alanlarına yeni bir Azure Güvenlik Duvarı dağıtın veya farklı bir bölge kullanın. Mevcut bir güvenlik duvarını yapılandırmak için bkz. Dağıtımdan sonra kullanılabilirlik alanlarını nasıl yapılandırabilirim? |
| - | Standart ve Premium | - Güney Doğu Asya'daki 3. bölgeye veya Kuzey Avrupa'daki 2. bölgeye yeni bir Azure Güvenlik Duvarı dağıtamazsınız.
- Bu bölgelerde dağıtılan mevcut bir Azure Güvenlik Duvarı'nı durdurursanız, yeniden başlatamazsınız. Daha fazla bilgi için bkz . Fiziksel ve mantıksal kullanılabilirlik alanları. |
Kalan kullanılabilirlik alanlarına yeni bir Azure Güvenlik Duvarı dağıtın veya farklı bir bölge kullanın. Mevcut bir güvenlik duvarını yapılandırmak için bkz. Dağıtımdan sonra kullanılabilirlik alanlarını nasıl yapılandırabilirim? |
| Orta Güney ABD'de fiziksel bölge 3 | Temel, Standart ve Premium | - Bölge 3'te yeni bir Azure Güvenlik Duvarı dağıtamazsınız.
Tahmini kullanılabilir tarih: 31 Mart 2026 |
Kalan kullanılabilirlik alanlarına yeni bir Azure Güvenlik Duvarı dağıtın veya farklı bir bölge kullanın. Mevcut bir güvenlik duvarını yapılandırmak için bkz. Dağıtımdan sonra kullanılabilirlik alanlarını nasıl yapılandırabilirim? |
| Orta İspanya'da fiziksel bölge 2 | Temel, Standart ve Premium | - 2. bölgede yeni bir Azure Güvenlik Duvarı dağıtamazsınız.
Tahmini kullanılabilir tarih: 31 Aralık 2026 |
Kalan kullanılabilirlik alanlarına yeni bir Azure Güvenlik Duvarı dağıtın veya farklı bir bölge kullanın. Mevcut bir güvenlik duvarını yapılandırmak için bkz. Dağıtımdan sonra kullanılabilirlik alanlarını nasıl yapılandırabilirim? |
| Fiziksel Bölge 3ABD Gov Virginia'da | Temel ve Standart | - Bölgesel dağıtımlar, ABD Gov Virginia'da fiziksel bölge 3'te engellenir.
- Başarılı bir dağıtım için kullanılabilir alanları manuel olarak seçmeniz gerektiğini ve bunun optimum olmayan bir dağıtım deneyimi yarattığını unutmayın. |
Bölgesel dağıtımlar için 1. ve 2. bölgeleri seçin veya farklı bir bölge kullanın. |
| Batı ABD 2'de fiziksel bölge 2 | Temel, Standart ve Premium | - 2. bölgede yeni bir Azure Güvenlik Duvarı dağıtamazsınız. | Kalan kullanılabilirlik alanlarına yeni bir Azure Güvenlik Duvarı dağıtın veya farklı bir bölge kullanın. Mevcut bir güvenlik duvarını yapılandırmak için bkz. Dağıtımdan sonra kullanılabilirlik alanlarını nasıl yapılandırabilirim? |
| Fiziksel bölge 1, 2, 3Katar Orta | Temel, Standart ve Premium | - Yeni Azure Güvenlik Duvarı dağıtımları engellendi. Tahmini kullanılabilir tarih: 31 Aralık 2026 |
Farklı bir bölgeye yeni bir Azure Güvenlik Duvarı dağıtın. |
| Doğu ABD | Standart | Yeni Azure Güvenlik Duvarı Standart dağıtımlar engellenir. | Farklı bir bölgeye yeni bir Azure Güvenlik Duvarı dağıtın. |
Uyarı
Bu kapasite kısıtlanmış bölgelerden herhangi birinde mevcut Azure Güvenlik Duvarı dağıtımını durdurursanız, devam eden kapasite sınırlamaları nedeniyle yeniden başlatamayabilirsiniz. Bu bölgelerdeki güvenlik duvarı örneklerini durdurmadan önce uygun şekilde planlayın.
Azure Güvenlik Duvarı Standart bilinen sorunlar
Azure Güvenlik Duvarı Standard'da aşağıdaki bilinen sorunlar vardır:
| Sorun | Açıklama | Risk azaltma |
|---|---|---|
| Standart ve Premium sürümlerle sınırlı özel IP adresleri için DNAT desteği | Azure Güvenlik Duvarı özel IP adresinde DNAT desteği, Temel sürümde değil, yalnızca Standart ve Premium Güvenlik Duvarı sürümlerinde kullanılabilir. | Hiçbiri |
| Özel IP DNAT kuralları yapılandırıldığında Azure Güvenlik Duvarı'un serbest bırakılması ve tahsis edilmesi desteklenmez. | Özel DNAT kuralları yapılandırıldığında Azure Güvenlik Duvarı ayırma işlemi başarısız oluyor | 1. Azure Güvenlik Duvarı 2 tahsisini kaldır. Tüm özel IP DNAT kurallarını silin 3. Azure Güvenlik Duvarı ayırın ve özel IP 4 doldurulana kadar bekleyin. Özel IP DNAT kurallarını uygun özel IP adresiyle yeniden yapılandırın |
| TCP/UDP dışı protokollere (örneğin ICMP) yönelik ağ filtreleme kuralları İnternet'e bağlı trafik için çalışmaz | TCP/UDP olmayan protokoller için ağ filtreleme kuralları, genel IP adresinizde SNAT ile çalışmaz. TCP/UDP dışı protokoller, uç alt ağlarla sanal ağlar arasında desteklenir. | Azure Güvenlik Duvarı Standart Load Balancer kullanır Bu gün IP protokolleri için SNAT'yi desteklemez. Gelecek bir sürümde İnternet'e bağlı trafik için TCP/UDP olmayan protokolleri destekleme seçeneklerini araştırıyoruz. |
| Bir Azure Güvenlik Duvarı serbest bırakılıp yeniden ayrıldığında, yeni bir özel IP adresi atanabilir | Azure Güvenlik Duvarı tahsis iptali ve yeniden tahsis işleminden sonra, Azure Güvenlik Duvarı alt ağından dinamik olarak özel bir IP adresi atanır. Öncekinden farklı yeni bir özel IP adresi atandığında, yönlendirme sorunlarına neden olur. | Mevcut Kullanıcı Tanımlı Yolları (UDR) yeni özel IP adresiyle yeniden yapılandırmanız gerekir. Ayırma işleminden sonra özel IP adresini korumak için bir düzeltme araştırılıyor. |
| Alt güvenlik duvarı ilkeleri, DNS ayarlarını üst ilkelerden devralamaz. | Bir üst güvenlik duvarı ilkesinde DNS ayarlarını değiştirdiğinizde, buna bağlı alt ilkeler kendi kurallarındaki etki alanı adlarını çözümleyemeyebilirler. | DNS ayarlarını üst ilkeye bağlı kalmak yerine doğrudan her alt ilkede yapılandırın. DNS ayarlarının devralınmasına izin vermek için bir düzeltme üzerinde çalışıyoruz. |
| ICMP için eksik PowerShell ve CLI desteği | Azure PowerShell ve CLI, ağ kurallarında geçerli bir protokol olarak ICMP'i desteklemez. | ICMP'yi portal ve REST API aracılığıyla protokol olarak kullanmaya devam edebilirsiniz. Yakında PowerShell ve CLI'ya ICMP eklemek için çalışıyoruz. |
| FQDN etiketleri bir protokol: bağlantı noktası ayarlamayı gerektirir | FQDN etiketlerine sahip uygulama kuralları için bağlantı noktası ve protokol tanımı gerekir. | Bağlantı noktası:protokol değeri olarak https kullanabilirsiniz. FQDN etiketleri kullanıldığında bağlantı noktası: protokol alanını isteğe bağlı hale getirmek için çalışıyoruz. |
| Güvenlik duvarını farklı bir kaynak grubuna veya aboneliğe taşıma desteklenmez | Güvenlik duvarını farklı bir kaynak grubuna veya aboneliğe taşıma desteklenmez. | Bu işlevin desteklenmesi yol haritamızda yer alır. Bir güvenlik duvarını başka bir kaynak grubuna veya aboneliğe taşımak için geçerli örneği silmeniz ve yeni kaynak grubunda veya abonelikte yeniden oluşturmanız gerekir. |
| Tehdit istihbarat uyarıları gizlenebilir. | Giden filtreleme için hedef 80/443 olan ağ kuralları, yalnızca uyarı moduna yapılandırıldığında tehdit bilgileri uyarılarını maskeler. | Uygulama kurallarını kullanarak 80/443 için giden filtreleme oluşturun. Alternatif olarak tehdit bilgileri modunu Uyarı ve Reddet olarak da değiştirebilirsiniz. |
| Güvenli sanal hub'lar ile kullanılabilirlik alanları yalnızca dağıtım sırasında yapılandırılabilir. | Güvenli sanal hub'lara sahip bir güvenlik duvarı dağıtıldıktan sonra Kullanılabilirlik Alanları yapılandıramazsınız. | Tasarım gereği. |
| Gelen bağlantılarda SNAT | Gelen DNAT kuralları her zaman dönüş trafiği için kaynak IP adresini değiştirir. | Web trafiğinin özgün istemci IP'sini izlemek için, istemcilerinizi veya ara sunucularınızı özgün IP'yi XFF üst bilgilerine dahil etmek üzere yapılandırın. Azure Güvenlik Duvarı bu IP adreslerini XFF üst bilgisinde korur ve web trafiği kurallarını işlerken Güvenlik Duvarı IP'sini XFF üst bilgisine ekler. |
| SQL FQDN filtreleme desteği yalnızca ara sunucu modunda (bağlantı noktası 1433) | Azure SQL Veritabanı, Azure Synapse Analytics ve Azure SQL Yönetilen Örneği için: SQL FQDN filtrelemesi yalnızca proxy modunda desteklenir (bağlantı noktası 1433). Azure SQL IaaS için: Standart olmayan bağlantı noktaları kullanıyorsanız, bu bağlantı noktalarını uygulama kurallarında belirtebilirsiniz. |
Yeniden yönlendirme modundaki SQL için (Azure içinden bağlanıyorsanız varsayılan ayar), bunun yerine Azure Güvenlik Duvarı ağ kurallarının bir parçası olarak SQL hizmet etiketini kullanarak erişimi filtreleyebilirsiniz. |
| TCP bağlantı noktası 25'te giden SMTP trafiği engellendi | Azure platformu, 25 numaralı TCP bağlantı noktasında doğrudan dış etki alanlarına (outlook.com ve gmail.com gibi) gönderilen giden e-posta iletilerini engeller. 25 numaralı bağlantı noktasında giden SMTP trafiğinin engellenmesi, Azure'daki varsayılan platform davranışıdır. Azure Güvenlik Duvarı daha belirli bir kısıtlama sunmaz. |
Genellikle TCP bağlantı noktası 587 üzerinden bağlanan ancak diğer bağlantı noktalarını da destekleyen kimliği doğrulanmış SMTP geçiş hizmetlerini kullanın. Daha fazla bilgi için bkz. Azure giden SMTP bağlantı sorunlarını giderme. Bir diğer seçenek de standart kurumsal anlaşma (EA) aboneliğinde Azure Güvenlik Duvarı dağıtmaktır. EA aboneliğindeki Azure Güvenlik Duvarı giden TCP bağlantı noktası 25'i kullanarak genel IP adresleriyle iletişim kurabilir. Diğer abonelik türlerinde çalışabilir, ancak garanti edilmeyebilir. Sanal ağlar, VPN'ler ve Azure ExpressRoute gibi özel IP adresleri için Azure Güvenlik Duvarı 25 numaralı TCP bağlantı noktasında giden bağlantıyı destekler. |
| SNAT bağlantı noktası tükenmesi | Azure Güvenlik Duvarı şu anda arka uç Sanal Makine Ölçek Kümesi örneği başına Genel IP adresi başına 2.496 bağlantı noktasını desteklemektedir. Varsayılan olarak, iki Sanal Makine Ölçek Kümesi örneği vardır. Bu nedenle, akış başına 4.992 bağlantı noktası vardır (hedef IP, hedef bağlantı noktası ve protokol (TCP veya UDP)). Güvenlik duvarı en fazla 20 örneğe kadar ölçeklendirilir. | SNAT bağlantı noktası tükenmesi bir platform sınırlamasıdır. SNAT tükenmesine duyarlı dağıtımlar için en az beş genel IP adresiyle Azure Güvenlik Duvarı dağıtımları yapılandırarak sınırları aşabilirsiniz. Daha fazla genel IP adresi eklemek, kullanılabilir SNAT bağlantı noktalarını beş kat artırır. IP adresi ön ekinden tahsis yaparak alt izinleri basitleştirin. Daha kalıcı bir çözüm için, SNAT bağlantı noktası sınırlarını aşmak için bir NAT ağ geçidi dağıtabilirsiniz. NAT ağ geçidi dağıtımı, sanal ağ dağıtımları için desteklenir. Daha fazla bilgi için Azure Sanal Ağ NAT ile SNAT bağlantı noktalarını ölçeklendirme konusuna bkz. |
| Zorlamalı Tünel etkinken DNAT desteklenmez | Zorlamalı Tünel etkin olarak dağıtılan güvenlik duvarları, asimetrik yönlendirme nedeniyle İnternet'ten gelen erişimi destekleyemez. | Zorlamalı Tünel ile DNAT desteğinin olmaması, asimetrik yönlendirme nedeniyle tasarım gereğidir. Gelen bağlantıların dönüş yolu, kurulan bağlantıyı görmeyen şirket içi güvenlik duvarından geçer. |
| Giden Pasif FTP, FTP sunucu yapılandırmanıza bağlı olarak birden çok genel IP adresine sahip güvenlik duvarları için çalışmayabilir. | Pasif FTP, denetim ve veri kanalları için farklı bağlantılar kurar. Birden çok genel IP adresine sahip bir Güvenlik Duvarı giden veri gönderdiğinde, kaynak IP adresi için genel IP adreslerinden birini rastgele seçer. FTP sunucusu yapılandırmanıza bağlı olarak veri ve denetim kanalları farklı kaynak IP adresleri kullandığında FTP başarısız olabilir. | Açık bir SNAT yapılandırması planlanıyor. Bu arada, FTP sunucunuzu farklı kaynak IP adreslerinden veri kabul edecek ve kanalları denetleyecek şekilde yapılandırabilirsiniz (IIS örneğine bakın). Alternatif olarak, FTP bağlantı sorunları yaşarken tek bir IP adresi kullanmayı göz önünde bulundurun. |
| Gelen Pasif FTP, FTP sunucu yapılandırmanıza bağlı olarak çalışmayabilir | Pasif FTP, denetim ve veri kanalları için farklı bağlantılar kurar. Azure Güvenlik Duvarı üzerindeki gelen bağlantılar, simetrik yönlendirmeyi sağlamak için güvenlik duvarının özel IP adreslerinden birine SNAT edilir. FTP sunucusu yapılandırmanıza bağlı olarak veri ve denetim kanalları farklı kaynak IP adresleri kullandığında FTP başarısız olabilir. | Özgün kaynak IP adresinin korunması araştırılıyor. Bu arada, FTP sunucunuzu farklı kaynak IP adreslerinden veri kabul etmek ve kanalları denetlemek için yapılandırabilirsiniz. |
| FTP istemcisinin İnternet üzerinden bir FTP sunucusuna ulaşması gerektiğinde etkin FTP çalışmaz. | Etkin FTP, FTP istemcisinden, FTP sunucusuna veri kanalı için hangi IP ve bağlantı noktasının kullanılacağını yönlendiren bir PORT komutu kullanır. PORT komutu, istemcinin değiştirilmeyecek özel IP'sini kullanır. Azure Güvenlik Duvarı'dan geçen istemci tarafı trafiği, İnternet tabanlı iletişimler için NAT'lenir ve bu da PORT komutunun FTP sunucusu tarafından geçersiz olarak görülmesine neden olur. | Etkin FTP hatası, istemci tarafı NAT ile kullanıldığında Etkin FTP'nin genel bir sınırlamasıdır. |
| NetworkRuleHit ölçümünde protokol boyutu eksik | ApplicationRuleHit ölçümü, filtreleme tabanlı protokole izin verir, ancak ilgili NetworkRuleHit ölçümünde bu özellik eksiktir. | Bir düzeltme araştırılıyor. |
| 64000 ile 65535 arasında bağlantı noktaları olan NAT kuralları desteklenmiyor | Azure Güvenlik Duvarı ağ ve uygulama kurallarında 1-65535 aralığındaki herhangi bir bağlantı noktasına izin verir, ancak NAT kuralları yalnızca 1-63999 aralığındaki bağlantı noktalarını destekler. | NAT kuralı bağlantı noktalarındaki kısıtlama geçerli bir sınırlamadır. |
| Azure Güvenlik Duvarı HTTPS ve MSSQL trafiğini filtrelemek için SNI TLS üst bilgilerini kullanır | Tarayıcı veya sunucu yazılımı Sunucu Adı Göstergesi (SNI) uzantısını desteklemiyorsa Azure Güvenlik Duvarı üzerinden bağlanamazsınız. | Tarayıcı veya sunucu yazılımı SNI'yi desteklemiyorsa, bağlantıyı uygulama kuralı yerine bir ağ kuralı kullanarak denetleyebilirsiniz. SNI'yi destekleyen yazılımlar için bkz. Sunucu Adı Belirtme. |
| Portal veya Azure Resource Manager (ARM) şablonları kullanılarak güvenlik duvarı ilkesi etiketleri eklenemez | Azure Güvenlik Duvarı İlkesi,Azure portalını veya ARM şablonlarını kullanarak etiket eklemenizi engelleyen bir düzeltme eki desteği sınırlaması içerir. Aşağıdaki hata oluşturuldu: Kaynak etiketleri kaydedilemedi. | Bir düzeltme araştırılıyor. Veya etiketleri güncelleştirmek için Azure PowerShell cmdlet'ini Set-AzFirewallPolicy kullanabilirsiniz. |
| IPv6 şu anda desteklenmiyor | Bir kurala IPv6 adresi eklerseniz güvenlik duvarı başarısız olur. | Yalnızca IPv4 adreslerini kullanın. IPv6 desteği araştırılıyor. |
| ARM şablonları ile RuleCollectionGroups kaldırma işlemi desteklenmiyor. | ARM şablonları kullanılarak RuleCollectionGroup'un kaldırılması desteklenmez ve hataya neden olur. | RULECollectionGroups'un ARM şablonları kullanılarak kaldırılması desteklenen bir işlem değildir. |
| Herhangi bir (*) için DNAT kuralı SNAT trafiğine izin verir. | Bir DNAT kuralı herhangi bir IP adresini (*) Kaynak IP adresi olarak kabul ediyorsa, örtük bir Ağ kuralı VNet-VNet trafiğini eşleştirir ve trafiği her zaman SNAT eder. | Herhangi bir kaynakta DNAT kuralları için otomatik SNAT davranışı geçerli bir sınırlamadır. |
| Güvenlik sağlayıcısıyla güvenli bir sanal hub'a DNAT kuralı eklemek desteklenmez. | Güvenlik sağlayıcısıyla güvenli bir sanal hub'a DNAT kuralı eklediğinizde, bu, güvenlik sağlayıcısına giden, geri dönen DNAT trafiği için zaman uyumsuz bir yol oluşturur. | Desteklenmiyor. |
| 2.000'den fazla kural koleksiyonu oluşturulurken hatayla karşılaşıldı. | NAT/Uygulama veya Ağ kuralı koleksiyonlarının en fazla sayısı 2000'dir (Resource Manager sınır). | 2.000 kural koleksiyonu sınırı geçerli bir sınırlamadır. |
| Yeni oluşturulmuş Genel IP adresiyle Elverişlilik Bölgeleri içeren bir Güvenlik Duvarı dağıtmak mümkün değil. | Kullanılabilirlik Alanları ile bir Güvenlik Duvarı dağıttığınızda, yeni oluşturulan genel IP adresini kullanamazsınız. | Önce yeni bir alanlar arası yedekli Genel IP adresi oluşturun, ardından güvenlik duvarı dağıtımı sırasında daha önce oluşturulmuş bu IP adresini atayın. |
| Bir Genel IP adresini Azure Güvenlik Duvarı ile ilişkilendirmek, kiracılar arası bir senaryoda desteklenmez. | A kiracısında Genel IP adresi oluşturursanız, bunu B kiracısında dağıtılan bir güvenlik duvarıyla ilişkilendiremezsiniz. | Yok. |
| Azure Güvenlik Duvarı arkasındaki VM'ler güvenlik duvarının genel IP'sini kullanarak DNAT kuralı hedeflerine bağlanamıyor | VM'ler trafiği Azure Güvenlik Duvarı üzerinden yönlendirdiğinde ve güvenlik duvarının genel IP adresini kullanarak DNAT kurallarıyla yapılandırılan kaynaklara bağlanmaya çalıştığında bağlantı başarısız olur. bağlantı hatası, Azure Güvenlik Duvarı iç VM'lerden DNAT kuralı hedefleri için güvenlik duvarının kendi genel IP adresine trafik sabitlemeyi desteklemediğinden oluşur. | Bu sınırlamaya yönelik bir çözüm şu anda geliştirme aşamasındadır. |
| Azure VM'lerden şirket içi Azure Güvenlik Duvarı Standart aracılığıyla işletim sistemi yerel IPsec trafiğini yönlendirme sırasında karşılaşılan bağlantı sorunları | Bazı karma dağıtımlarda, Azure sanal makineler şirket içi ağlara bağlanmak için işletim sistemi yerel IPsec tünellerini kullanır. Bu trafik Azure Güvenlik Duvarı Standard üzerinden yönlendirildiğinde (özellikle VPN Gateway veya Genel Sanal Ağ Eşlemesi ile), bağlantı sorunlarına neden olan çift kapsülleme senaryoları (örneğin, genel sanal ağ eşlemesi tarafından sunulan ek kapsülleme) nedeniyle IPsec paketleri başarısız olabilir. | Azure sanal makinelerden gelen işletim sistemi yerel IPsec trafiğini Azure Güvenlik Duvarı Standard üzerinden yönlendirmekten kaçının. Bu sınırlamaya yönelik bir çözüm şu anda geliştirme aşamasındadır. |
| Yönetim işlemleri günlüklerde görünür DNS sorguları oluşturur | Azure Güvenlik Duvarı, normal yönetim ve platform işlemlerinin (yapılandırma güncelleştirmeleri, telemetri ve hizmet bağlantısı gibi) bir parçası olarak iç DNS aramaları gerçekleştirir. Bu DNS sorguları müşteri trafiği tarafından başlatılmasa bile müşteri Azure DNS günlüklerinde veya güvenlik izleme araçlarında görüntülenebilir. | Bu davranış beklenir ve yanlış yapılandırma veya güvenlik sorununa işaret etmez. Gerekirse DNS izleme ilkelerindeki bilinen Microsoft hizmet etki alanlarını filtreleyin veya hariç tutun. |
| Taslak + Dağıtım işlemlerinden sonra İlke Analizi yapılandırması kaldırılır | bir İlke Analizi yapılandırması varsa, Taslak + Dağıtım kullanan tüm güncelleştirmeler (Kural veya Ayarlar gibi) İlke Analizi yapılandırmasını kaldırır. Bu, Azure Premium Güvenlik Duvarı için de geçerlidir. | Bir düzeltme araştırılıyor. |
| Ölçeği genişletme sırasında ağ kuralları için aralıklı trafik kaybı ve beklenmeyen reddetme günlükleri. | Yatay ölçeklendirme sırasında, yeni eklenen güvenlik duvarı örneklerinde, ağ kurallarında açıkça izin verilmiş olsa bile trafik kısa süreliğine kesilebilir ve beklenmedik engelleme olayları günlüğe kaydedilebilir. Bu davranış, ağ kurallarında 1.000'den fazla FQDN yapılandırıldığında veya yukarı akış DNS sunucusu yavaş yanıtladığında oluşur. | Sorun birkaç saniye içinde otomatik olarak azaltılmış olur. Etkiyi azaltmak için güvenlik duvarını beklenen aktarım hızınıza göre önceden ölçekleyin ve bakım olaylarının iş saatlerinde gerçekleşmemesi için bir bakım penceresi yapılandırın. Kalıcı bir düzeltme araştırılıyor. |
Azure Güvenlik Duvarı Premium bilinen sorunları
Uyarı
Standart için geçerli olan her sorun Premium için de geçerlidir.
Azure Güvenlik Duvarı Premium'da aşağıdaki bilinen sorunlar vardır:
| Sorun | Açıklama | Risk azaltma |
|---|---|---|
| HTTPS'de FQDN çözünürlüğü için ESNI desteği | Şifrelenmiş SNI, HTTPS el sıkışmasında desteklenmez. | Bugün özel yapılandırma aracılığıyla yalnızca Firefox ESNI'i destekler. Önerilen geçici çözüm, ESNI özelliğini devre dışı bırakmaktır. |
| İstemci Sertifikası Kimlik Doğrulaması desteklenmiyor | İstemci sertifikaları, istemci ile sunucu arasında karşılıklı kimlik güveni oluşturmak için kullanılır. İstemci sertifikaları bir TLS anlaşması sırasında kullanılır. Azure güvenlik duvarı sunucuyla bir bağlantıyı yeniden dener ve istemci sertifikalarının özel anahtarına erişimi yoktur. | Hiçbiri |
| QUIC/HTTP3 | QUIC, HTTP'nin yeni ana sürümüdür. 80 (PLAN) ve 443 (SSL) üzerinde UDP tabanlı bir protokol. FQDN/URL/TLS denetimi desteklenmez. | UDP 80/443'ün ağ kuralları olarak iletilmesini yapılandırın. |
| Güvenilmeyen müşteri imzalı sertifikalar | Güvenlik duvarı, intranet tabanlı bir web sunucusundan aldığında müşteri tarafından imzalanan sertifikalara güvenmez. | Bir düzeltme araştırılıyor. |
| IDPS, TLS denetimi olmadan HTTP uyarıları için yanlış kaynak IP adresi görüntüler | IDPS, genel IP adreslerine düz metin HTTP trafiği için uyarılar oluşturduğunda, özgün kaynak IP adresi yerine iç IP adresini görüntüler. | Bir düzeltme araştırılıyor. |
| Sertifika Yayma | Güvenlik duvarına bir CA sertifikası uygulandıktan sonra sertifikanın geçerlilik kazanması 5-10 dakika arasında sürebilir. | Bir düzeltme araştırılıyor. |
| TLS 1.3 desteği | TLS 1.3 kısmen desteklenir. İstemciden güvenlik duvarına TLS tüneli TLS 1.2'yi temel alır ve güvenlik duvarından dış Web sunucusuna TLS 1.3'e dayanır. | Güncelleştirmeler araştırılıyor. |
| TLSi ara CA sertifikası süre sonu | Bazı benzersiz durumlarda, ara CA sertifikasının süresi özgün son kullanma tarihinden iki ay önce dolabilir. | Ara CA sertifikasını özgün son kullanma tarihinden iki ay önce yenileyin. Bir düzeltme araştırılıyor. |
| Otomatik olarak imzalanan sertifikalar otomatik yenilemeyi desteklemiyor | TLS denetimi için otomatik olarak imzalanan sertifikalar kullanıldığında otomatik yenileme işlemleri başarısız olur. Bu sınırlama, güvenlik duvarı ilkesinde otomatik yenilemenin yapılandırıldığı sertifika döndürme senaryolarını etkiler. | Otomatik yenileme desteği için güvenilen bir Sertifika Yetkilisi (CA) tarafından verilen bir sertifika kullanın. |
| Otomatik olarak imzalanan sertifikaları değiştirmek için TLS incelemesini devre dışı bırakmanız gerekir | Azure portalı, güvenlik duvarı ilkesiyle zaten ilişkili olan yeni bir otomatik olarak imzalanan sertifika oluşturulmasına izin vermez. Bu sınırlama, otomatik olarak imzalanan sertifikaları döndürmeniz veya güncelleştirmeniz gereken senaryoları etkiler. | TLS incelemesini devre dışı bırakın, sonra yeniden etkinleştirin ve yeni sertifikayı oluşturun. |
| Azure VM'lerden şirket içi Azure Güvenlik Duvarı Premium aracılığıyla işletim sistemi yerel IPsec trafiğini yönlendirirken karşılaşılan bağlantı sorunları | Bazı karma dağıtımlarda, Azure sanal makineler şirket içi ağlara bağlanmak için işletim sistemi yerel IPsec tünellerini kullanır. Bu trafik, özellikle VPN Gateway veya Genel Sanal Ağ Eşlemesi söz konusu olduğunda Azure Güvenlik Duvarı Standard üzerinden yönlendirildiğinde, IPsec paketleri güvenlik duvarından geçemeyebilir ve bu da bağlantı sorunlarına neden olabilir. | Azure sanal makinelerden gelen işletim sistemi yerel IPsec trafiğini Azure Güvenlik Duvarı Premium üzerinden yönlendirmekten kaçının. Bu sınırlamaya yönelik bir çözüm şu anda geliştirme aşamasındadır. |