gfw_resist_tls_proxy
gfw_resist_tls_proxy copied to clipboard
GFW-knocker
توسعه کد برای گولنگ و پورت به v2ray-core
یك کد ساده و پروتوتایپ برای گولنگ و در اینده برای v2ray-core https://github.com/Sina-Ghaderi/wayout
در کل مکانیزم کار ساده هست، یك سری تغییرات کوچیک دادم به جای یك فرگمنت ثابت کلاینت میتونه بازه اندازه تعریف کنه که بین x و y به صورت رندوم انتخاب بشه و سایز هر فرگمنت متغییر باشه..
اسلیپ تایم رو هم به همین شکل میتونه به صورت بازه زمانی در میلی ثانیه تعریف کنه که بصورت رندوم یك مقدار در این بازه برای هر فرگمنت انتخاب بشه..
کلاینت همچنین میتونه لیستی از ادرس های کلودفلر رو برای اتصال مشخص کنه که برای هر کانکشن به صورت رندوم انتخاب میشه.. میشه تو مراحل بعدی توسعه برای لیست ادرس های کلودفلر پریوریتی تعریف کنیم که بر اساس پینگ و سرعت سنجیده بشه..
در کل راهکار خوبیه اگرچه اتصال رو برقرار میکنه ولی latency رو به شدت افزایش میده، از اونجایی که ماهیت v2ray پروکسی هست و برای هر کانکشن نیاز به ارسال tls hello داره هر کانکشن دچار تاخیر ناشی از دور زدن DPI میشه، مگراینکه هسته v2ray رو تغییر بدیم، توی این حالت اگه از پایه یك vpn سرور با تکنیک های obfuscation شبیه به v2ray بنویسیم به نظرم ساده تر هست.. خصوصا چون کلاینت اندروید و ایفون هم باید کلا تغییر کنه و روی tun/tap سوار بشه.. اگر فرضا چنین سرویسی توسعه داده بشه هم مشکل تعداد کانکشن بالا و فیلتر شدن ایپی سرور حل میشه و هم مشکل لتنسی، چون عملا فقط یك کانکشن برای اتصال داریم و فقط یك tls hello برای استابلیش کردن تانل لایه ۳ لازم هست..
در اخر برای توسعه هسته v2ray میتونم مشارکت کنم، خوشحال میشم نظراتتون رو در مورد پروژه تانلینگ لایه ۳ بدونم، خودم استارتش کردم و با یك سری از دوستان در حال توسعه هستیم
https://github.com/Sina-Ghaderi/lib50cal
سلام خیلی تشکراز زحمت شما یک branch بزنم مخصوص go شما pull کنید بهش؟ یا میخواید تو پیج خودتون کار کنید؟
پرژه تانلینگ شما کار میکنه الان؟
درباره فیلتر شدن ایپی سرور شخصی از جاهای معروف وقتی ترافیک داشته باشه درجا بسته میشه حتی با یک کانکشن کلادفلر بسته نمیشه چون 30 درصد وبسایت ها پشتش اند
سلام ممنونم از وقتی که میزارید اساتید و کمکی که گردش آزاد اطلاعات و اینترنت ازاد میکنید. با استفاده از روش هایی که وجود داره، استفاده از وب ساکت، tls و استفاده از CDN کلادفلر، مشکلاتی که شاهد بودیم این بود که آیپی های کلادفلر که به عنوان آیپی تمیز پابلیش میشدند، بعد از مدتی تحت تاثیر اختلال های شبکه ای فیلترینگ میشدند، که این موضوع روی سرور های شخصی نیز با ایجاد ترافیک نزدیک به خارج از عرف سیستم فیلترینگ، موجب مسدودی و فیلترینگ کلی می شود. ممکن است استفاده از آیپی های کلادفلر در صورتیکه در وایت لیست فیلترینگ نباشد، در صورت استفاده عموم و ایجاد ترافیک سنگین مجددا شاهد اختلال شبکه ای لایه۳ روی آیپی ها باشیم. امیدوارم راهکار های هوشمندانه جهت دیتکت نشدن ایپی های destination با توجه به رفتار کاربر روی آیپی توسط شما اساتید ارائه بشه. ممنون.
تفاوتی نداره اگه branch بزنید بهتر هست
در مورد پروژه تانل فعلا اولای کار هستیم و اماده نیست، اگرچه تقریبا برای rfc ایده هایی مطرح شده، پروتکل برپایه ws قراره باشه که امکان مخفی کردن سرور پشت cdn هارو داشته باشه
بیشتر کار روی کلاینت هست که شامل obfuscation میشه، برای مثال utls و همین فرگمنتیشن و از بین بردن کانکشن و reestablish کردن پس از یك مدت زمان تصادفی و یا امکان مولتیپلکس کردن پکت های ip بین چند کانکشن ازبین بردن کانکشن مهم هست چون ممکنه dpi بتونه کانکشن هایی که در حالت idle هستن رو ترمینیت کنه، مولتیپلکس کردن پکت ها بین چند کانکشن tls با sni هایی که هر بار متفاوت (رندومایز کردن ساب دامین یا استفاده از چند دامین) هستن تشخیص و فیلترینگ دامنه ها رو سخت تر میکنه.. به طور کلی vpn بر پایه یك کانکشن زده میشه و بعدا با توجه به کانفیگ تعداد کانکشن ها به صورت تصادفی در یك بازه تعداد (برای مثال ۴ تا ۸) افزایش پیدا میکنه.. هرکدوم از این کانکشن ها هم بعد از یك مدت زمان تصادفی ترمینیت میشن و مجددا برقرار میشن، در همین حین بقیه کانکشن ها اکتیو هستن و نباید وقفه ای در ارتباط و دیتافلو پیش بیاد.. برای مولتیپلکس کردن پکت ها میشه از الگوریتم هایی شبیه به tcp یا quic استفاده کرد، هر پکت یك سیکوئنس نامبر داشته باشه و به ترتیب هر بسته شماره گذاری بشه و سمت گیرنده بر اساس شماره اسمبل بشن، اگر بسته ای نرسید یا گم شد مجددا توسط فرستنده ارسال بشه (شبیه به tcp retransmission) یا اگر بسته ای موفق رسید ack ش ارسال بشه برای ارسال کننده که از توی بافر حذفش کنه.. و الگوریتم ها و مکانیزم های دیگه ای که میشه از بقیه پروتکل ها پورت کرد
ایده جدیدی اگه هست یا اشکال و نقطه ضعفی وجود داره دوستان اشاره کنن..
در رابطه با فیلترینگ ایپی ها به نظرم track کردن ترافیک رد و بدل شده سخت تر هست تا شمردن تعداد کانکشن برثانیه.. در حال حاظر سرور های بیرون از ایران من ترافیك بالایی دارن ولی فقط از طریق یك کانکشن این ترافیك رد و بدل میشه و مشکلی پیش نیومده براشون، خصوصا اینکه سرور های زیادی هستن که دانلود ازشون زیاد هست، سرویس های هاست فایل ریپوزیتوری ها و غیره، اگرچه شاید ترکیبی از هردو(کانکشن و ترافیك) باشه یا واقعا فقط از روی ترافیک باشه، اگر بشه این موضوع رو تست کرد خیلی خوب میشه
اینطور که فیلترینگ عمل میکنه کلا آپلود بعضی آی پی های خارجی به ازای کاربر محدود کردن. اما اگه آپی تمیز باشه برای اینکه کثیف نشه یه راه حل هست باید پروتکل جدید نوشته بشه: اینکه آپلود و دانلود رو در دو کانال جدا چند کانال بفرستیم به طوری که مثلا یک یا چند ریکوئست فقط برای دیتا به از کاربر به سرور باشه مثل آپلود فایل رفتار کنه، و یک یا چند ریکوئست هم فقط برای دیتای سرور به کاربر باشه مثل دانلود فایل رفتار کنه. حالا اگه با پورت های مختلف و آی پی های مختلف کلودفلر توزیع بشه و نهایت به سرور شخصی برسه و اونجا اسمبل و مرتب سازی بشه. اینطوری برای فیلترچی یه سری ريکوئست آپلود و دانلود مجزا با آی پی های مختلف هست که تشخیصش از ترافیک معمولی بسیار سخت هست. حتی میشه با پورت 80 بدون tls دیتا رمزنگاری شده رو با هدر و استایل آپلود یا دانلود فایل ارسال کرد. چندین کانال آپلود و چندین کانال دانلود به صورت همزمان! @Sina-Ghaderi
@Sina-Ghaderi
جناب قادری برحسب تجربه کار با پروتکل های مختلف ، بهترین هایی که دیدم تا به حال openconnect یا همون ocserv و خود v2ray بوده . خوبی ocserv این هست که ماهیت پروکسی نداره و یک کانکشن برای اتصال کافی هست . الان بنده از پنل 3X-UI استفاده میکنم وقتی حتی یک کاربر هم وصله تعداد 150 تا کانکشن فعال به سرور زده میشه که خب شناسایی رو راحت میکنه . سوالم این هست که آیا راهی هست که توی xray عین ocserv ما با تعداد کمی کانکشن کار کنیم ؟ اگر بله از کجا باید این ویرایش انجام بشه و کانفیگش چطوری هست ؟ خوبی v2ray توی مخفی کردن TLS Fingerprint هست خصوصا با این قابلیت reality . اگر میشد یه ترکیبی از تک کانکشن بودن ocserv و قابلیت های xray داشت خیلی خوب میشد . یا اینکه مثلا کاری کنیم TLS به صورت persistent باشه و یه handshake برای کل کار کافی باشه . نظر شما چی هست؟
دقیقا باید پروتکل به همین شکل باشه، شبیه به AnyConnect بر بستر TLS باشه.. (البته anyconnect فقط برپایه TLS هست به همین دلیل نمیشه تحت وب سوکت پشت CDN قرار بگیره)
برای v2ray متاسفانه نمیشه کاری کرد مگر تغییر اساسی v2ray-core که به نظر من اگر از پایه نوشته بشه ساده تر هست.. همه تکنیك های obfuscation که در v2ray استفاده شده رو میشه روی پروتکل دیگه ای هم پیاده کرد.. برای مثال همین uTLS یك کتابخانه tls گولنگ هست که میتونید تو هرپروژه ای استفاده کنید..
تا جایی که میدونم اساس کار v2ray پروکسی کردن هر کانکشن سیستم به سمت سرور هست، فرضا یك تلفن همراه میتونه به تنهایی ۱۰۰ الی ۲۰۰ کانکشن فعال داشته باشه، درصورتی که در بستر تانل یك کانکشن فعال داریم با دیتای لایه 3 یا 2 بسته به نوع اینترفیس tun یا tap.. هرکانکشن tcp یا udp کلاینت بر بستر این تانل جابه جا میشه و درنهایت nat میشن که از بُعد پرفورمنس هم بهتر عمل میکنه..
@Sina-Ghaderi
بله دقیقا با توجه به شرایط کشور ما نیاز به پروتکل های اختصاصی برای ایران داریم . توی چین GFW اینقدر که اینجا محدودیت گذاشته ، محدودیت نداره . پس باید منتظر باشیم یکی از عزیزان اهل فن دست به کار بشن و یه سرویس جدید برای کشور خودمون اوکی کنن .
اینطور که معلومه شناسایی، بیشتر بر اساس الگوی رد و بدل شدن پکت تو یه کانکشن انجام میگیره و اینکه مجموعه کاربران، فقط با یک الگوی ارتباطی خاص رفتار میکنند! اینکه چند لایه رمزنگاری بشه تاثیری نداره، باید الگوی ارتباط رو طوری انتخاب کنیم که مخفی بمونه، بهترین راه حل اینه تا جایی که میشه کانکشن ها مشابه نت گردی عادی در بیاد تا تمایز دادنش سخت بشه. تا جایی که میشه از کانکشن هایی مثل websocket باید دوری کرد چون خیلی سریع شناسایی میشه، چون معمولا یه کاربر نت معمولی نمیتونه تعداد زیاد ws باز داشته باشه برای همین قابل شناسایی میشه، عموم کانکشن ها keep alive نیست یعنی ابتدا کلاینت یه هدری میفرسته بعد سرور دیتا رو میفرسته کانکشن بسته میشه، یا تو پست یا آپلود کلاینت هدر و دیتا رو میفرسته نهایت سرور پاسخ میده، اگه از این الگو تبعیت کنیم پیدا کردنش بین میلیونها کانکشن عادی بسیار سخت میشه، باید بریم سراغ ساده ترین نوع ارتباط مثل آپلود و دانلود فایل، چون عموما ارتباطات مردم keep alive نیست مثل لود کردن سایت.
نکته دیگه اینکه اگه زمان کانکشن زیاد باشه و زیاد باز بمونه معمولا آی پی ردیابی میشه، ظاهرا آی پی هایی که کانکشن هاشون سریع کلوز میشه رو تو لیست خاکستری نمیبرند، بالاخره محدودیت پردازش دارند، ما از این نکته باید استفاده کنیم، سعی کنیم کانکشن های کوتاه مدت باز کنیم.
برای مثال سایت parspack.com روی کلودفلر هست، ولی کافیه از آی پی اون برای v2ray استفاده کنید بعد از مدتی کانکشن لاست و کاهش سرعت دچار میشید ولی سایت parspack.com با همون آی پی سریع لود میشه!
@H320
توی XRAY میشه keepalive رو تایمش رو کم کرد زود kill کنه ؟ اطلاع کافی ندارم از این قضیه .
اون رو میدونم، فکر کنم منظورت بخش policy هست درسته؟ من اینارو تست کردم یکم کمک میکنه ولی اگه بخوایم پشت کلودفلر باشیم کثیف نشه باید روش جدید ابداع کنیم. کلا پروتکل های v2ray یا xray قابل شناسایی هستند چون الگو ارتباطیشون متفاوت از ترافیک عادی هست فقط trojan هست که یکم شبیه به ترافیک عادی رفتار میکنه و دیرتر شناسایی میشه، من همیشه از trojan استفاده میکنم. مابقی پروتکل ها سریع ردیابی میشه، واسه همین میگم کلا باید یه پروتکل جدید برای ایران نوشته بشه دقیقا شبیه ترافیک عادی رفتار کنه، کانکشن ها بیشتر از سه چهار ثانیه بر مبنای میزان ترافیک رد و بدل شده میره برای ردیابی!
@H320
درمورد اینکه عموم کانکشن ها keep alive نیست: مرورگر های امروزی وقتی یك کانکشن به یك سرور میزنن درصورتی که سرور اجازه بده (که دیفالت میده مگر به دلایل امنیتی محدود باشه) اون کانکشن تا مدت زمانی باز نگه داشته میشه برای استفاده مجدد برای همون هاست.. کروم و فایرفاکس رو با وایرشارک تست کردم قبلا به همین شکل تا مدت زمانی اکتیو میمونه کانکشن، حتی بعد از تموم شدن دیتای http ارسال شده از سرور!
حتی curl هم به همین شکل میتونه کانکشن ها رو در pool برای مدت زمانی اکتیو داشته باشه
و در مورد وب سوکت، وقتی ترافیک رمز باشه بر بستر tls شما چه تروجان بزنی چه وب سوکت و غیره.. وقتی رمز بشن دیگه تفاوتی ندارن چون از دید فایروال دیتا فقط دیتای tls هست..
خود v2ray هم میتونه کانکشن اکتیو داشته باشه و داره یادمون نره که v2ray پروکسی هست و تا زمانی که کانکشن پروکسی شده اکتیو باشه، کانکشن کلوز نمیشه.. برای مثال تلگرام رو درنظر بگیر وقتی کانکشن های تلگرام پروکسی میشن تا زمانی که اپ تلگرام و سرور کانکشن رو کلوز نکردن v2ray باید اون‌کانکشن ها رو اکتیو نگه داره..
میتونی یه نگا به این پروکسی ساده بندازی تا وقتی ارور یا eof نگیری حلقه for کارشو ادامه میده.. پس کانکشن اکتیو هست توی پروکسی هام اگه کانکشن هایی که پروکسی میکنه اکتیو باشه..
اینکه کانکشن باز بمونه مشکلی نیست اینکه بعد از اتمام دیتای http به طور غیرمعمول دیتا رد و بدل بشه میره برای رد گیری و کند شدن و فیلتر شدن! خود دیتا مهم نیست که چی باشه یا رمزگذاری شده باشه، اینکه دیتا چطور و به چه ترتیبی بین کلاینت و سرور رد و بدل میشه باعث شناسایی و کند شدن میشه. رفتار trojan با vless و vmess پشت ws کمی فرق داره برای هم دیرتر شناسایی میشه ولی در نهایت شناسایی میشه! واسه همین میگم الگوی ساده ای استفاده کنیم که عموم نت گردی بر این اساس هست تا تشخیص بسیار سخت بشه، مهم نیست چند لایه رمزگذاری بشه مهم رفتار کلاینت و سرور و ترتیب پاسخ گویی هست. مثل الگوی دانلود فایل یا آپلود فایل، وقتی یک فایلی رو دانلود میکنی ابتدا هدر request از کلاینت ارسال میشه بعدش سرور هدر response و دیتای فایل رو میفرسته اینجا کانشکن باز هست تا زمانیکه کلاینت کل دیتا رو دریافت کنه ولی دیگه دیتایی از سمت کلاینت ارسال نمیشه و یک طرفه میشه، توی آپلود هم هدر دیتا فایل پست میشه و سرور پاسخ میده و بعد کلوز میشه، در واقع ترتیب رد و بدل شدن دیتا مهمه، تو این حالت dpi تشخیص دانلود فایل یا آپلود ساده رو میده و با یه وب گردی ساده اشتباه میگیره. اگر ما سمت کلاینت یه کانکشن دو سویه داریم میتونیم تقسیمش کنیم به چندین کانکشن دانلود و آپلود ساده به صورت chunk به طور رندم بین یک یا چند آی پی کلودفلر تقسیمش کنیم در نهایت سمت سرور شخصی تجمیعش کنیم، بیشتر پروکسی مثل یک wrapper عمل کنه
اینکه کانکشن باز بمونه مشکلی نیست اینکه بعد از اتمام دیتای http به طور غیرمعمول دیتا رد و بدل بشه میره برای رد گیری و کند شدن و فیلتر شدن! خود دیتا مهم نیست که چی باشه یا رمزگذاری شده باشه، اینکه دیتا چطور و به چه ترتیبی بین کلاینت و سرور رد و بدل میشه باعث شناسایی و کند شدن میشه. رفتار trojan با vless و vmess پشت ws کمی فرق داره برای هم دیرتر شناسایی میشه ولی در نهایت شناسایی میشه! واسه همین میگم الگوی ساده ای استفاده کنیم که عموم نت گردی بر این اساس هست تا تشخیص بسیار سخت بشه، مهم نیست چند لایه رمزگذاری بشه مهم رفتار کلاینت و سرور و ترتیب پاسخ گویی هست. مثل الگوی دانلود فایل یا آپلود فایل، وقتی یک فایلی رو دانلود میکنی ابتدا هدر request از کلاینت ارسال میشه بعدش سرور هدر response و دیتای فایل رو میفرسته اینجا کانشکن باز هست تا زمانیکه کلاینت کل دیتا رو دریافت کنه ولی دیگه دیتایی از سمت کلاینت ارسال نمیشه و یک طرفه میشه، توی آپلود هم هدر دیتا فایل پست میشه و سرور پاسخ میده و بعد کلوز میشه، در واقع ترتیب رد و بدل شدن دیتا مهمه، تو این حالت dpi تشخیص دانلود فایل یا آپلود ساده رو میده و با یه وب گردی ساده اشتباه میگیره. اگر ما سمت کلاینت یه کانکشن دو سویه داریم میتونیم تقسیمش کنیم به چندین کانکشن دانلود و آپلود ساده به صورت chunk به طور رندم بین یک یا چند آی پی کلودفلر تقسیمش کنیم در نهایت سمت سرور شخصی تجمیعش کنیم، بیشتر پروکسی مثل یک wrapper عمل کنه
این شبیه چیزیه که گفتی @sambali9
اینکه کانکشن باز بمونه مشکلی نیست اینکه بعد از اتمام دیتای http به طور غیرمعمول دیتا رد و بدل بشه میره برای رد گیری و کند شدن و فیلتر شدن! خود دیتا مهم نیست که چی باشه یا رمزگذاری شده باشه، اینکه دیتا چطور و به چه ترتیبی بین کلاینت و سرور رد و بدل میشه باعث شناسایی و کند شدن میشه. رفتار trojan با vless و vmess پشت ws کمی فرق داره برای هم دیرتر شناسایی میشه ولی در نهایت شناسایی میشه! واسه همین میگم الگوی ساده ای استفاده کنیم که عموم نت گردی بر این اساس هست تا تشخیص بسیار سخت بشه، مهم نیست چند لایه رمزگذاری بشه مهم رفتار کلاینت و سرور و ترتیب پاسخ گویی هست. مثل الگوی دانلود فایل یا آپلود فایل، وقتی یک فایلی رو دانلود میکنی ابتدا هدر request از کلاینت ارسال میشه بعدش سرور هدر response و دیتای فایل رو میفرسته اینجا کانشکن باز هست تا زمانیکه کلاینت کل دیتا رو دریافت کنه ولی دیگه دیتایی از سمت کلاینت ارسال نمیشه و یک طرفه میشه، توی آپلود هم هدر دیتا فایل پست میشه و سرور پاسخ میده و بعد کلوز میشه، در واقع ترتیب رد و بدل شدن دیتا مهمه، تو این حالت dpi تشخیص دانلود فایل یا آپلود ساده رو میده و با یه وب گردی ساده اشتباه میگیره. اگر ما سمت کلاینت یه کانکشن دو سویه داریم میتونیم تقسیمش کنیم به چندین کانکشن دانلود و آپلود ساده به صورت chunk به طور رندم بین یک یا چند آی پی کلودفلر تقسیمش کنیم در نهایت سمت سرور شخصی تجمیعش کنیم، بیشتر پروکسی مثل یک wrapper عمل کنه
ایده اینکه کانکشن ها تقسیم بشن ممکنه جواب بده ولی خب عملا یه چالش جدید برای GFW حساب میشه. وقتی بخوان روی چند کانکشنی بودن پروکسی ها تمرکز کنن راه های دیگه برای شناسایی پیدا میکنن. همون طور که اولش ws+tcp کار میکرد ولی الان tls به زور کار میکنه. اینجا چندتا نکته مهمه: ۱. خیلی از سایتا و برنامه ها ازhttp2 استفاده میکنن که داخل تنها یک کانکشن چندبار پیام ردو بدل میشه. ۲. یکی از دلایل تشخیص ws اینه که بعد از tls handshake عملا یه ws handshake هم هست که تشخیصش راحته و اگه زمان و سایز پکت ها رو انالیز کنیم شناسایی میشه.(ایرانسل هم چند وقتی هست ws روی آیپی های کلادفلر رو بسته) اما با fragment کردن پکت های ws handshake ممکنه بشه این قضیه رو دور زد. ۳. اینکه به چندتا آیپی کلادفلر کانکت بشیم شاید گزینه خوبی باشه ولی بعید میدونم جوابگو باشه چون بازم دامنه ها یکی هستن پس امکان شناسایی هست. اگر هم چندتا دامنه جدا باشن باز به دلیل اینکه افراد کمی به اون دامنه ها وصل میشن و ترافیک خیلی زیادی داره سمتشون میره٬ ممکنه باز دامنه ها فیلتر بشن. ۴. یه سری تشخیص ها هم مربوط به پرتکل هستش. مثلا خیلی از پرتکل ها در برابر tls in tls ایمن نیستن و این یکی از دلایل بسته شدنشونه
