تخطي إلى المحتوى
CivoCloudManager

افتح جدار حماية Civo لعنوانك، ثم أغلقه.

الإجراء اليدوي، ومصيدة الـ IP المتغير التي يخلّفها، ومسار مجاني من شريط القوائم يغلق القاعدة عند موعد.

تريد الوصول إلى instance في Civo أو إلى API عنقود من حيث تجلس الآن. والجواب قاعدة جدار حماية واحدة: اعرف عنوان IPv4 العام، ثم اسمح بالمنفذ من ذلك العنوان وحده بكتابة الـ CIDR بصيغة /32. تسهّل Civo النصف الأول وتجعل النصف الثاني خطِرًا، لأن قاعدة تضيفها بيدك تبقى حتى يحذفها أحد. هذه الصفحة تعرض الإجراء اليدوي كاملًا، ثم الجزء الذي لا يتولاه أحد تقريبًا: إغلاقها من جديد.

القاعدة نفسها، مفتوحة من شريط القوائم

  1. 01

    أخبر التطبيق أي جدران حماية تديرها

    عند أول تشغيل يبدأ درع شريط القوائم الإعداد: أدخل مفتاح Civo API الذي يذهب إلى macOS Keychain، واختر منطقة، وحدد جدران الحماية التي تريد التحكم فيها. لكل جدار حماية مختار منفذ، وذلك الحقل يبدأ عند 6443.

  2. 02

    دعه يجد عنوان IPv4 العام

    يجري الكشف مقابل api.ipify.org أولًا، ثم ifconfig.me/ip، ثم icanhazip.com، ويتوقف عند أول مزود يجيب بعنوان عام صالح. أما جواب IPv6 أو عنوان خاص فيُرفض برسالة بدل أن يُكتب في قاعدة، لأن قواعد جدار حماية Civo تحتاج CIDR من نوع IPv4.

  3. 03

    نقرة واحدة تكتب القاعدة

    ينشئ التطبيق قاعدة ingress على المنفذ المختار مع CIDR مضبوط على عنوانك المكتشف زائد /32، وبتسمية civo-cloud-<hostname>-<firewall-name>. وتعيد Civo معرّف القاعدة الدقيق في استجابة الإنشاء، فلا يضطر التطبيق لاحقًا إلى تخمين أي قاعدة كانت قاعدته.

  4. 04

    اختر كم تبقى مفتوحة

    يوفّر الوصول المؤقت 15 دقيقة و30 دقيقة وساعة وساعتين. وهناك أيضًا Unlimited، الذي يفتح القاعدة ولا يجدول أي إغلاق، فلا تختره إلا وأنت تنوي إغلاق القاعدة بنفسك.

  5. 05

    الموعد مكتوب على القرص

    كل مهمة إغلاق تحمل معرّف جدار الحماية ومعرّف القاعدة والمنطقة والموعد، وتُكتب بشكل ذرّي في firewall-closures.json داخل مجلد Application Support الخاص بالتطبيق. أغلق التطبيق ويبقى الموعد قائمًا: في التشغيل التالي تُغلق المهام المتأخرة بلا أن تُفتح النافذة المنبثقة أصلًا. والحد الصريح أن التطبيق يجب أن يكون شغالًا وقادرًا على الوصول إلى Civo كي يحذف قاعدة. الإغلاق أو النوم لا يجدول حذفًا من جهة الخادم.

  6. 06

    احفظ العنوان كإعداد مسمى

    خزّن الـ IP الحالي تحت اسم مثل Home أو Office وافتح جدار حماية لذلك الإعداد لاحقًا بلا كشف جديد. مفيد حين تريد فتح الوصول لعنوان مكتب ثابت وأنت جالس في مكان آخر.

ما الذي يفعله جدار حماية Civo الجديد فعلًا

