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

ObfuscatorServer

ObfuscatorServer سمت مقابل ObfuscatorClient است. payload تغییرشکل‌داده‌شده را از سمت transport می‌گیرد، همان transform برگشت‌پذیر را اعمال می‌کند تا payload اصلی بازیابی شود، و پاسخ‌های برگشتی را دوباره obfuscate می‌کند.

در نسخه فعلی فقط روش xor پشتیبانی می‌شود.

جایگاه رایج​

TcpListener -> ObfuscatorServer -> TcpConnector

نمونه تنظیم​

{
  "name": "obfuscator-server",
  "type": "ObfuscatorServer",
  "settings": {
    "method": "xor",
    "xor_key": 90,
    "skip": "transport",
    "tls_record_header": true
  },
  "next": "service-node"
}

تنظیمات​

گزینهاجباریتوضیح
methodبلهفعلا فقط xor
xor_keyبله، وقتی method=xorکلید یک‌بایتی مشترک با client
skipخیرnone، ipv4 یا transport
tls_record_headerخیراضافه/حذف کردن header پنج‌بایتی شبیه TLS application-data در سمت transport

رفتار​

  • payload ورودی از سمت قبلی، بعد از حذف header اختیاری، XOR می‌شود و به next می‌رود.
  • payload برگشتی از next دوباره XOR می‌شود و اگر tls_record_header فعال باشد header پنج‌بایتی می‌گیرد.
  • lifecycle callbackها مثل init، finish، pause و resume بدون تغییر مفهوم عبور داده می‌شوند.

skip​

  • none: کل payload تغییر می‌کند.
  • ipv4: فقط IPv4 header clear می‌ماند.
  • transport: IPv4 header و TCP/UDP header clear می‌مانند.

این گزینه وقتی مفید است که payload شما packet خام است و می‌خواهید headerهای لازم برای routing یا injection قابل خواندن بمانند. اگر packet قابل parse نباشد، کل payload XOR می‌شود.

tls_record_header​

این گزینه فقط ظاهر record ایجاد می‌کند:

17 03 03 + length(2 bytes) + obfuscated payload

TLS واقعی، certificate، SNI یا handshake تولید نمی‌شود.

هشدار

اگر tls_record_header=true باشد، یک payload buffer باید در record حداکثر 65535 بایتی جا شود. payloadهای بزرگ‌تر drop می‌شوند.

نکته‌ها​

  • این نود را با ObfuscatorClient و تنظیمات یکسان استفاده کنید.
  • obfuscation جای encryption نیست.
  • اگر فقط stream معمولی دارید، skip: "none" ساده‌ترین حالت است.