جميع المقالات

نشر بنية تحتية لشبكة VPN متعددة الخوادم باستخدام RemnaWave: 10 خوادم وتطبيق «الخادم الأفضل»

vpndevopsremnawavevlessrealityhysteria2dockerlinuxnetworking

نشر بنية تحتية لشبكة VPN متعددة الخوادم باستخدام RemnaWave: 10 خوادم وتطبيق «الخادم الأفضل»

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

يستعرض هذا الدليل بالتفصيل عملية بناء شبكة VPN متكاملة وموزعة بالاعتماد على RemnaWave Panel عبر عنقود يضم 10 خوادم موزعة جغرافياً (ألمانيا، هولندا، لاتفيا، التشيك، السويد، فنلندا، والولايات المتحدة)، مع دعم بروتوكولات VLESS + REALITY و Hysteria 2، وتطبيق ميزة «⚡ أفضل خادم» (الفحص الديناميكي التلقائي والتحويل السلس عند الأعطال).

1. المعمارية الهيكلية للعنقود الموزع

تعتمد البنية على فصل تام بين خادم الإدارة (Master) وخوادم معالجة البيانات (Workers):

[ Master Server: RemnaWave Panel ]
  (واجهة الويب، واجهة REST API، قاعدة PostgreSQL 16، تخزين Redis، محرك الاشتراكات)
       │
       ├── gRPC / TLS (نفق تحكم مشفر وآمن)
       │
       ├── Worker 1: ألمانيا - 1 (VLESS REALITY)
       ├── Worker 2: ألمانيا - 2 (VLESS REALITY)
       ├── Worker 3: ألمانيا - 3 (VLESS REALITY)
       ├── Worker 4: هولندا - 1 (VLESS REALITY)
       ├── Worker 5: هولندا - 2 (VLESS REALITY + Hysteria 2)
       ├── Worker 6: ريغا / لاتفيا (VLESS REALITY)
       ├── Worker 7: براغ / التشيك (VLESS REALITY)
       ├── Worker 8: السويد (VLESS REALITY)
       ├── Worker 9: فنلندا (VLESS REALITY)
       └── Worker 10: أمريكا / الولايات المتحدة (VLESS REALITY)
المكون الدور في النظام حزمة التقنيات
خادم الإدارة (Master Panel) إدارة المستخدمين، الفوترة، مراقبة العقد، توليد الاشتراكات Docker, RemnaWave, PostgreSQL, Redis, Caddy
خوادم العقد (Workers 1–10) استقبال حركة البيانات وتمريرها RemnaWave Node Daemon, Xray-core, Sing-box
بروتوكول VLESS + REALITY البروتوكول الأساسي المموه كحركة TLS 1.3 شرعية TCP, XTLS Reality, X25519, SNI Camouflage
بروتوكول Hysteria 2 بروتوكول UDP عالي السرعة للشبكات غير المستقرة UDP, Salamander Obfuscation, BBR Congestion Control
العقدة الافتراضية «أفضل خادم» اختيار تلقائي للخادم الأقل تأخيرًا وبدون فقدان للحزم Client-side URL-Test / Fallback Proxy Group

2. إعداد خادم الإدارة الرئيسي (RemnaWave Panel)

لا يتعامل الخادم الرئيسي مع حركة بيانات التصفح، بل يقتصر دوره على التوثيق ومزامنة الإعدادات وتوزيع روابط الاشتراك لتطبيقات العملاء (Happ و v2rayN و Sing-box و Clash و Streisand).

الخطوة 2.1. تهيئة النظام وتثبيت المتطلبات

على خادم نظيف يعمل بنظام Ubuntu 24.04 LTS، يتم تثبيت Docker والأدوات المساعدة:

apt update && apt upgrade -y
apt install -y curl ufw git jq

# تثبيت Docker و Docker Compose
curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

ضبط الجدار الناري (UFW):

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 3000/tcp
ufw enable

الخطوة 2.2. إعداد ملف Docker Compose لـ RemnaWave

إنشاء المجلد وملف الإعداد:

mkdir -p /opt/remnawave && cd /opt/remnawave

