حلّ المجتمع

‏CasaOS: لا يعمل IPv4 — تحقّق من IPv6 وربط Docker

A CasaOS user on Debian 12 in GCP saw port 80 reported as tcp6 and then broke web access after disabling IPv6 before installation.

لا تُعطّل IPv6 لمجرد أن ss يعرض خدمة CasaOS أو Docker تستمع على :::80. في Linux، يمكن لمستمع IPv6 عام أن يقبل IPv4 أيضًا، وفقًا لإعدادات المقبس، كما ينشر Docker المنافذ عادةً إلى IPv4 عند عدم تحديد عنوان المضيف.

تتعلق الحالة الأصلية بـ CasaOS على Debian 12 في GCP، وليس ZimaOS. ويتمثل التشخيص الصحيح في اختبار IPv4 صراحةً، وفحص بوابة CasaOS وارتباطات منافذ Docker، والتحقق من جدار الحماية السحابي قبل تغيير GRUB أو تعطيل IPv6 على مستوى النظام.

اختبر IPv4 مباشرةً أولًا

curl -4 -v http://127.0.0.1:80/
curl -4 -v http://SERVER_IPV4:80/
ss -ltnp | grep ':80'

إذا كان IPv4 المحلي يعمل بينما يفشل IPv4 البعيد، فمن المرجح أن تكون المشكلة في جدار حماية المضيف أو السحابة أو في التوجيه، وليس في ارتباط CasaOS.

يتضمن نشر منافذ Docker عادةً IPv4

يوضح دليل نشر منافذ Docker الحالي أن المنافذ المنشورة عادةً يمكن الوصول إليها عبر تعيينات عناوين المضيف؛ ويتطلب السلوك المقتصر على IPv6 إعدادًا مختلفًا.

تحقق من CasaOS نفسه

systemctl status casaos
journalctl -u casaos --no-pager -n 100
ss -ltnp | grep -E ':80|casaos'

لا يزال مُثبّت CasaOS الحالي يعرض عناوين واجهات الشبكة IPv4 عند طباعة عنوان لوحة التحكم، لذا فالتثبيت السليم لا يُصمَّم ليتطلب وصولًا مقتصرًا على IPv6.

تحقق من جدار حماية GCP

تأكد من أن الجهاز الافتراضي يملك عنوان IPv4 ومسارًا وقاعدة دخول للمنفذ الذي اخترته لواجهة CasaOS. يمكن لجدار الحماية السحابي حظر المنفذ 80 حتى عندما تكون الخدمة تستمع بصورة صحيحة.

لا تُعطّل IPv6 على مستوى النظام باعتباره الحل الأول

اعتمدت مكونات CasaOS الأقدم تاريخيًا على وجود /proc/net/tcp6، وقد تسبب تعطيل IPv6 في مشكلات بإدارة التطبيقات في بعض الإصدارات. وقد يؤدي حذف IPv6 إلى إنشاء مشكلة ثانية دون حل المشكلة الأولى.

إذا كنت بحاجة إلى ارتباط Docker مقتصر على IPv4

ports:
  - "0.0.0.0:8080:80"

استخدم الارتباط الصريح بـ IPv4 فقط عندما تتحكم في تعريف Compose هذا وتفهم آثار تعريضه للشبكة.

تحقق من منفذ الويب في CasaOS

قد يختار المُثبّت منفذًا متاحًا آخر إذا كان المنفذ 80 مشغولًا بالفعل. تأكد من منفذ HTTP الفعلي لـ CasaOS قبل افتراض فشل الخدمة.

يغطي دليل شبكات Docker أساسيات الشبكات نفسها.

تحقق من sysctl فقط بعد اختبار الاتصال الفعلي

إذا كنت لا تزال تشك في سلوك مقابس الاتصال المزدوج، فتحقق من sysctl net.ipv6.bindv6only. تسمح القيمة 0 للعديد من مقابس IPv6 العامة بقبول اتصالات IPv4 المعيّنة، بينما تجعلها القيمة 1 مقتصرة على IPv6. لا تغيّر هذا الإعداد على مستوى النظام ما لم تفهم جميع الخدمات المتأثرة.

تحقق من العناوين المنشورة الفعلية في Docker

docker ps --format 'table {{.Names}}	{{.Ports}}'
docker inspect CONTAINER --format '{{json .NetworkSettings.Ports}}'

يوضح هذا ما إذا كان Docker قد أنشأ تعيين IPv4 مثل 0.0.0.0:PORT، أو تعيين IPv6، أو كليهما. وهو أكثر موثوقية من استنتاج السلوك من سطر واحد في قائمة العمليات.

تذكّر أن لدى GCP طبقتين من جدران الحماية

قد يملك مضيف Debian قواعد nftables/iptables الخاصة به، بينما يتحكم GCP بشكل منفصل في دخول جدار حماية VPC. وقد تكون الخدمة سليمة محليًا لكنها غير قابلة للوصول خارجيًا لأن أيًا من الطبقتين يحظر المنفذ.

الأسئلة الشائعة

هل يعني :::80 دائمًا أنه مقتصر على IPv6؟

لا. تحقّق باستخدام curl -4 قبل استخلاص هذا الاستنتاج.

هل ينبغي تعطيل IPv6 في GRUB؟

ليس كخطوة أولى لاستكشاف الأخطاء. فقد يؤدي ذلك إلى تعطيل مكونات تتوقع وجود واجهات IPv6 في النواة.

لماذا يعمل localhost بينما لا يعمل IPv4 العام؟

تحقق من جدار الحماية السحابي، ومجموعة الأمان، والمسار، وجدار حماية المضيف.

هل هذه مشكلة في ZimaOS؟

يتعلق النقاش الأصلي بتثبيت CasaOS على Debian 12، وليس ZimaOS.