وثائق Civo واضحة: لا يوجد خيار سماح أو منع حين تنشئ قاعدة، لأن الافتراضي في جدار حماية جديد هو منع كل شيء، فلا تفتح إلا المنافذ التي تحتاجها. وجدار الحماية الذي تنشئه أنت يبدأ مغلقًا إذن، وكل قاعدة تضيفها قاعدة سماح. لكن المصيدة في مكان آخر. كل منطقة تأتي بجدار حماية اسمه حرفيًا Default (all open)، ووثائق Civo نفسها تقول إن كل منافذه مفتوحة وتنصح بتخصيصه. فالجواب الصحيح على السؤال المتكرر هو: جدار حمايتك يمنع افتراضيًا، أما جدار حماية Default في المنطقة فلا.

الإجراء اليدوي كاملًا

أولًا، احصل على عنوان IPv4 العام: curl -s https://api.ipify.org. ثانيًا، أضف القاعدة. مع Civo CLI تكون civo firewall rule create <firewall_id> --protocol=TCP --startport=6443 --endport=6443 --cidr=203.0.113.42/32 --direction=ingress --label='laptop'. ثالثًا، وهذا ما يتخطاه الناس، دوّن معرّف القاعدة العائد كي تحذفها بعد ذلك. وانتبه للقيم الافتراضية: اترك --cidr خارج الأمر فتطبّق الـ CLI القيمة 0.0.0.0/0، وهو ما يفتح المنفذ للإنترنت كله لا لك. ومسار اللوحة بالشكل نفسه: Actions، ثم Rules، ثم منفذ واحد أو مدى، والبروتوكول والاتجاه والـ CIDR.

القاعدة تعيش أطول من سبب إضافتها

قاعدة جدار حماية Civo بلا انتهاء صلاحية. تبقى حتى يزيلها إنسان أو استدعاء API. على خط عمل بعنوان ثابت هذا مجرد فوضى صغيرة. أما على اتصال منزلي فهو انكشاف حقيقي، لأن معظم مزودي الإنترنت المنزلي يدوّرون العنوان عند إعادة الاتصال أو عند تجديد ليلي للعقد. الـ /32 الذي سمحت به يُسلَّم عندها إلى راوتر شخص آخر، وقاعدتك صارت تمرّر غريبًا إلى المنفذ 6443 بينما أنت محجوب عن الدخول وتكتب قاعدة ثانية. كل قاعدة تكتبها بيدك دين صغير، ولا يُسدَّد الدين إلا حين تتذكر حذفها.

لماذا لا يستطيع التطبيق حذف قاعدة كتبتها أنت

الملكية تُحسم بالتسمية، لا بالمنفذ ولا بالعنوان. لا ينشئ التطبيق إلا قواعد بتسمية civo-cloud-<hostname>-<firewall-name>، والقواعد المفتوحة لاتصال Kubernetes API تحمل اللاحقة k8s-api بدلًا من ذلك. ويسرد Bulk Close All القواعد على كل جدار حماية مُدار ولا يزيل إلا ما تبدأ تسميته بتلك البادئة لهذا الجهاز. أما قاعدة إنتاج كتبتها بيدك فلا تحمل تسمية كهذه، فلا تكون مرشحة أبدًا. وتحفّظ يستحق الذكر: فشل استعلام الحالة ما زال يظهر في شريط القوائم كمغلق أو غير معروف، فالعرض ليس دليلًا على إغلاق من جهة الخادم. راجع لوحة Civo حين يكون الأمر مهمًا.

المنفذ 6443 ولماذا يتكرر دائمًا

6443 هو منفذ خادم Kubernetes API. وينشر عنقود k3s في Civo نقطته على الشكل https://<master-ip>:6443، وهي ما يتحدث إليه kubectl وkubeconfig وأي عميل Kubernetes. فإن لم يسمح جدار حماية العنقود بالمنفذ 6443 من عنوانك، انتهت مهلة كل أمر، ولهذا يهيمن ذلك الرقم على عمليات البحث عن جدار حماية Civo. وفي التطبيق، 6443 هو المنفذ الافتراضي في الإعداد، والاتصال بعنقود يفحص وصول API ويفتح القاعدة لك إن كانت ناقصة. وذلك المسار الخاص بـ Kubernetes يتتبع قاعدته في الذاكرة وينظّفها عند قطع الاتصال؛ وهو لا يرث سلوك الاستمرار وإعادة المحاولة الخاص بطابور شريط القوائم المؤقت.

