بناء Cloud صغير كامل بـ Proxmox وPrivate IPs وCloudflare

وصلنا إلى الجزء الأخير. الآن نجمع كل ما بنيناه في سحابة صغيرة كاملة: عشر خدمات تعمل على سيرفر Proxmox واحد، بعنوان عام واحد، وكلها تظهر للعالم بنطاقات فرعية أنيقة بشهادات صالحة — بينما تعيش داخلياً على عناوين خاصة لا يراها أحد.

هذا ليس تمريناً نظرياً: إنها بنية كافية لتشغيل شركة صغيرة كاملة.

المخطّط النهائي

خطة العناوين والنطاقات

ما الذي فُتح فعلاً على الإنترنت؟

المنفذ 80   → 10.10.10.10   (الوسيط — للتحويل وتحدّي الشهادات)
المنفذ 443  → 10.10.10.10   (الوسيط — كل المواقع)
المنفذ 2201 → 10.10.10.11:22 (SSH — مقيّد بعنوان المكتب)

ثلاثة منافذ لعشر خدمات. هذا هو مكسب المعمارية كلها.

بناء السحابة — النصّ الكامل

1) الشبكة وNAT

cat >> /etc/network/interfaces <<'EOF'

auto vmbr2
iface vmbr2 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
    post-up   iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 80  -j DNAT --to 10.10.10.10:80
    post-up   iptables -t nat -A PREROUTING -d 82.39.115.50 -p tcp --dport 443 -j DNAT --to 10.10.10.10:443
    post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
EOF

ifup vmbr2

2) الحاويات دفعة واحدة

TPL=local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst

mk() {  # mk     
  pct create $1 $TPL --hostname $2 --memory $3 --cores 2 --rootfs local-lvm:$4 \
    --net0 name=eth0,bridge=vmbr2,ip=10.10.10.$5/24,gw=10.10.10.1 \
    --nameserver 1.1.1.1 --features nesting=1 \
    --unprivileged 1 --onboot 1 --password "$PASS"
  pct start $1
}

mk 201 npm        1024  8 10
mk 202 wordpress   768  8 11
mk 203 n8n         768  8 12
mk 204 api         384  4 13
mk 205 nextcloud  1024 20 14
mk 206 git         512  8 15
mk 207 odoo       2048 16 16
mk 208 dev         768  8 17
mk 250 postgres   1024 16 50
mk 251 monitoring  768  8 51

3) الوسيط والنطاقات

نصّب Nginx Proxy Manager على 201 كما في الجزء السادس، ثم أضف مضيفاً لكل خدمة منشورة، ثم اطلب شهادة لكل واحد.

الأمان: سبع قواعد مطبَّقة لا منصوحاً بها

1) اعزل قاعدة البيانات تماماً

# تمنع قاعدة البيانات من الخروج إلى الإنترنت
iptables -A FORWARD -s 10.10.10.50 -o vmbr0 -j REJECT

# ولا تصل إليها إلا الخدمات التي تحتاجها
iptables -A FORWARD -d 10.10.10.50 -p tcp --dport 5432 -s 10.10.10.16 -j ACCEPT
iptables -A FORWARD -d 10.10.10.50 -p tcp --dport 5432 -j REJECT

قاعدة بيانات مخترقة لا تستطيع الخروج = تسريب محصور.

2) لوحات الإدارة عبر نفق لا عبر نطاق

ssh -L 8181:10.10.10.10:81 -L 3001:10.10.10.51:3000 [email protected]

3) قيّد SSH بالمصدر وبالمفاتيح

iptables -t nat -A PREROUTING -s 203.0.113.0/24 -d 82.39.115.50 \
  -p tcp --dport 2201 -j DNAT --to 10.10.10.11:22
# وداخل الحاوية: PasswordAuthentication no

4) حاويات غير مميّزة دائماً

--unprivileged 1 في كل حاوية. اختراق داخلها لا يعني اختراق المضيف.

5) شهادات وتحويل إجباري

فعّل Force SSL وBlock Common Exploits لكل مضيف.

6) قائمة وصول لما لا يحتاج الجمهور

