bilinen sorunlar ve sınırlamalar Azure Güvenlik Duvarı
Bu makalede, Azure Güvenlik Duvarı için bilinen sorunlar listelenir ve çözümlendikç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.
Önemli
Kapasite kısıtlamaları
Aşağıdaki bölgelerde şu anda hem Standart hem de Premium SKU'lar için kapasite kısıtlamaları yaşanıyor:
| Bölgeler | Kısıtlamalar | Öneri |
|---|---|---|
|
-
Kuzey Avrupa'da - fiziksel bölge 2 Güney Doğu Asya'da fiziksel bölge 3 |
- 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ölgede dağıtılan mevcut bir Azure Güvenlik Duvarı durdurursanız, yeniden başlatılamaz. 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ğıtmanızı veya farklı bir bölge kullanmanızı öneririz. 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ı Standart
Azure Güvenlik Duvarı Standard'da aşağıdaki bilinen sorunlar vardır:
| Sorun | Description | 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 kuruluşlara yöneliktir, bu nedenle Standart ve Premium Güvenlik Duvarı sürümleriyle sınırlıdır. | Hiçbiri |
| 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. |
| 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 | Azure platformu, 25 numaralı TCP bağlantı noktasındaki dış etki alanlarına (ve gibi outlook.comgmail.com) doğrudan gönderilen giden e-posta iletilerini engeller. Bu, 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'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. Diğer abonelik türlerinde çalışabilir, ancak 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 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. | 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. |
| 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. |
| 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ı). | 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 Güvenlik Duvarı Premium
Not
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 | 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. |