الملف /opt/remnawave/docker-compose.yml:

version: '3.8'

services:
  remnawave:
    image: remnawave/backend:latest
    container_name: remnawave-panel
    restart: always
    ports:
      - '3000:3000'
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://remna:secure_db_pass@postgres:5432/remnawave
      - REDIS_URL=redis://redis:6379
      - JWT_SECRET=super_secret_jwt_key_random_generated_string_here
      - APP_PORT=3000
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16-alpine
    container_name: remnawave-postgres
    restart: always
    environment:
      POSTGRES_USER: remna
      POSTGRES_PASSWORD: secure_db_pass
      POSTGRES_DB: remnawave
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    container_name: remnawave-redis
    restart: always
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

الخطوة 2.3. تشغيل الخدمات وتهيئة Caddy كخادم وسيط

تشغيل الحاويات:

docker compose up -d

تثبيت Caddy للحصول التلقائي على شهادات SSL وإعادة التوجيه الآمن:

apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

الملف /etc/caddy/Caddyfile:

panel.yourdomain.com {
    reverse_proxy localhost:3000
}

بعد إعادة التشغيل (systemctl restart caddy) تصبح لوحة التحكم متاحة عبر HTTPS.

3. ربط خوادم العقد الـ 10 وضبط أداء النواة

تعمل كل عقدة على خادم VPS مستقل بسرعة منفذ 1 غيغابت/ثانية. ولضمان أقصى كفاءة، يتم تحسين نواة لينكس مسبقًا.

الخطوة 3.1. تحسين نواة لينكس وتفعيل خوارزمية TCP BBR

على كل خادم، يتم تعديل إعدادات الشبكة في /etc/sysctl.conf:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192

تطبيق التعديلات فوراً:

sysctl -p

الخطوة 3.2. تشغيل وكيل العقدة RemnaWave Node Daemon

على كل خادم فرعي، يتم تشغيل الحاوية الخفيفة:

mkdir -p /opt/remnawave-node && cd /opt/remnawave-node

الملف /opt/remnawave-node/docker-compose.yml:

version: '3.8'

services:
  node:
    image: remnawave/node:latest
    container_name: remnawave-node
    restart: always
    network_mode: host
    environment:
      - PANEL_URL=https://panel.yourdomain.com
      - NODE_SECRET_TOKEN=unique_node_token_generated_in_panel
      - PORT=2053

تشغيل الوكيل:

docker compose up -d

تظهر العقدة فورًا في اللوحة بحالة Connected وتعرض مؤشرات زمن الاستجابة واستهلاك الذاكرة وحجم الترافيك.

4. إعداد البروتوكولات: VLESS REALITY و Hysteria 2

4.1. تكوين بروتوكول VLESS-TCP-REALITY

يوفر REALITY تمويهاً كاملاً: حيث يرى المراقب الخارجي مصافحة TLS 1.3 حقيقية مع مواقع ومخدمات عالمية موثوقة (SNI).

  1. توليد مفاتيح X25519: تولد اللوحة زوج المفاتيح (Private Key / Public Key) ومعرف Short ID (مثل 16a8d0ef).
  2. اختيار نطاق التمويه (Target SNI): اختيار خوادم تدعم TLS 1.3 و HTTP/2 قريبة جغرافياً (مثل gateway.icloud.com و dl.google.com و swdist.apple.com و www.microsoft.com).
  3. المنفذ: 443/TCP.

4.2. إعداد Hysteria 2 (UDP) على عقدة هولندا-2

للشبكات التي تعاني من فقدان الحزم، يتم تفعيل Hysteria 2 على عقدة هولندا - 2:

  • البروتوكول: Hysteria 2 (QUIC / UDP).
  • المنفذ: 443/UDP (أو نطاق 20000-50000/UDP).
  • التمويه: كلمة مرور Salamander.
  • شهادة SSL معتمدة أو ذاتية التوقيع.

5. تحليل عميق: كيف تعمل ميزة «⚡ أفضل خادم»