في NPM: Access Lists لحماية dev.example.com وgit.example.com بكلمة مرور أو بقائمة عناوين.

7) حدّث كل شيء

for c in $(pct list | awk 'NR>1{print $1}'); do
  pct exec $c -- bash -lc 'apt-get update -qq && apt-get upgrade -y -qq' || true
done

النسخ الاحتياطي — الجزء الذي يُهمَل

# نسخة يومية لكل الحاويات عند الثالثة فجراً
vzdump 201 202 203 204 205 206 207 208 250 251 \
  --mode snapshot --compress zstd \
  --storage local --mailnotification failure

وضعها في Datacenter ← Backup من الواجهة أسهل. الأهم:

واحتفظ بنسخة خارج السيرفر: نسخة على القرص نفسه تحميك من خطأ بشري لا من فقدان الجهاز.

المراقبة: أن تعرف قبل أن يتصل الزبون

ثلاثة أشياء تكفي في البداية:

• توفّر الخدمات — فحص HTTP كل دقيقة لكل نطاق
• مساحة القرص — امتلاء القرص أشهر سبب لتوقّف الخدمات فجأة
• انتهاء الشهادات — الوسيط يجدّدها، لكن راقب أن التجديد يحدث فعلاً

# فحص بسيط لكل النطاقات
for d in www n8n api cloud git erp; do
  code=$(curl -s -o /dev/null -w "%{http_code}" -m 10 https://$d.example.com/)
  [ "$code" = "200" ] || echo "تنبيه: $d.example.com يعيد $code"
done

الموارد: ماذا تحتاج فعلاً؟

والقرص أهمّ ممّا يُظنّ: NVMe يغيّر إحساس كل شيء، لأن أغلب هذه الخدمات تقرأ وتكتب قواعد بيانات صغيرة باستمرار.

أخطاء شائعة في التشغيل الطويل

أسئلة شائعة

هل أستطيع بيع هذه البنية كاستضافة؟

نعم، وهي أساس أغلب الاستضافات الصغيرة. لكن احرص على عزل الزبائن: حاوية غير مميّزة لكل زبون، وقواعد FORWARD تمنع زبوناً من الوصول إلى شبكة زبون آخر.

ماذا لو احتجت سيرفراً ثانياً؟

المعمارية نفسها تتوسّع: كوّن كلاستر Proxmox، وأبقِ الوسيط على واحد، ووجّهه إلى خدمات على الآخر عبر الشبكة الخاصة بينهما.

وماذا عن High Availability؟

يحتاج ثلاثة نودات وتخزيناً مشتركاً — قفزة كبيرة في التكلفة والتعقيد. لا تفكّر فيها قبل أن يصبح التوقّف مكلفاً فعلاً.

كم يستغرق بناء كل هذا؟

يوم عمل واحد لمن قرأ السلسلة كاملة: الشبكة وNAT نصف ساعة، والوسيط نصف ساعة، وكل خدمة من 15 إلى 45 دقيقة.

ما أول شيء أفعله بعد الانتهاء؟

النسخ الاحتياطي، ثم اختبار الاسترجاع. قبل أن تضع أي بيانات حقيقية.

خاتمة السلسلة

بدأنا بسؤال بسيط: «عندي عنوان عام واحد، فكيف أشغّل عشرات الخدمات؟» وانتهينا ببنية كاملة: شبكة خاصة، وNAT للخروج، وتمرير منافذ لما ليس ويباً، ووسيط عكسي يوزّع حسب اسم النطاق، وشهادات تُدار نفسها، وCloudflare يخفي عنوانك ويحميه.

والفكرة التي تستحقّ أن تبقى: العنوان يحدّد الجهاز، والاسم يحدّد الخدمة. من فهم هذه الجملة لم يعد يحتاج شراء عنوان لكل موقع — إلى الأبد.

وإن أردت سيرفراً تبني عليه: اطّلع على باقات VPS — واسأل عن المعالج وعدد الأنوية ونوع التخزين، فهذه الثلاثة هي التي تحدّد كم خدمة يتحمّل سيرفرك فعلاً.