۱. همونطور که میدونید جنگ فیلترینگ دیگه محدود به بستن IP یا پورت نیست، الان با داستان Pattern Matching و Heuristics طرفیم. سیستمهایی مثل GFW روی متادیتا و رفتار ترافیک (Behavioral Analysis) کار میکنن، یعنی دوران Encrypted Tunnel خالی تموم شده و عصر Traffic Shaping شروع شده
۲. مشکل پروتکلهای کلاسیک (مثل OpenVPN یا WireGuard) این بود که برای Obfuscation طراحی نشدن. این پروتکلها هدرهای مشخص و High Entropy دارن. DPI (بازرسی عمیق بسته) با یه نگاه به Handshake یا سایز پکتها، میفهمه این ترافیک نرمال وب (HTTPS) نیست و دراپش میکنه.
۳. وقتی اینطور شد کارایی مثل تونل کردن تروجان داخل TLS با مشکل TLS-in-TLS مواجه میشد یعنی وقتی یه استریم رمزنگاری شده رو دوباره رمز میکنی، الگوی سایز رکوردها و Timing تغییر میکنه، فایروال هم با Passive Analysis و بدون باز کردن بسته، میفهمه که یه چیزی داره ادای HTTPS رو درمیاره
۴. در واقع اینجا بود که XTLS از پروژهی Xray وارد بازی شد اینطوری که XTLS لایه اپلیکیشن و ترانسپورت رو ادغام میکنه. وقتی هندشیک تموم شد، ترافیک رو Direct Stream میکنه. نتیجه؟ پترن ترافیک دقیقاً مثل یک اتصال TLS خام و تکلایه به نظر میرسه.
۵. چالش بعدی موضوع SNI Whitelisting بود، فیلترچی پکت ClientHello تورو نگه میداره و SNI (نام دامنه) رو میخونه. اگه دامین توی لیست مجاز نباشه، کانکشن RST میشه ( مثل وقتی که ایکس رو با اینترنت عادی باز کنی )، یه بحثی هم بود دامین فرانتینگ که با دستکاری SNI میشد که الان نمیشه دیگه.
۶. بعد پروتکل REALITY اومد، که عملا نیاز به سرتیفیکیت معتبر روی سرور شما رو حذف میکنه. سرور شما نقش Man-in-the-Middle رو بازی میکنه و ServerHello یه سایت معتبر (مثل Microsoft یا Apple) رو میدزده و به کلاینت میده. برای ناظر میانی، شما خودِ اون سایت معتبر هستید.
۷. داستان بعدی کلاینت بود، اینطوری که فایروال ترتیب Cipher Suiteها و Extensionهای داخل پکت ClientHello رو چک میکنه. اگه کلاینت شما ،مثلا با Go نوشته شده باشه و پترن متفاوتی از کروم داشته باشه، شناسایی میشه. استفاده از کتابخونه uTLS باعث شد امضای کلاینت کاملا شبیه مرورگر بشه
۸. بعدش Active Probing مد شد، یعنی فایروال خودش یه ریکوئست فیک میفرسته سمت سرور شما. اگه سرور ارور بده یا الگوی خاص پروکسی رو برگردونه، IP بلاک میشه، پس کانفیگ درستی باید روی Fallback تنظیم بشه یعنی اگه کلاینت auth نشد، ترافیک رو فوروارد کنه روی یه سایت واقعی تا فایروال گول بخوره
۹. الان بهترین چیه؟
Xray Core + VLESS + XTLS-Vision + REALITY + uTLS
اینطوری RTT اضافه حذف میشه، وایتلیستینگ SNI فریب میخوره، جلوی Reply Attack ها خوب کار میکنه و طول پکت رو با padding هوشمند پنهان میکنه
۱۰. خلاصه هیچ دکمه قرمزی وجود نداره. ما مثل یه بازی موش و گربهی توی تله افتادیم و و الگوریتمهای ML فیلترینگ هم هر روز قویتر میشن.
بنظر من تکیه به پرووایدرهای تجاری ریسکه، راهکار پایدار برای کامیونیتی، Self-hosting روی VPS شخصی و درک عمیق این پروتکلهاست.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
۱/ یه چیز جالب اینکه لیندکدین بیشتر از ۱ میلیارد یوزر داره و میتونن ۴ ۵ میلیون کوئری رو زیر ۵ میلی ثانیه پاسخ بدن.
سیستم قدیمیشون که بر پایه dbms و server side caching بود توانایی مقیاسپذیری کمی داشت.
چی کار کردن؟
۲/اولین قدم اومدن از Espresso (دیتابیس NoSQL لینکدین) + کافکا استفاده کردن، چرا؟ برای پردازش میلیونها درخواست همزمان و آپدیت لحظهای بدون نیاز به مراجعه دائم به دیتابیس، چطوری؟ هر تغییر (مثل بستن اکانت) بلافاصله از طریق کافکا به تمام سرورها استریم میشه.
۳/ مشکل بعدیشون Memory Heap و تاخیرهای GC بود،چیکار کردن؟ اومدن از کلاینت DaVinci استفاده کردن چرا؟چون ذخیره داده در JVM Heap باعث مشکلات Garbage Collection و افزایش یهویی تاخیر میشد.
چطوری انجامش دادن؟ دادههارو به خارج از heap منتقل کردن (off-heap) که تاثیری روی GC نداشته باشه