أسئلة يطرحها الناس فعلًا

كيف أفتح جدار حماية Civo لعنوان IP الخاص بي وحده؟
احصل على عنوان IPv4 العام بـ curl -s https://api.ipify.org، ثم أنشئ قاعدة ingress على جدار الحماية المستهدف مع ذلك العنوان مكتوبًا كـ CIDR بصيغة /32. مع Civo CLI: civo firewall rule create <firewall_id> --protocol=TCP --startport=6443 --endport=6443 --cidr=203.0.113.42/32 --direction=ingress. ولا يوجد خيار سماح أو منع في الـ API، لأن جدار الحماية الذي تنشئه يمنع كل شيء حتى تفتح منفذًا. واحتفظ بمعرّف القاعدة العائد كي تحذفها لاحقًا.
ماذا يعني /32 في قاعدة جدار حماية Civo؟
في ترميز CIDR، الرقم بعد الشرطة المائلة هو عدد البتات الأولى الثابتة في العنوان. وعنوان IPv4 من 32 بت، فـ /32 يثبّتها كلها وتطابق القاعدة عنوانًا واحدًا بالضبط. 203.0.113.42/32 هو ذلك المضيف ولا شيء غيره. وللمقارنة، /24 يغطي 256 عنوانًا، و0.0.0.0/0 يغطي الإنترنت كله، وهو ما تطبّقه Civo حين تنشئ قاعدة بلا CIDR.
ماذا يحدث إذا تغير عنوان IP الخاص بي؟
القاعدة لا تتغير معك. تظل تسمح بالعنوان القديم، فتفقد أنت الوصول وتضطر إلى إضافة قاعدة ثانية، بينما يرث ذلك العنوان من يسلّمه له المزود بعدك. وهذه هي الحالة الطبيعية على الاتصالات المنزلية، حيث يتبدل العنوان عادة عند إعادة الاتصال أو عند تجديد ليلي للعقد. والحل ليس عنوانًا أفضل، بل قاعدة تغلق نفسها: افتح المنفذ لنافذة زمنية محددة ودع الموعد يزيلها.
هل يمسّ CivoCloudManager قواعد جدار الحماية الموجودة عندي؟
لا. لا يحذف إلا القواعد التي أنشأها بنفسه، ويعرفها بالتسمية civo-cloud-<hostname>-<firewall-name>، مع اللاحقة k8s-api لوصول Kubernetes API. ويرشّح Bulk Close All قائمة قواعد كل جدار حماية مُدار بتلك البادئة قبل أن يحذف شيئًا، فالقاعدة التي كتبتها بيدك في لوحة Civo أو الـ CLI أو Terraform لا تحمل تسمية مطابقة ولا تُزال أبدًا.
هل يبقى مؤقت الإغلاق التلقائي بعد إغلاق التطبيق؟
الموعد يبقى. كل مهمة تخزّن معرّف جدار الحماية ومعرّف القاعدة والمنطقة ووقت الإغلاق في ملف JSON يُكتب بشكل ذرّي تحت Application Support، وتُغلق المهام المتأخرة عند التشغيل التالي. أما ما لا يبقى فهو الإغلاق بلا حضور: الحذف استدعاء API من جهازك، فالتطبيق يجب أن يكون شغالًا وقادرًا على الوصول إلى Civo. وإغلاق التطبيق أو نوم الجهاز بعد الموعد يؤجل الإغلاق حتى تشغّله من جديد، ولا يجدول شيئًا على الخادم.

التحكم في جدار الحماية هو الطبقة المجانية.

الفتح والإغلاق من شريط القوائم لعنوانك الحالي، والإعدادات المسماة، وموعد الإغلاق التلقائي، كلها تبقى مجانية بعد انتهاء تجربة الوصول الكامل لسبعة أيام، فهذه الصفحة لا تكلفك شيئًا كي تعمل بها.