پرش به مطلب اصلی

نصب

WaterWall به‌صورت یک فایل اجرایی مستقل منتشر می‌شود؛ بنابراین به سرویس Package Manager، پایگاه داده یا Runtime جداگانه‌ای نیاز ندارید. کافی است نسخه‌ی مناسب سیستم‌عامل خود را دانلود کنید، فایل core.json را کنار فایل اجرایی بگذارید و برنامه را از همان دایرکتوری اجرا کنید.

بیشتر کاربران WaterWall را روی یک VPS لینوکسی اجرا می‌کنند. مدیریت فایل‌ها از یک سیستم Windows و از طریق SSH یا VS Code Remote SSH امکان‌پذیر است، اما دستورهای زیر باید روی خود سرور اجرا شوند.

دانلود​

آخرین نسخه را از صفحه‌ی Releaseهای WaterWall دانلود کنید. فایلی را انتخاب کنید که با سیستم‌عامل و معماری CPU شما سازگار باشد.

یک نصب دستی معمول در Linux به این شکل است:

mkdir -p ~/waterwall
cd ~/waterwall

# Put the downloaded archive or binary here, then extract it if needed.
chmod +x ./WaterWall

اگر فایل Release فشرده است، ابتدا آن را با ابزار متناسب، مانند tar، unzip یا 7z، از حالت فشرده خارج کنید.

ساختار دایرکتوری​

یک راه‌اندازی کوچک معمولاً چنین ساختاری دارد:

waterwall/
  WaterWall
  core.json
  configs/
    local-test.json
  logs/

WaterWall فایل core.json را از Working Directory پردازش می‌خواند. مسیرهای نوشته‌شده در core.json، از جمله فایل‌های آرایه‌ی configs، بدون تغییر به Loader داده می‌شوند؛ پس برنامه را آگاهانه از دایرکتوری درست اجرا کنید.

یک core.json حداقلی​

فایل core.json را کنار فایل اجرایی بسازید:

{
  "log": {
    "path": "logs/",
    "core": {
      "loglevel": "INFO",
      "file": "core.log",
      "console": true
    },
    "network": {
      "loglevel": "INFO",
      "file": "network.log",
      "console": true
    },
    "dns": {
      "loglevel": "INFO",
      "file": "dns.log",
      "console": true
    },
    "internal": {
      "loglevel": "INFO",
      "file": "internal.log",
      "console": true
    }
  },
  "misc": {
    "workers": 1,
    "ram-profile": "client",
    "mtu": 1500,
    "try-enabling-bbr": true,
    "libs-path": "libs/"
  },
  "dns": {
    "domain-strategy": "prefer-ipv4"
  },
  "configs": [
    "configs/local-test.json"
  ]
}

وجود آرایه‌ی configs الزامی است و این آرایه باید دست‌کم مسیر یک فایل پیکربندی را داشته باشد. بخش‌های دیگر اختیاری‌اند، اما نوشتن صریح تنظیمات misc باعث می‌شود رفتار Runtime روشن‌تر و قابل‌پیش‌بینی‌تر باشد.

زنجیره‌ی حداقلی برای آزمایش​

فایل configs/local-test.json را بسازید:

{
  "name": "local-test",
  "author": "waterwall-user",
  "config-version": 1,
  "core-minimum-version": 0,
  "nodes": [
    {
      "name": "listen-http",
      "type": "TcpListener",
      "settings": {
        "address": "127.0.0.1",
        "port": 8080
      },
      "next": "connect-example"
    },
    {
      "name": "connect-example",
      "type": "TcpConnector",
      "settings": {
        "address": "example.com",
        "port": 80
      }
    }
  ]
}

WaterWall را اجرا کنید:

cd ~/waterwall
./WaterWall

در ترمینالی دیگر، Listener محلی را آزمایش کنید:

curl -v http://127.0.0.1:8080/

اگر درخواست به example.com می‌رسد، فایل اجرایی، فایل Core، Config Loader، TcpListener، DNS Resolver و TcpConnector همگی درست کار می‌کنند.

اجرا روی VPS​

برای ارائه‌ی یک سرویس عمومی، Listenerها را روی یک آدرس عمومی یا Wildcard قرار دهید:

"address": "0.0.0.0"

سپس پورت را در Firewall سیستم‌عامل یا Cloud Firewall باز کنید. برای مثال، اگر روی پورت 443 گوش می‌دهید، هم Firewall سیستم‌عامل و هم Firewall شرکت ارائه‌دهنده باید اتصال ورودی TCP روی پورت 443 را مجاز بدانند.

استفاده از پورت‌های پایین‌تر از 1024 معمولاً به دسترسی Root یا قابلیتی مانند CAP_NET_BIND_SERVICE نیاز دارد. Nodeهای Packet-level مانند TunDevice نیز ممکن است به دسترسی بیشتری نیاز داشته باشند، زیرا Interface شبکه می‌سازند یا از آن استفاده می‌کنند.

مشکلات رایج​

core.json پیدا نمی‌شود: WaterWall را از دایرکتوری حاوی core.json اجرا کنید یا Working Directory را در Service Manager خود مشخص کنید.

فایل پیکربندی پیدا نمی‌شود: همه‌ی مسیرهای موجود در configs را بررسی کنید. مسیرهای نسبی معمولاً نسبت به Working Directory فعلی محاسبه می‌شوند.

خطای Permission denied: دستور chmod +x ./WaterWall را اجرا کنید. اگر پورت Listener کمتر از 1024 است، برنامه را با دسترسی لازم اجرا کنید یا برای آزمایش پورت بالاتری در نظر بگیرید.

پورت از قبل در حال استفاده است: در Linux با دستور ss -ltnp پردازشی را پیدا کنید که روی آن پورت TCP گوش می‌دهد.

Clientهای راه دور نمی‌توانند متصل شوند: آدرس Listener، Logهای WaterWall، Firewall لینوکس و Firewall شرکت ارائه‌دهنده را بررسی کنید. Listenerای که روی 127.0.0.1 قرار دارد فقط اتصال‌های محلی را می‌پذیرد.

نام دامنه Resolve نمی‌شود: بخش dns در core.json، به‌ویژه گزینه‌های servers و domain-strategy، را بررسی کنید و سپس Log موجود در logs/dns.log را ببینید.