bilinen sorunlar ve sınırlamalar Azure Güvenlik Duvarı

Bu makalede, Azure Güvenlik Duvarı ile ilgili bilinen sorunlar listelenir. Sorunlar çözüldükçe güncelleştirilir.

Azure Güvenlik Duvarı sınırlamaları için bkz. Azure aboneliği ve hizmet sınırları, kotalar ve kısıtlamalar.

Azure Güvenlik Duvarı Standart

Azure Güvenlik Duvarı Standard'da aşağıdaki bilinen sorunlar vardır:

Not

Standart için geçerli olan her sorun Premium için de geçerlidir.

Sorun Description Risk azaltma
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ı, bugün IP protokolleri için SNAT desteği olmayan Standart Load Balancer kullanır. Gelecek bir sürümde bu senaryoya yönelik seçenekleri araştırı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ı: protokol tanımı gerekir. Bağlantı noktası:protokol değeri olarak https kullanabilirsiniz. FQDN etiketleri kullanıldığında bu alanı 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 bilgileri uyarıları maskelenebilir 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.
Azure Güvenlik Duvarı DNAT, özel IP hedeflerinde çalışmaz Azure Güvenlik Duvarı DNAT desteği İnternet çıkışı/girişi ile sınırlıdır. DNAT şu anda özel IP hedefleri için çalışmıyor. Örneğin, konuşarak uç. Bir düzeltme araştırılıyor.

