Az Azure Firewall ismert problémái és korlátozásai
Ez a cikk felsorolja az Azure Firewall ismert problémáit, és azok megoldásakor frissül.
Az Azure Firewall korlátozásaiért tekintse meg az Azure előfizetési és szolgáltatási korlátait, kvótáit és korlátozásait.
Fontos
Kapacitáskorlátozások
A következő zónákban jelenleg kapacitáskorlátozások lépnek fel mind a Standard, mind a Prémium termékváltozatok esetében:
| Zóna | Korlátozások | Ajánlás |
|---|---|---|
|
-
2. fizikai zóna Észak-Európában- – 3. fizikai zóna Délkelet-Ázsiában |
– Nem helyezhet üzembe új Azure Firewallt a 3. zónában Délkelet-Ázsiában vagy a 2. zónában Észak-Európában.
– Ha leállítja a zónában üzembe helyezett meglévő Azure Firewallt, az nem indítható újra. További információ: Fizikai és logikai rendelkezésre állási zónák. |
Javasoljuk, hogy helyezzen üzembe egy új Azure Firewallt a fennmaradó rendelkezésre állási zónákban, vagy használjon másik régiót. Meglévő tűzfal konfigurálásához lásd : Hogyan konfigurálhatom a rendelkezésre állási zónákat az üzembe helyezés után? |
Azure Firewall Standard
Az Azure Firewall Standard az alábbi ismert problémákat tapasztalja:
| Probléma | Leírás | Kezelés |
|---|---|---|
| DNST-támogatás standard és prémium verzióra korlátozott magánhálózati IP-címekhez | Az Azure Firewall privát IP-címének DNST-támogatása nagyvállalatoknak szól, így a Standard és a Premium Firewall verziókra korlátozódik. | Egyik sem |
| A nem TCP/UDP-protokollokra (például ICMP) vonatkozó hálózati szűrési szabályok nem működnek az internetre irányuló forgalom esetében | A nem TCP/UDP protokollok hálózati szűrési szabályai nem működnek az SNAT-val a nyilvános IP-címre. A nem TCP/UDP-protokollok a küllők alhálózatai és a virtuális hálózatok között támogatottak. | Az Azure Firewall a Standard Load Balancert használja, amely jelenleg nem támogatja a forráshálózati címfordítást az IP-protokollokon. A forgatókönyv későbbi kiadásban való támogatásának lehetőségeit vizsgáljuk. |
| A PowerShell és a CLI nem támogatja az ICMP-t | Az Azure PowerShell és a CLI nem támogatja az ICMP-t érvényes protokollként a hálózati szabályokban. | Az ICMP protokollként továbbra is használható a portálon és a REST API-on keresztül. Dolgozunk azon, hogy hamarosan hozzáadjuk az ICMP-t a PowerShellben és a PARANCSSOR-ban. |
| Az FQDN-címkék protokoll: port megadását igénylik | Az FQDN-címkékkel rendelkező alkalmazásszabályokhoz port: protokolldefiníció szükséges. | A port:protokoll értékként használhat https-t. Dolgozunk azon, hogy ezt a mezőt a teljes tartománynév címkéinek használata esetén opcionálissá tegyük. |
| Tűzfal áthelyezése másik erőforráscsoportba vagy előfizetésbe nem támogatott | A tűzfal áthelyezése másik erőforráscsoportba vagy előfizetésbe nem támogatott. | Ennek a funkciónak a támogatása az ütemtervünkben található. Ahhoz, hogy egy tűzfalat áthelyezzen másik erőforráscsoportba vagy előfizetésbe, először törölnie kell az aktuális példányt, és újra létre kell hoznia az új erőforráscsoportban vagy előfizetésben. |
| A fenyegetésintelligencia-riasztások maszkolást kaphatnak | A 80/443-at célként szolgáló hálózati szabályok a kimenő szűrési maszkok fenyegetésintelligencia-riasztásaira, ha csak riasztási módra vannak konfigurálva. | Hozzon létre kimenő szűrést a 80/443-hoz alkalmazásszabályok használatával. Vagy módosítsa a fenyegetésfelderítési módot riasztásra és elutasításra. |
| Biztonságos virtuális központok esetén a rendelkezésre állási zónák csak az üzembe helyezés során konfigurálhatók. | A rendelkezésre állási zónák nem konfigurálhatók a biztonságos virtuális központokkal rendelkező tűzfal üzembe helyezése után. | Ez az elvárt működés. |
| SNAT bejövő kapcsolatokon | A DNST mellett a tűzfal nyilvános IP-címén (bejövő) keresztüli kapcsolatok az egyik tűzfal magánhálózati IP-címére vannak SNATedítve. Ez a követelmény (az aktív/aktív NVA-k esetében is) a szimmetrikus útválasztás biztosításához. | A HTTP/S eredeti forrásának megőrzéséhez fontolja meg az XFF-fejlécek használatát. Például használjon olyan szolgáltatást, mint az Azure Front Door vagy Azure-alkalmazás Gateway a tűzfal előtt. A WAF-et az Azure Front Door részeként és a tűzfalhoz láncként is hozzáadhatja. |
| Az SQL teljes tartománynév szűrésének támogatása csak proxy módban (1433-es port) | Azure SQL Database, Azure Synapse Analytics és felügyelt Azure SQL-példány esetén: Az SQL FQDN-szűrés csak proxy módban támogatott (1433-es port). Azure SQL IaaS esetén: Ha nem szabványos portokat használ, az alkalmazásszabályokban megadhatja ezeket a portokat. |
Átirányítási módban futó SQL esetén (ha az Azure-ból csatlakozik az alapértelmezett), az Azure Firewall hálózati szabályainak részeként szűrheti a hozzáférést az SQL szolgáltatáscímkéje alapján. |
| A 25-ös TCP-port kimenő SMTP-forgalma le van tiltva | Az Azure platform letiltja a 25-ös TCP-porton közvetlenül külső tartományoknak (például outlook.com és gmail.com) küldött kimenő e-maileket. Ez az Alapértelmezett platform viselkedés az Azure-ban. Az Azure Firewall nem vezet be további korlátozásokat. |
Hitelesített SMTP-továbbítási szolgáltatásokat használjon, amelyek általában az 587-ös TCP-porton keresztül csatlakoznak, de más portokat is támogatnak. További információ: Kimenő SMTP-csatlakozási problémák elhárítása az Azure-ban. Egy másik lehetőség az Azure Firewall üzembe helyezése standard Nagyvállalati Szerződés (EA) előfizetésben. Az EA-előfizetésben lévő Azure Firewall a 25-ös kimenő TCP-port használatával kommunikálhat nyilvános IP-címekkel. Előfordulhat, hogy más előfizetéstípusokban is működik, de nem garantált. Privát IP-címek, például virtuális hálózatok, VPN-ek és Azure ExpressRoute esetén az Azure Firewall támogatja a kimenő kapcsolatot a 25-ös TCP-porton. |
| Nincs elegendő SNAT-port | Az Azure Firewall jelenleg 2496 portot támogat nyilvános IP-címenként háttérbeli virtuálisgép-méretezési csoportpéldányonként. Alapértelmezés szerint két virtuálisgép-méretezési csoportpéldány létezik. Tehát folyamatonként 4992 port található (cél IP-cím, célport és protokoll (TCP vagy UDP). A tűzfal legfeljebb 20 példányra méretezhető. | Ez egy platformkorlátozás. A korlátok megkerüléséhez konfiguráljon legalább öt nyilvános IP-címmel rendelkező Azure Firewall-telepítéseket az SNAT-kimerültségnek kitett üzemelő példányokhoz. Ez ötszörösére növeli a rendelkezésre álló SNAT-portokat. Leosztás ip-címelőtagból az alsóbb rétegbeli engedélyek egyszerűsítése érdekében. Egy állandóbb megoldás érdekében üzembe helyezhet egy NAT-átjárót az SNAT-portkorlátok leküzdése érdekében. Ez a megközelítés támogatott a virtuális hálózatok üzembe helyezéséhez. További információ: SNAT-portok méretezése az Azure Virtual Network NAT használatával. |
| A DNAT nem támogatott a kényszerített bújtatás engedélyezésével | A kényszerített bújtatással üzembe helyezett tűzfalak az aszimmetrikus útválasztás miatt nem támogatják az internetről érkező bejövő hozzáférést. | Ez a tervezés miatt aszimmetrikus útválasztás. A bejövő kapcsolatok visszatérési útvonala a helyszíni tűzfalon keresztül halad, amely nem látta a kapcsolat létrejöttét. |
| Előfordulhat, hogy a kimenő passzív FTP nem működik több nyilvános IP-címmel rendelkező tűzfalak esetében az FTP-kiszolgáló konfigurációjától függően. | A passzív FTP különböző kapcsolatokat hoz létre a vezérléshez és az adatcsatornákhoz. Amikor egy több nyilvános IP-címmel rendelkező tűzfal kimenő adatokat küld, véletlenszerűen kiválaszt egy nyilvános IP-címet a forrás IP-címhez. Az FTP sikertelen lehet, ha az adatok és a vezérlőcsatornák eltérő forrás IP-címeket használnak az FTP-kiszolgáló konfigurációjától függően. | Explicit SNAT-konfigurációt tervezünk. Addig is konfigurálhatja az FTP-kiszolgálót úgy, hogy különböző forrás IP-címekről fogadjon el adatokat és szabályozza a csatornákat (lásd az IIS példáját). Másik lehetőségként érdemes lehet egyetlen IP-címet használni ebben a helyzetben. |
| Előfordulhat, hogy a bejövő passzív FTP nem működik az FTP-kiszolgáló konfigurációjától függően | A passzív FTP különböző kapcsolatokat hoz létre a vezérléshez és az adatcsatornákhoz. Az Azure Firewall bejövő kapcsolatait a rendszer az egyik tűzfal privát IP-címére irányítja a szimmetrikus útválasztás biztosítása érdekében. Az FTP sikertelen lehet, ha az adatok és a vezérlőcsatornák eltérő forrás IP-címeket használnak az FTP-kiszolgáló konfigurációjától függően. | Az eredeti forrás IP-cím megőrzése folyamatban van. Addig is konfigurálhatja az FTP-kiszolgálót, hogy fogadja el a különböző forrás IP-címekről származó adatokat és csatornákat. |
| Az aktív FTP nem működik, ha az FTP-ügyfélnek el kell érnie egy FTP-kiszolgálót az interneten keresztül. | Az Active FTP az FTP-ügyfél portparancsát használja, amely az FTP-kiszolgálót irányítja, hogy milyen IP-címet és portot használjon az adatcsatornához. Ez a PORT-parancs az ügyfél privát IP-címét használja, amely nem módosítható. Az Azure Firewallon áthaladó ügyféloldali forgalom az internetalapú kommunikációra van kiprogramva, így az FTP-kiszolgáló érvénytelennek tekinti a PORT parancsot. | Ez az aktív FTP általános korlátozása, ha ügyféloldali NAT-tal használják. |
| A NetworkRuleHit metrika hiányzik egy protokolldimenzióból | Az ApplicationRuleHit metrika lehetővé teszi a szűrésen alapuló protokollt, de ez a képesség hiányzik a megfelelő NetworkRuleHit-metrikában. | A javítás vizsgálata folyamatban van. |
| A 64000 és 65535 közötti portokkal rendelkező NAT-szabályok nem támogatottak | Az Azure Firewall a hálózati és alkalmazásszabályok 1-65535 tartományában lévő portokat engedélyezi, a NAT-szabályok azonban csak az 1–63999 tartomány portjain használhatók. | Ez egy jelenlegi korlátozás. |
| A konfigurációs frissítések átlagosan öt percet is igénybe vehetnek | Az Azure Firewall konfigurációs frissítése átlagosan 3–5 percet vehet igénybe, és a párhuzamos frissítések nem támogatottak. | A javítás vizsgálata folyamatban van. |
| Az Azure Firewall SNI TLS-fejlécekkel szűri a HTTPS- és MSSQL-forgalmat | Ha a böngésző- vagy kiszolgálószoftver nem támogatja a Kiszolgálónévmutató (SNI) bővítményt, nem tud csatlakozni az Azure Firewallon keresztül. | Ha a böngésző- vagy kiszolgálószoftver nem támogatja az SNI-t, akkor lehetséges, hogy egy alkalmazásszabály helyett hálózati szabály használatával szabályozhatja a kapcsolatot. Lásd az SNI-t támogató szoftverek kiszolgálónév-jelzését. |
| Nem lehet tűzfalszabályzat-címkéket hozzáadni a portál vagy az Azure Resource Manager (ARM) sablonjaival | Az Azure Firewall Policy egy javítástámogatási korlátozással rendelkezik, amely megakadályozza, hogy címkét adjon hozzá az Azure Portal vagy AZ ARM-sablonok használatával. A következő hiba jön létre: Nem sikerült menteni az erőforrás címkéinek mentését. | A javítás vizsgálata folyamatban van. Vagy az Azure PowerShell-parancsmaggal Set-AzFirewallPolicy frissítheti a címkéket. |
| Az IPv6 jelenleg nem támogatott | Ha IPv6-címet ad hozzá egy szabályhoz, a tűzfal meghibásodik. | Csak IPv4-címeket használjon. Az IPv6-támogatás vizsgálata folyamatban van. |
| A RuleCollectionGroups eltávolítása ARM-sablonokkal nem támogatott. | A RuleCollectionGroup arm-sablonokkal való eltávolítása nem támogatott, és sikertelenséget eredményez. | Ez nem támogatott művelet. |
| A (*) engedélyezésére vonatkozó DNAT-szabály SNAT-forgalmat fog használni. | Ha egy DNST-szabály engedélyezi a forrás IP-címként bármelyik (*) értéket, akkor egy implicit hálózati szabály megegyezik a VNet-VNet forgalommal, és mindig SNAT-ként kezeli a forgalmat. | Ez egy jelenlegi korlátozás. |
| A DNST-szabály biztonsági szolgáltatóval rendelkező biztonságos virtuális központhoz való hozzáadása nem támogatott. | Ez a visszaadott DNST-forgalom aszinkron útvonalát eredményezi, amely a biztonsági szolgáltatóhoz kerül. | Nem támogatott. |
| Több mint 2000 szabálygyűjtemény létrehozásakor hiba történt. | A NAT-/alkalmazás- vagy hálózati szabálygyűjtemények maximális száma 2000 (Resource Manager-korlát). | Ez egy jelenlegi korlátozás. |
| XFF-fejléc HTTP/S-ben | Az XFF-fejlécek felülíródnak a tűzfal által látott eredeti forrás IP-címmel. Ez a következő használati esetekben alkalmazható: - HTTP-kérések - HTTPS-kérelmek TLS-leállítással |
A javítás vizsgálata folyamatban van. |
| A rendelkezésre állási zónákkal rendelkező tűzfal nem telepíthető újonnan létrehozott nyilvános IP-címmel | Ha rendelkezésre állási zónákkal rendelkező tűzfalat helyez üzembe, nem használhat újonnan létrehozott nyilvános IP-címet. | Először hozzon létre egy új zónaredundáns nyilvános IP-címet, majd rendelje hozzá ezt a korábban létrehozott IP-címet a tűzfal üzembe helyezése során. |
Azure Firewall Premium
Feljegyzés
A Standardra vonatkozó problémák a Premiumra is vonatkoznak.
Az Azure Firewall Premium az alábbi ismert problémákat tapasztalja:
| Probléma | Leírás | Kezelés |
|---|---|---|
| AZ FQDN-feloldás ESNI-támogatása HTTPS-ben | A titkosított SNI nem támogatott a HTTPS-kézfogásban. | Jelenleg csak a Firefox támogatja az ESNI-t egyéni konfigurációval. Javasolt megkerülő megoldás a funkció letiltása. |
| Az ügyféltanúsítvány-hitelesítés nem támogatott | Az ügyféltanúsítványokkal kölcsönös identitásmegbízhatóságot hozhat létre az ügyfél és a kiszolgáló között. Az ügyféltanúsítványok a TLS-egyeztetés során használatosak. Az Azure Firewall újratárgyalja a kapcsolatot a kiszolgálóval, és nem fér hozzá az ügyféltanúsítványok titkos kulcsához. | Egyik sem |
| QUIC/HTTP3 | A QUIC a HTTP új főverziója. Ez egy UDP-alapú protokoll 80-nál (PLAN) és 443-nál (SSL). Az FQDN/URL/TLS-ellenőrzés nem támogatott. | Konfigurálja az UDP 80/443 átadását hálózati szabályként. |
| Nem megbízható ügyfél által aláírt tanúsítványok | Az ügyfél által aláírt tanúsítványokat a tűzfal nem megbízhatónak minősíti, ha egy intranetes webkiszolgálótól érkezett. | A javítás vizsgálata folyamatban van. |
| Helytelen forrás IP-cím a HTTP azonosítójával rendelkező riasztásokban (TLS-vizsgálat nélkül). | Ha egyszerű szöveges HTTP-forgalom van használatban, és az IDPS új riasztást ad ki, és a cél egy nyilvános IP-cím, a megjelenített forrás IP-címe helytelen (az eredeti IP-cím helyett a belső IP-cím jelenik meg). | A javítás vizsgálata folyamatban van. |
| Tanúsítványterjesztés | A hitelesítésszolgáltatói tanúsítvány tűzfalra való alkalmazása után a tanúsítvány érvénybe lépése 5–10 percet vehet igénybe. | A javítás vizsgálata folyamatban van. |
| TLS 1.3-támogatás | A TLS 1.3 részben támogatott. Az ügyfél és a tűzfal közötti TLS-alagút a TLS 1.2-n alapul, a tűzfalról a külső webkiszolgálóra pedig a TLS 1.3-on alapul. | A frissítések vizsgálata folyamatban van. |
| TLSi köztes hitelesítésszolgáltatói tanúsítvány lejárata | Egyes egyedi esetekben a köztes hitelesítésszolgáltató tanúsítványa az eredeti lejárati dátum előtt két hónappal lejárhat. | Az eredeti lejárati dátum előtt két hónappal újítsa meg a köztes hitelesítésszolgáltatói tanúsítványt. A javítás vizsgálata folyamatban van. |