إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تساعدك هذه المقالة على فهم المشكلات والقيود المعروفة الحالية في Azure Firewall. نقوم بتحديث هذه المعلومات عند حل المشكلات، لذا تحقق مرة أخرى بانتظام للحصول على أحدث حالة.
قبل نشر Azure Firewall أو استكشاف أخطاء عمليات التوزيع الحالية وإصلاحها، راجع هذه المشكلات المعروفة لتجنب المشكلات الشائعة وتخطيط الحلول المناسبة
للحصول على حدود خدمة Azure Firewall، راجع حدود اشتراك Azure والخدمة والحصص النسبية والقيود.
قيود السعة الحالية
تواجه المناطق التالية حاليا قيودا على السعة:
| المنطقة / المناطق | SKU | القيود | التوصية |
|---|---|---|---|
| المنطقة الفيزيائية 1 والمنطقة 4 في شرق US 2 EUAP | أساسي، قياسي، ومتميز | - لا يمكنك نشر جدار حماية Azure جديد في المنطقة 1 والمنطقة 4. | نوصي بنشر جدار حماية Azure جديد إلى مناطق التوفر المتبقية أو استخدام منطقة مختلفة. لتكوين جدار حماية موجود، راجع كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟ |
|
-
المنطقة المادية 2 فيالمنطقة المادية 3 في - في جنوب شرق آسيا |
قياسي ومميز | - لا يمكنك نشر جدار حماية Azure جديد إلى المنطقة 3 في جنوب شرق آسيا أو المنطقة 2 في شمال أوروبا.
- إذا أوقفت جدار حماية Azure الموجود الذي تم نشره في هذه المنطقة، فلا يمكن إعادة تشغيله. لمزيد من المعلومات، راجع مناطق التوفر المادية والمنطقية. |
نوصي بنشر جدار حماية Azure جديد إلى مناطق التوفر المتبقية أو استخدام منطقة مختلفة. لتكوين جدار حماية موجود، راجع كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟ |
| المنطقة الفيزيائية 3 في جنوب وسط الولايات المتحدة | أساسي، قياسي، ومتميز | - لا يمكنك نشر جدار حماية Azure جديد في المنطقة 3.
التاريخ المتوقع متاح: 31 مارس 2026 |
نوصي بنشر جدار حماية Azure جديد إلى مناطق التوفر المتبقية أو استخدام منطقة مختلفة. لتكوين جدار حماية موجود، راجع كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟ |
| المنطقة الفيزيائية 2 في وسط إسبانيا | أساسي، قياسي، ومتميز | - لا يمكنك نشر جدار حماية Azure جديد في المنطقة 2.
التاريخ المتوقع متاح: 31 ديسمبر 2026 |
نوصي بنشر جدار حماية Azure جديد إلى مناطق التوفر المتبقية أو استخدام منطقة مختلفة. لتكوين جدار حماية موجود، راجع كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟ |
| حاكم الولايات المتحدة فيرجينيا | Premium | - لا توجد سعة ل Azure Firewall Premium SKU في حكومة الولايات المتحدة في ولاية فرجينيا، يتم حظر كل من عمليات النشر في المناطق وغير الإقليمية. | انشر Azure Firewall Standard SKU أو انشر Premium SKU إلى منطقة مختلفة. |
| المنطقة المادية 3 في حكومة الولايات المتحدة فيرجينيا | أساسية وقياسية | - تم حظر عمليات النشر في المنطقة المادية 3 في ولاية فرجينيا الحكومية.
- يجب عليك تحديد المناطق المتاحة يدويا للنشر الناجح، مما يؤدي إلى إنشاء تجربة نشر دون المستوى الأمثل. |
حدد المناطق 1 و2 لعمليات النشر في المنطقة أو استخدم منطقة مختلفة. |
| المنطقة الفيزيائية 2 في غرب US 2 | أساسي، قياسي، ومتميز | - لا يمكنك نشر جدار حماية Azure جديد في المنطقة 2. | نوصي بنشر جدار حماية Azure جديد إلى مناطق التوفر المتبقية أو استخدام منطقة مختلفة. لتكوين جدار حماية موجود، راجع كيف يمكنني تكوين مناطق التوفر بعد التوزيع؟ |
تحذير
إذا قمت بإيقاف توزيع Azure Firewall موجود في أي من هذه المناطق المقيدة بالسعة، فقد لا تتمكن من بدء تشغيله مرة أخرى بسبب قيود السعة المستمرة. خطط وفقا لذلك قبل إيقاف مثيلات جدار الحماية في هذه المناطق.
المشكلات المعروفة لمعيار جدار حماية Azure
يحتوي Azure Firewall Standard على المشكلات المعروفة التالية:
| المشكلة | الوصف | التخفيف |
|---|---|---|
| يقتصر دعم DNAT لعناوين IP الخاصة على الإصدارات القياسية والمميزة | يتوفر دعم DNAT على عنوان IP الخاص بجدار حماية Azure فقط في إصدارات جدار الحماية القياسية والمتميزة، وليس في الإصدار الأساسي. | بلا |
| عملية إلغاء التخصيص والتخصيص لجدار حماية Azure غير مدعومة عند تكوين قواعد DNAT الخاصة بعنوان IP | تفشل عملية تخصيص Azure Firewall عند تكوين قواعد DNAT الخاصة | 1. إلغاء تخصيص جدار حماية Azure 2. حذف جميع قواعد IP DNAT الخاصة 3. قم بتخصيص جدار حماية Azure وانتظر حتى يتم ملء IP الخاص 4. إعادة تكوين قواعد IP DNAT الخاصة بعنوان IP الخاص المناسب |
| لا تعمل قواعد تصفية الشبكة لبروتوكولات غير TCP/UDP (على سبيل المثال ICMP) لحركة المرور المرتبطة بالإنترنت | لا تعمل قواعد تصفية الشبكة لبروتوكولات غير TCP/UDP مع SNAT إلى عنوان IP العام. يتم دعم بروتوكولات غير TCP/UDP بين الشبكات الفرعية المحورية والشبكات الظاهرية. | يستخدم Azure Firewall موازن التحميل القياسي، والذي لا يدعم SNAT لبروتوكولات IP اليوم. نحن نستكشف خيارات لدعم بروتوكولات TCP/UDP غير لحركة المرور المرتبطة بالإنترنت في إصدار مستقبلي. |
| عند إلغاء تخصيص Azure Firewall ثم تخصيصه مرة أخرى، قد يتم تعيين عنوان IP خاص جديد له | بعد عملية إلغاء التخصيص والتخصيص لجدار حماية Azure، يتم تعيين عنوان IP خاص ديناميكيا من الشبكة الفرعية لجدار حماية Azure. عند تعيين عنوان IP خاص جديد يختلف عن العنوان السابق، فإنه يتسبب في حدوث مشكلات في التوجيه. | تحتاج إلى إعادة تكوين المسارات المعرفة من قبل المستخدم (UDRs) الحالية باستخدام عنوان IP الخاص الجديد. يتم التحقق من إصلاح للاحتفاظ بعنوان IP الخاص بعد عملية التخصيص. |
| لا ترث نهج جدار الحماية الفرعي إعدادات DNS من النهج الأصلية. | عند تغيير إعدادات DNS في نهج جدار حماية أصلي، قد تفشل النهج الفرعية المرتبطة به في حل أسماء المجالات في قواعدها. | قم بتكوين إعدادات DNS مباشرة على كل نهج فرعي بدلا من الاعتماد على النهج الأصل. نحن نعمل على إصلاح للسماح بوراثة إعدادات DNS. |
| دعم PowerShell وCLI مفقود ل ICMP | لا يدعم Azure PowerShell وCLI ICMP كبروتوكول صالح في قواعد الشبكة. | لا يزال من الممكن استخدام ICMP كبروتوكول عبر المدخل وواجهة برمجة تطبيقات REST. نحن نعمل على إضافة ICMP في PowerShell وCLI قريبا. |
| تتطلب علامات FQDN بروتوكولا: يجب تعيين المنفذ | تتطلب قواعد التطبيق مع علامات FQDN المنفذ: تعريف البروتوكول. | يمكنك استخدام https كمنفذ: قيمة البروتوكول. نحن نعمل على جعل المنفذ: حقل البروتوكول اختياريا عند استخدام علامات FQDN. |
| نقل جدار حماية إلى مجموعة موارد مختلفة أو اشتراك غير مدعوم | نقل جدار حماية إلى مجموعة موارد مختلفة أو اشتراك غير مدعوم. | دعم هذه الوظيفة موجود في خارطة الطريق الخاصة بنا. لنقل جدار حماية إلى مجموعة موارد أو اشتراك مختلف، يجب حذف المثيل الحالي وإعادة إنشائه في مجموعة الموارد الجديدة أو الاشتراك الجديد. |
| قد يتم إخفاء تنبيهات التحليل الذكي للمخاطر | تقوم قواعد الشبكة ذات الوجهة 80/443 للتصفية الصادرة بإخفاء تنبيهات التحليل الذكي للمخاطر عند تكوينها لتنبيه الوضع فقط. | إنشاء تصفية صادرة ل 80/443 باستخدام قواعد التطبيق. أو قم بتغيير وضع التحليل الذكي للمخاطر إلى Alert and Deny. |
| مع المراكز الظاهرية الآمنة، يمكن تكوين مناطق التوفر فقط أثناء النشر. | لا يمكنك تكوين مناطق التوفر بعد نشر جدار حماية مع مراكز ظاهرية آمنة. | حسب التصميم. |
| SNAT على الاتصالات الواردة | تقوم قواعد DNAT الواردة دائما بتغيير عنوان IP المصدر لحركة المرور المرتجعة. | لتتبع عنوان IP الأصلي للعميل لحركة مرور الويب، قم بتكوين العملاء أو الخوادم الوكيلة لتضمين عنوان IP الأصلي في رؤوس XFF . يحتفظ Azure Firewall بعناوين IP هذه في رأس XFF ويضيف عنوان IP لجدار الحماية إلى رأس XFF عند معالجة قواعد حركة مرور الويب. |
| دعم تصفية SQL FQDN فقط في وضع الوكيل (المنفذ 1433) | بالنسبة إلى Azure SQL Database وAzure Synapse Analytics وAzure SQL Managed Instance: يتم دعم تصفية SQL FQDN في وضع الوكيل فقط (المنفذ 1433). بالنسبة إلى Azure SQL IaaS: إذا كنت تستخدم منافذ غير قياسية، يمكنك تحديد هذه المنافذ في قواعد التطبيق. |
بالنسبة إلى SQL في وضع إعادة التوجيه (الافتراضي إذا كان الاتصال من داخل Azure)، يمكنك بدلا من ذلك تصفية الوصول باستخدام علامة خدمة SQL كجزء من قواعد شبكة Azure Firewall. |
| تم حظر حركة مرور SMTP الصادرة على منفذ TCP 25 | يحظر النظام الأساسي Azure رسائل البريد الإلكتروني الصادرة المرسلة مباشرة إلى المجالات الخارجية (مثل outlook.com و gmail.com) على منفذ TCP 25. حظر نسبة استخدام الشبكة SMTP الصادرة على المنفذ 25 هو سلوك النظام الأساسي الافتراضي في Azure. لا يقدم جدار حماية Azure أي قيود أكثر تحديدا. |
استخدم خدمات ترحيل SMTP المصادق عليها، والتي تتصل عادة من خلال منفذ TCP 587، ولكنها تدعم أيضا المنافذ الأخرى. للحصول على مزيد من المعلومات، راجع قسم استكشاف أخطاء مشكلات الاتصال الوارد بواسطة بروتوكول SMTP وإصلاحها في منصة Azure. خيار آخر هو نشر Azure Firewall في اشتراك اتفاقية Enterprise القياسية (EA). يمكن لجدار حماية Azure في اشتراك EA الاتصال بعناوين IP العامة باستخدام منفذ TCP الصادر 25. قد يعمل في أنواع الاشتراكات الأخرى ، ولكنه غير مضمون. بالنسبة لعناوين IP الخاصة مثل الشبكات الظاهرية والشبكات الظاهرية الخاصة وAzure ExpressRoute، يدعم جدار حماية Azure اتصالا صادرا على منفذ TCP 25. |
| استنفاد منفذ SNAT | يدعم Azure Firewall حاليا 2496 منفذا لكل عنوان IP عام لكل مثيل مجموعة مقياس الجهاز الظاهري الخلفية. بشكل افتراضي، هناك اثنان من مثيلات مجموعة مقاييس الجهاز الظاهري. لذلك، هناك 4992 منفذا لكل تدفق (عنوان IP الوجهة ومنفذ الوجهة والبروتوكول (TCP أو UDP). يتوسع جدار الحماية حتى 20 مثيلا كحد أقصى. | يعد استنفاد منفذ SNAT قيدا على النظام الأساسي. يمكنك التغلب على الحدود عن طريق تكوين عمليات نشر Azure Firewall مع خمسة عناوين IP عامة كحد أدنى للتوزيعات المعرضة لاستنفاد SNAT. تؤدي إضافة المزيد من عناوين IP العامة إلى زيادة منافذ SNAT المتوفرة بمقدار خمس مرات. تخصيص من بادئة عنوان IP لتبسيط أذونات انتقال البيانات من الخادم. للحصول على حل دائم، يمكنك نشر بوابة NAT للتغلب على حدود منفذ SNAT. يتم دعم نشر بوابة NAT لعمليات توزيع الشبكة الظاهرية. لمزيد من المعلومات، راجع تغيير حجم منافذ SNAT باستخدام Azure Virtual Network NAT. |
| DNAT غير مدعوم مع تمكين Forced Tunneling | لا يمكن أن تدعم جدران الحماية المنشورة مع تمكين Forced Tunneling الوصول الوارد من الإنترنت بسبب التوجيه غير المتماثل. | إن عدم وجود دعم DNAT مع النفق القسري هو حسب التصميم بسبب التوجيه غير المتماثل. يمر مسار الإرجاع للاتصالات الواردة عبر جدار الحماية المحلي، الذي لا يرى الاتصال الذي تم إنشاؤه. |
| قد لا يعمل بروتوكول نقل الملفات الخاملة الصادرة مع جدران الحماية ذات عناوين IP العامة المتعددة، اعتمادا على تكوين خادم FTP. | ينشئ FTP السلبي اتصالات مختلفة لقنوات التحكم والبيانات. عندما يرسل جدار الحماية الذي يحتوي على عناوين IP عامة متعددة البيانات الصادرة، فإنه يحدد عشوائيا أحد عناوين IP العامة الخاصة به لعنوان IP المصدر. قد تفشل FTP عندما تستخدم قنوات البيانات والتحكم عناوين IP مختلفة المصدر، اعتمادا على تكوين خادم FTP. | تم التخطيط لتكوين SNAT صريح. في غضون ذلك، يمكنك تكوين خادم FTP الخاص بك لقبول البيانات وقنوات التحكم من عناوين IP المصدر المختلفة (راجع مثال ل IIS). بدلا من ذلك، ضع في اعتبارك استخدام عنوان IP واحد عند مواجهة مشكلات اتصال FTP. |
| قد لا يعمل FTP السلبي الوارد استنادا إلى تكوين خادم FTP | ينشئ FTP السلبي اتصالات مختلفة لقنوات التحكم والبيانات. الاتصالات الواردة على جدار حماية Azure SNATed إلى أحد عناوين IP الخاصة بجدار الحماية لضمان التوجيه المتماثل. قد تفشل FTP عندما تستخدم قنوات البيانات والتحكم عناوين IP مختلفة المصدر، اعتمادا على تكوين خادم FTP. | يتم التحقيق في الاحتفاظ بعنوان IP المصدر الأصلي. في غضون ذلك، يمكنك تكوين خادم FTP لقبول البيانات وقنوات التحكم من عناوين IP المصدر المختلفة. |
| لا يعمل FTP النشط عندما يجب أن يصل عميل FTP إلى خادم FTP عبر الإنترنت. | يستخدم FTP النشط أمر PORT من عميل FTP الذي يوجه خادم FTP عنوان IP والمنفذ الذي يجب استخدامه لقناة البيانات. يستخدم الأمر PORT عنوان IP الخاص للعميل الذي لا يمكن تغييره. نسبة استخدام الشبكة من جانب العميل التي تعبر جدار حماية Azure هي NATed للاتصالات المستندة إلى الإنترنت، ما يجعل الأمر PORT ينظر إليه على أنه غير صالح من قبل خادم FTP. | يعد فشل FTP النشط قيدا عاما ل FTP النشط عند استخدامه مع NAT من جانب العميل. |
| يفتقد مقياس NetworkRuleHit إلى بعد بروتوكول | يسمح مقياس ApplicationRuleHit بالبروتوكول المستند إلى التصفية، ولكن هذه الإمكانية مفقودة في مقياس NetworkRuleHit المقابل. | يتم التحقيق في إصلاح. |
| قواعد NAT مع المنافذ بين 64000 و65535 غير مدعومة | يسمح Azure Firewall بأي منفذ في النطاق 1-65535 في قواعد الشبكة والتطبيق، ولكن قواعد NAT تدعم فقط المنافذ في النطاق 1-63999. | يعد التقييد المفروض على منافذ قاعدة NAT قيدا حاليا. |
| قد تستغرق تحديثات التكوين خمس دقائق في المتوسط | قد يستغرق تحديث تكوين Azure Firewall من ثلاث إلى خمس دقائق في المتوسط، ولا يتم دعم التحديثات المتوازية. | يتم التحقيق في إصلاح. |
| يستخدم جدار حماية Azure عناوين SNI TLS لتصفية حركة مرور HTTPS وMSSQL | إذا كان المستعرض أو برنامج الخادم لا يدعم ملحق مؤشر اسم الخادم (SNI)، فلا يمكنك الاتصال من خلال جدار حماية Azure. | إذا كان المستعرض أو برنامج الخادم لا يدعم SNI، فقد تتمكن من التحكم في الاتصال باستخدام قاعدة شبكة بدلا من قاعدة تطبيق. راجع إشارة اسم الخادم للبرامج التي تدعم SNI. |
| لا يمكن إضافة علامات نهج جدار الحماية باستخدام المدخل أو قوالب Azure Resource Manager (ARM) | يحتوي نهج جدار حماية Azure على قيود دعم التصحيح التي تمنعك من إضافة علامة باستخدام مدخل Microsoft Azure أو قوالب ARM. تم إنشاء الخطأ التالي: تعذر حفظ العلامات للمورد. | يتم التحقيق في إصلاح. أو يمكنك استخدام Azure PowerShell cmdlet Set-AzFirewallPolicy لتحديث العلامات. |
| IPv6 غير مدعوم حاليا | إذا أضفت عنوان IPv6 إلى قاعدة، يفشل جدار الحماية. | استخدم عناوين IPv4 فقط. يتم التحقيق في دعم IPv6. |
| إزالة RuleCollectionGroups باستخدام قوالب ARM غير مدعومة. | إزالة RuleCollectionGroup باستخدام قوالب ARM غير مدعومة وتؤدي إلى فشل. | إزالة RuleCollectionGroups باستخدام قوالب ARM ليست عملية مدعومة. |
| قاعدة DNAT للسماح بأي (*) سحركة مرور SNAT. | إذا كانت قاعدة DNAT تسمح بأي (*) كعنوان IP المصدر، فإن قاعدة الشبكة الضمنية تتطابق مع نسبة استخدام الشبكة VNet-VNet وستقوم دائما بتعيين نسبة استخدام الشبكة. | يعد سلوك SNAT التلقائي لقواعد DNAT مع أي مصدر قيدا حاليا. |
| إضافة قاعدة DNAT إلى مركز ظاهري آمن مع موفر أمان غير مدعوم. | عند إضافة قاعدة DNAT إلى مركز ظاهري آمن مع موفر أمان، ينتج عن ذلك مسار غير متزامن لنسبة استخدام الشبكة DNAT العائدة، والتي تنتقل إلى موفر الأمان. | غير مدعومة. |
| حدث خطأ عند إنشاء أكثر من 2000 مجموعة قواعد. | العدد الأقصى لمجموعات قاعدة NAT/Application أو الشبكة هو 2000 (حد Resource Manager). | حد تحصيل القاعدة البالغ 2,000 هو قيد حالي. |
| لا يمكن نشر جدار الحماية مع مناطق التوفر باستخدام عنوان IP عام تم إنشاؤه حديثا | عند نشر جدار حماية مع مناطق التوفر، لا يمكنك استخدام عنوان IP عام تم إنشاؤه حديثا. | أولا قم بإنشاء عنوان IP عام مكرر لمنطقة جديدة، ثم قم بتعيين عنوان IP الذي تم إنشاؤه مسبقا أثناء نشر جدار الحماية. |
| لا يتم دعم إقران عنوان IP عام بجدار حماية Azure في سيناريو عبر المستأجرين. | إذا قمت بإنشاء عنوان IP عام في المستأجر أ، فلا يمكنك إقرانه بجدار حماية تم نشره في المستأجر ب. | لا شيء. |
| لا يمكن للأجهزة الظاهرية الموجودة خلف Azure Firewall الاتصال بوجهات قاعدة DNAT باستخدام عنوان IP العام لجدار الحماية | عندما تقوم الأجهزة الظاهرية بتوجيه نسبة استخدام الشبكة عبر Azure Firewall وتحاول الاتصال بالموارد التي تم تكوينها باستخدام قواعد DNAT باستخدام عنوان IP العام لجدار الحماية، يفشل الاتصال. يحدث فشل الاتصال لأن Azure Firewall لا يدعم نسبة استخدام الشبكة من الأجهزة الظاهرية الداخلية إلى عنوان IP العام الخاص بجدار الحماية لوجهات قاعدة DNAT. | ويجري حاليا وضع حل لهذا القيد. |
المشكلات المعروفة لجدار حماية Azure Premium
ملاحظة
تنطبق أي مشكلة تنطبق على Standard أيضا على Premium.
يحتوي Azure Firewall Premium على المشكلات المعروفة التالية:
| المشكلة | الوصف | التخفيف |
|---|---|---|
| دعم ESNI لحل FQDN في HTTPS | SNI المشفرة غير مدعومة في تأكيد اتصال HTTPS. | اليوم فقط فايرفوكس يدعم ESNI من خلال التكوين المخصص. الحل البديل المقترح هو تعطيل ميزة ESNI. |
| مصادقة شهادة العميل غير مدعومة | يتم استخدام شهادات العميل لبناء ثقة هوية متبادلة بين العميل والخادم. يتم استخدام شهادات العميل أثناء تفاوض TLS. يقوم جدار حماية Azure بإعادة التفاوض على اتصال بالخادم وليس لديه حق الوصول إلى المفتاح الخاص لشهادات العميل. | بلا |
| QUIC/HTTP3 | QUIC هو الإصدار الرئيسي الجديد من HTTP. إنه بروتوكول يستند إلى UDP على 80 (PLAN) و443 (SSL). فحص FQDN/URL/TLS غير مدعوم. | تكوين تمرير UDP 80/443 لقواعد الشبكة. |
| شهادات موقعة لعميل غير موثوق به | لا يثق جدار الحماية في الشهادات الموقعة من قبل العميل عند استلامها من خادم ويب يستند إلى الإنترانت. | يتم التحقيق في إصلاح. |
| يعرض IDPS عنوان IP مصدر خاطئ لتنبيهات HTTP بدون فحص TLS | عندما يقوم IDPS بإنشاء تنبيهات لحركة مرور HTTP للنص العادي إلى عناوين IP العامة، فإنه يعرض عنوان IP الداخلي بدلا من عنوان IP المصدر الأصلي. | يتم التحقيق في إصلاح. |
| نشر الشهادة | بعد تطبيق شهادة CA على جدار الحماية، قد يستغرق الأمر ما بين 5-10 دقائق حتى تصبح الشهادة سارية المفعول. | يتم التحقيق في إصلاح. |
| دعم TLS 1.3 | TLS 1.3 مدعوم جزئيا. يستند نفق TLS من العميل إلى جدار الحماية إلى TLS 1.2، ومن جدار الحماية إلى خادم الويب الخارجي يعتمد على TLS 1.3. | يتم التحقيق في التحديثات. |
| انتهاء صلاحية شهادة المرجع المصدق الوسيط TLSi | في بعض الحالات الفريدة، يمكن أن تنتهي صلاحية شهادة المرجع المصدق الوسيطة قبل شهرين من تاريخ انتهاء الصلاحية الأصلي. | تجديد شهادة المرجع المصدق الوسيط قبل شهرين من تاريخ انتهاء الصلاحية الأصلي. يتم التحقيق في إصلاح. |