Özel DNAT şu anda özel önizleme aşamasındadır. Genel önizleme duyurusu için Azure Güvenlik Duvarı önizleme özellikleri makalesini izleyin.
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. Bu tasarım gereğidir.
Gelen bağlantılarda SNAT DNAT'ye ek olarak, güvenlik duvarı genel IP adresi (gelen) üzerinden yapılan bağlantılar güvenlik duvarı özel IP'lerinden birine SNATed edilir. Simetrik yönlendirmeyi sağlamak için bu gereksinim bugün (aynı zamanda Etkin/Etkin NVA'lar için de). HTTP/S için özgün kaynağı korumak için XFF üst bilgilerini kullanmayı göz önünde bulundurun. Örneğin, güvenlik duvarının önünde Azure Front Door veya Azure Uygulaması lication Gateway gibi bir hizmet kullanın. Ayrıca Azure Front Door'un bir parçası olarak WAF ekleyebilir ve güvenlik duvarına zincir ekleyebilirsiniz.
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'dan bağlanıyorsanız varsayılan değer), 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 TCP bağlantı noktası 25'te doğrudan dış etki alanlarına (ve gibi outlook.comgmail.com) gönderilen giden e-posta iletileri Azure platformu tarafından engellenebilir. Bu, Azure'daki varsayılan platform davranışıdır Azure Güvenlik Duvarı daha belirli bir kısıtlamaya neden olmaz. 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'da 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. Şu anda diğer abonelik türlerinde de çalışabilir, ancak çalışması garanti değildir. 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 2496 bağlantı noktasını destekler. Varsayılan olarak iki Sanal Makine Ölçek Kümesi örneği vardır. Bu nedenle, akış başına 4992 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. Bu 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. Bu, kullanılabilir SNAT bağlantı noktalarını beş kat artırır. Aşağı akış izinlerini basitleştirmek için ip adresi ön ekinden ayırın. 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. Bu yaklaşım sanal ağ dağıtımları için desteklenir.

Daha fazla bilgi için bkz. Azure Sanal Ağ NAT ile SNAT bağlantı noktalarını ölçeklendirme.
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. Bu, asimetrik yönlendirme nedeniyle tasarım gereğidir. Gelen bağlantıların dönüş yolu, bağlantının kurulduğunu görmemiş olan şirket içi güvenlik duvarı üzerinden gider.
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, bu durumda 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ı gelen bağlantılar simetrik yönlendirmeyi sağlamak için güvenlik duvarı özel IP adreslerinden birine yönlendirilir. 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. Bu PORT komutu, istemcinin değiştirilmeyecek özel IP'sini kullanır. Azure Güvenlik Duvarı çapraz geçiş yapan istemci tarafı trafiği İnternet tabanlı iletişimler için SıZdır ve FTP sunucusu tarafından PORT komutunun geçersiz olarak görülmesini sağlayabilir. Bu, 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. Bu geçerli bir sınırlamadır.
Yapılandırma güncelleştirmeleri ortalama beş dakika sürebilir Azure Güvenlik Duvarı yapılandırma güncelleştirmesi ortalama üç-beş dakika sürebilir ve paralel güncelleştirmeler desteklenmez. Bir düzeltme araştırılıyor.
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'nin, Azure portalını veya ARM şablonlarını kullanarak etiket eklemenizi engelleyen bir düzeltme eki desteği sınırlaması vardır. Aşağıdaki hata oluşturuldu: Kaynak etiketleri kaydedilemedi. Bir düzeltme araştırılıyor. Alternatif olarak, etiketleri güncelleştirmek için Azure PowerShell cmdlet'ini Set-AzFirewallPolicy de 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.
Birden çok IP Grubunun güncelleştirilmesi çakışma hatasıyla başarısız oluyor. Aynı güvenlik duvarına bağlı iki veya daha fazla IP Grubunu güncelleştirdiğinizde kaynaklardan biri başarısız duruma geçer. Bu bilinen bir sorun/sınırlamadır.

Bir IP Grubunu güncelleştirdiğinizde, IPGroup'un bağlı olduğu tüm güvenlik duvarlarında bir güncelleştirme tetikler. Güvenlik duvarı hala Güncelleştirme durumundayken ikinci bir IP Grubuna güncelleştirme başlatılırsa, IPGroup güncelleştirmesi başarısız olur.

Hatayı önlemek için aynı güvenlik duvarına bağlı IP Gruplarının birer birer güncelleştirilmesi gerekir. Güvenlik duvarının Güncelleştirme durumundan çıkmasını sağlamak için güncelleştirmeler arasında yeterli süre tanıyın.
ARM şablonları kullanılarak RuleCollectionGroups kaldırılma desteklenmiyor. ARM şablonları kullanılarak RuleCollectionGroup'un kaldırılması desteklenmez ve hataya neden olur. Bu desteklenen bir işlem değildir.
Herhangi bir (*) için DNAT kuralı SNAT trafiğine izin verir. BIR DNAT kuralı Kaynak IP adresi olarak (*) izin veriyorsa, örtük bir Ağ kuralı VNet-VNet trafiğiyle eşleşir ve trafiği her zaman SNAT eder. Bu geçerli bir sınırlamadır.
Güvenlik sağlayıcısıyla güvenli bir sanal hub'a DNAT kuralı eklemek desteklenmez. Bu, geri dönen DNAT trafiği için zaman uyumsuz bir yol oluşturur ve bu da güvenlik sağlayıcısına gider. Desteklenmiyor.
2000'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ı). Bu geçerli bir sınırlamadır.
HTTP/S'de XFF üst bilgisi XFF üst bilgilerinin üzerine güvenlik duvarı tarafından görüldüğü gibi özgün kaynak IP adresi yazılır. Bu, aşağıdaki kullanım örnekleri için geçerlidir:
- HTTP istekleri
- TLS sonlandırma ile HTTPS istekleri
Bir düzeltme araştırılıyor.
Yeni oluşturulan Genel IP adresine sahip Kullanılabilirlik Alanları güvenlik duvarı dağıtılamıyor 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.
Azure özel DNS bölgesi, Azure Güvenlik Duvarı ile desteklenmez Azure özel DNS bölgesi, Azure Güvenlik Duvarı DNS ayarlarından bağımsız olarak Azure Güvenlik Duvarı ile çalışmaz. Özel DNS sunucusunu kullanabilmek istiyorsanız Azure özel DNS bölgesi yerine Azure Güvenlik Duvarı DNS ara sunucusu kullanın.
Doğu Japonya'daki fiziksel bölge 2, güvenlik duvarı dağıtımları için kullanılamıyor. Fiziksel bölge 2 ile yeni bir güvenlik duvarı dağıtamazsınız. Ayrıca, fiziksel bölge 2'de dağıtılan mevcut bir güvenlik duvarını durdurursanız, yeniden başlatılamaz. Daha fazla bilgi için bkz . Fiziksel ve mantıksal kullanılabilirlik alanları. Yeni güvenlik duvarları için kalan kullanılabilirlik alanlarıyla 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?.

Azure Güvenlik Duvarı Premium

Azure Güvenlik Duvarı Premium'da aşağıdaki bilinen sorunlar vardır:

Sorun Description 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, bu özelliği 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'i ağ kuralları olarak geçirmeyi yapılandırın.
Güvenilmeyen müşteri imzalı sertifikalar İntranet tabanlı bir web sunucusundan alınan müşteri imzalı sertifikalara güvenlik duvarı tarafından güvenilmez. Bir düzeltme araştırılıyor.
HTTP için IDPS ile Uyarılar'da yanlış kaynak IP adresi (TLS denetimi olmadan). Düz metin HTTP trafiği kullanımda olduğunda ve IDPS yeni bir uyarı verirse ve hedef bir genel IP adresiyse, görüntülenen kaynak IP adresi yanlıştır (özgün IP adresi yerine iç IP adresi görüntülenir). 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.

Sonraki adımlar