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

TlsClient

📖 معرفی کلی

ویژگیمقدارتوضیح
نوع نودTunnel (تک‌جهته)کانکشن‌ها از چپ آغاز شده و به راست پیش می‌روند
لایه شبکهلایه ۴ (Transport Layer)کار با کانکشن‌ها، نه بسته‌های خام
موقعیت در زنجیروسط زنجیرفقط در میانه زنجیر قابل استفاده است
وابستگینود قبل/بعدبرای دریافت/ارسال داده ضروری است

عملکرد

این نود یک کلاینت برای پروتکل TLS است که توانایی شبیه‌سازی رفتار مرورگر Google Chrome را در انجام هندشیک دارد.

این کار کمک می‌کند سیستم‌های فیلترینگ متوجه نشوند که یک برنامه غیرمرورگر در حال هندشیک است.

سرور مقصد نیز تشخیص نمی‌دهد که ما مرورگر نیستیم و معمولاً کپچا نمایش نمی‌دهد؛ در حالی‌که اگر با curl متصل شوید ممکن است کپچا نمایش داده شود.

هش کنونی JA4 که توسط این نود تولید می‌شود:

JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd

این مقدار در زمان ساخت نود با نسخه زیر از Chrome بررسی شده است:

Chrome Version 138.0.7204.184 (Official Build) (64-bit)


⚙️ راهنمای پیکربندی

{
"name": "node_name",
"type": "TlsClient",
"settings": {
"sni": "mydomain.com"
},
"next": "next_node_name"
}

تنها تنظیم قابل تغییر sni است که باید به دامنه مقصد اشاره کند؛ سایر مشخصات TLS به‌صورت خودکار تولید و تنظیم می‌شوند.

نکته

این نود باید در ادامه به یک TlsServer برسد تا هندشیک انجام شود.

نکته برای برنامه‌نویسان

اگر قصد اتصال به Cloudflare یا وب‌سایت‌های عادی را دارید، نود قبلی باید از HTTP/2 پشتیبانی کند.

Google Chrome پیاده‌سازی پیچیده‌ای دارد و تنظیمات HTTP/2 (Settings Frame) را در فرآیند ClientHello/TLS لحاظ می‌کند؛ بنابراین ما نیز مجبور به افزودن آن بودیم. در نتیجه پس از پایان هندشیک، مقداری بایت از این نود به نود قبلی بازگردانده می‌شود و این موضوع مستقل از آن است که سرور مقصد واتروال باشد یا وب‌سایتی مانند Cloudflare.

در حال حاضر نود TlsClient این بایت‌های ابتدایی را حذف می‌کند و به نود قبلی تحویل نمی‌دهد تا سازگاری حفظ شود. بنابراین اگر نود قبلی شما HTTP/2 است، باید شبیه‌سازی لازم را انجام دهد؛ به‌گونه‌ای که گویی Settings Frame ارسال و پاسخ آن دریافت شده است. تلاش کنید تنظیمات دقیقاً مطابق چیزی باشد که Chrome Network Stack برای HTTP/2 در نظر می‌گیرد. بایت‌های مربوط به Settings Frame در کد قابل مشاهده هستند.