يظهر للمستخدمين في أعلى القائمة عقدة افتراضية باسم «⚡ أفضل خادم». هذه ليست خادماً فيزيائياً مستقلاً، بل مجموعة اختبار تلقائي وتبديل سلس في تطبيق العميل (URL-Test / Smart Failover).

                  ┌── [ فحص: http://gstatic.com/generate_204 ] ──┐
                  │                                               │
[ حركة المرور ] ──> [ مجموعة URL-Test: ⚡ أفضل خادم ] ────────────┤
                                                                  ├──> ألمانيا-1 (الاستجابة: 42ms)  [نشط]
                                                                  ├──> ألمانيا-2 (الاستجابة: 45ms)
                                                                  ├──> هولندا-1 (الاستجابة: 48ms)
                                                                  ├──> ريغا (الاستجابة: 62ms)
                                                                  └──> أمريكا (الاستجابة: 128ms)

آلية عمل الفحص التلقائي والتبديل السلس

  1. إرسال حزم الفحص الدوري (Probing): يرسل تطبيق العميل (Happ أو Sing-box أو Clash) طلبات HTTP GET خفيفة عبر الخوادم العشرة إلى نقطة فحص معيارية (http://www.gstatic.com/generate_204) كل 300 ثانية.
  2. حساب زمن الاستجابة ونسبة الفقدان: يقيس التطبيق زمن الرحلة ذهاباً وإياباً (RTT) ونسبة نجاح الحزم.
  3. توجيه حركة البيانات للخادم الأسرع: يتم توجيه الاتصال مباشرة إلى الخادم صاحب أقل تأخير (مثل ألمانيا - 1 بتأخير 42 ملي ثانية).
  4. التبديل التلقائي عند العطل (Failover): إذا توقف الخادم النشط عن الاستجابة، يقوم التطبيق بتحويل الجلسات فوراً إلى الخادم الاحتياطي التالي (ألمانيا - 2) دون انقطاع الاتصال ودون أي تدخل يدوي من المستخدم.

بنية المجموعة في ملف الاشتراك (Sing-box / Clash Meta)

يولد نظام RemnaWave المقطع التالي في ملف التكوين:

{
    "tag": "⚡ أفضل خادم",
    "type": "urltest",
    "outbounds": [
        "ألمانيا",
        "ألمانيا - 2",
        "ألمانيا - 3",
        "ريغا",
        "براغ",
        "هولندا - 1",
        "هولندا - 2",
        "السويد",
        "فنلندا",
        "أمريكا"
    ],
    "url": "http://www.gstatic.com/generate_204",
    "interval": "5m",
    "tolerance": 50,
    "idle_timeout": "30m"
}

يمنع خيار tolerance: 50 التبديل المستمر بين خوادم متقاربة جداً في زمن الاستجابة، مما يحافظ على استقرار جلسات TCP والمكالمات الصوتية.

6. مزامنة الاشتراكات والتحديث التلقائي

  1. فترة التحديث التلقائي: يرسل خادم الاشتراكات رأس profile-update-interval: 12 لتوجيه التطبيقات لتحديث قائمة الخوادم والمفاتيح كل 12 ساعة.
  2. بيانات الرصيد والصلاحية: يتم إرسال ترويسة Subscription-Userinfo لعرض تفاصيل الاستهلاك (كما في الواجهة: 678GB / ∞ وصالح حتى 25.05.2027).
  3. توسيع العنقود دون توقف: عند إضافة خادم حادي عشر في لوحة التحكم، يصل الخادم الجديد تلقائياً لجميع المستخدمين في التحديث التالي وينضم مباشرة لحوض فحص الخادم الأفضل.

7. الخلاصات الهندسية

  1. عزل الإدارة عن معالجة الترافيك: يضمن بقاء نظام إدارة الاشتراكات فعالاً حتى في حال توقف بعض خوادم التمرير.
  2. تكامل بروتوكولات TCP و UDP: يجمع بين التمويه العالي لـ VLESS REALITY والسرعة الفائقة لـ Hysteria 2 تحت ظروف فقدان الحزم.
  3. مجموعات URL-Test كمعيار لتجربة المستخدم: تحول البنية التحتية المعقدة إلى اتصال سلس وموثوق لا يتطلب أي إدارة يدوية من العميل.