44 subscribers
30 photos
22 videos
2 files
42 links
Freedom through power. Power through intelligence.| voidNetwork.ir
Download Telegram
Red Hat Enterprise Linux (RHEL) کلاس enterprise را نمایندگی می‌کند. مستند سیاست چرخهٔ حیات RHEL برای نسخه‌های ۸، ۹ و ۱۰ چرخهٔ ۱۰ سالهٔ Full Support و Maintenance Support را اعلام می‌کند، و Red Hat حتی برای برخی سناریوها Extended Life Cycle تا ۱۴ سال را هم ارائه کرده است. این مدل برای سازمان‌هایی که ثبات، پشتیبانی قراردادی، و مهاجرت‌های برنامه‌ریزی‌شده می‌خواهند، از نظر مهندسی بسیار معنی‌دار است.

چرا بعضی انتخاب‌ها «خوب نیستند»

بدیِ یک توزیع معمولاً مطلق نیست؛ بد بودن وقتی رخ می‌دهد که مدل توزیع با نیاز واقعی تو هم‌راستا نباشد. برای مثال، rolling release برای کسی که هر روز سیستم را نگه‌داری می‌کند و snapshot/rollback و حوصلهٔ مطالعه دارد، عالی است؛ اما برای تیمی که downtime گران است و تغییرات باید از قبل آزموده و زمان‌بندی شوند، مدل rolling می‌تواند ریسک عملیاتی اضافه کند. این نتیجه‌گیری از خودِ فلسفهٔ Arch و Tumbleweed و در برابر مدل‌های چرخه‌دار مثل Debian/Ubuntu/RHEL به‌دست می‌آید.

برعکس، انتخاب یک توزیع بسیار محافظه‌کار برای کسی که سخت‌افزار جدید، درایور تازه، گرافیک نو، یا ابزارهای توسعهٔ جدید می‌خواهد، می‌تواند به معنی «عقب ماندن از اکوسیستم» باشد. Fedora با چرخهٔ سریعش دقیقاً برای همین شکاف طراحی شده، و Arch/Tumbleweed هم با هدف رساندن بسته‌های جدیدتر وارد عمل می‌شوند. بنابراین انتخاب Debian Stable یا RHEL برای یک workstation که نیازمند آخرین toolchain یا driver است، از نظر نیازمندی فنی ممکن است انتخاب ضعیفی باشد، حتی اگر از نظر پایداری عالی باشد.

یک خطای رایج دیگر این است که توزیع را فقط بر اساس «معروف بودن» انتخاب کنیم. شهرت لزوماً معادل تناسب نیست. Ubuntu به‌خاطر اکوسیستم و LTS عالی است، Debian برای پایداری ممتاز است، Fedora برای تکنولوژی جدید عالی است، Arch برای کنترل و یادگیری عمیق است، Tumbleweed برای rolling پایدارتر عالی است، و RHEL برای سازمان‌ها تقریباً یک معیار صنعتی است. هیچ‌کدام «بهترینِ مطلق» نیستند؛ بهترین، تابعِ workload، تیم، و سطح تحمل ریسک است.

باورهای غلطِ خیلی رایج

یکی از مهم‌ترین سوءبرداشت‌ها این است که «لینوکس همان کرنل است، پس هر توزیعی یکی است». در واقع توزیع‌ها از نظر چرخهٔ انتشار، سیاست پشتیبانی، بسته‌بندی، کرنل توزیعی، و حتی تجربهٔ نگه‌داری تفاوت‌های عمیق دارند. kernel.org هم صریحاً میان upstream kernel و kernelهای توزیعی تمایز می‌گذارد.

باور غلط دوم این است که «rolling release یعنی unstable». این گزاره دقیق نیست. rolling release فقط یعنی انتشار نقطه‌ای و نسخه‌محورِ کلاسیک نداری؛ اما کیفیت می‌تواند از بسیار خوب تا ضعیف متغیر باشد. Tumbleweed با تست‌های گسترده و snapshot/rollback rolling را با انضباط عملیاتی ترکیب می‌کند، و Arch هم هرچند rolling است، خود را یک نصب یک‌باره با آپدیت دائمی معرفی می‌کند، نه یک سیستم بی‌قانون.

باور غلط سوم این است که «توزیع‌های enterprise کند و مرده‌اند». برعکس، فلسفهٔ آن‌ها این است که patch و backport و lifecycle بلند داشته باشند تا زیر بار production قابل اتکا بمانند. چرخهٔ ۱۰سالهٔ RHEL و ۵سالهٔ Debian stable و ۱۰سالهٔ Ubuntu LTS دقیقاً برای همین ساخته شده‌اند: نه برای هیجانِ نو بودن، بلکه برای پیش‌بینی‌پذیری و کاهش هزینهٔ تغییر.

باور غلط چهارم این است که «Fedora فقط یک بتاست». Fedora واقعاً fast-moving است، اما از نظر فرایند انتشار، چرخهٔ مشخص، نگه‌داری رسمی، و طول عمر قابل‌تعریف دارد. فرقش با توزیع‌های محافظه‌کار این نیست که «ناتمام» است؛ فرقش این است که عمداً در مرزِ جدیدتر بودن حرکت می‌کند.

جمع‌بندی کاربردی

اگر هدف سرور پایدار و کم‌دردسر است، Debian Stable، Ubuntu LTS، RHEL، و در دنیای openSUSE، Leap انتخاب‌های منطقی‌اند. اگر هدفت دسکتاپ مدرن با اکوسیستم بزرگ است، Ubuntu LTS و Fedora معمولاً انتخاب‌های خیلی خوبی‌اند. اگر هدف تجربهٔ به‌روزِ عمیق، کنترل کامل، و یادگیری جدی است، Arch یا Tumbleweed منطقی‌ترند. و اگر هدفت چرخهٔ حیات طولانی و پشتیبانی سازمانی است، RHEL و Ubuntu LTS و Debian Stable در صدر قرار می‌گیرند. این‌ها رتبه‌بندی مطلق نیستند؛ نقشهٔ تناسب‌اند.

کرنل همان موتور است، توزیع همان شاسی و سیاست رانندگی؛ و «بهترین» همیشه یعنی مناسب‌ترین برای مسیر، نه قدرتمندترین روی کاغذ.
∆ Join VOID
3
در کل نباید بر سیستم ها و ابزار ها تعصب داشت
آنها توسعه دیدن که مورد استفاده قرار گیرند و نیازی به تعصب ندارند
خوده بنده به شخصه ویندوز و گاها ارچ استفاده میکنم
3
part ۰
شبکه (Networking)
در مدل مرجع OSI، داده‌ها از لایه کاربرد (مانند HTTP، DNS) به ترتیب به لایه‌های انتقال (TCP/UDP)، شبکه (IP)، پیوند داده (Ethernet) و فیزیکی منتقل می‌شوند. برای مثال یک بسته HTTP ابتدا در لایه کاربرد ساخته شده، در لایه انتقال با سرآیند TCP یا UDP کپسوله می‌شود، سپس در لایه شبکه آدرس‌دهی IP می‌گردد، در لایه پیوند داده فریم Ethernet (یا Wi-Fi) را تشکیل می‌دهد و در نهایت به صورت سیگنال الکتریکی یا نوری منتقل می‌شود. به صورت ساده می‌توان این مسیر را نمایش داد:
diff

+-----------------------------+
| لایه کاربرد (HTTP, DNS...) |
+-----------------------------+
| لایه انتقال (TCP/UDP) |
+-----------------------------+
| لایه شبکه (IP) |
+-----------------------------+
| لایه پیوند داده (فریم‌ها) |
+-----------------------------+
| لایه فیزیکی (بیت‌ها) |
+-----------------------------+

در مدل TCP/IP کاربردی هم مشابه عمل می‌کند با لایه‌های کاربرد، انتقال و اینترنت (معادل IP) و لایه لینک. تفاوت اصلی در مدل OSI، وجود لایه‌های «ارائه» و «نشست» است که در TCP/IP ادغام شده‌اند. بسته (Packet) به واحد داده در لایه شبکه (IP Packet) و فریم (Frame) به واحد داده در لایه پیوند (مثلاً Ethernet) گفته می‌شود. در مسیر یابی (Routing)، روترها با بررسی آدرس‌های IP مقصد، بسته‌ها را بین شبکه‌ها هدایت می‌کنند. سوئیچینگ (Switching) در لایه پیوند داده عمل می‌کند و بر اساس آدرس‌های MAC فریم‌ها، داده را درون شبکه محلی جابه‌جا می‌کند.
NAT/CGNAT: ترجمه آدرس شبکه (NAT) تکنیکی است که در لایه شبکه اجرا می‌شود تا چند میزبان خصوصی پشت یک آدرس IP عمومی قرار گیرند. CGNAT (NAT همزمان با گستره بزرگ) نسخه‌ای از NAT است که در مقیاس اپراتورهای اینترنتی به کار می‌رود و چند هزار کاربر را پشت آدرس‌های محدود IPv4 مشترک می‌کند. این فرایند شامل بازنویسی آدرس و پورت در سرآیند بسته‌ها است و باعث می‌شود بسته‌های بازگشتی به میزبان صحیح هدایت شوند. BGP: پروتکل مسیریابی مرزها (BGP) پروتکل اصلی تبادل اطلاعات مسیریابی بین شبکه‌های بزرگ (AS) است. هر مسیریاب BGP فهرست پیشوندهای IP که می‌تواند به آنها برسد و AS راهنمای آنها را به روترهای همسایه اعلام می‌کند. جدول مسیریابی BGP، مسیر بهینه را بر اساس سیاست‌ها، طول مسیر و سایر معیارها انتخاب می‌کند.
DNS: سامانه نام دامنه (DNS) نام‌های متنی (مثلاً example.com) را به آدرس‌های IP متناظر تبدیل می‌کند. در شبکه‌های امروزی، انواع جدیدی از DNS رمزنگاری‌شده رایج شده‌اند: DNS-over-UDP/TCP سنتی روی پورت 53 (متن ساده)، DNS-over-TLS (DoT) روی پورت 853، DNS-over-HTTPS (DoH) روی پورت 443 (که درون ترافیک HTTPS پنهان می‌شود) و DNS-over-QUIC (DoQ) که در پروتکل QUIC انجام می‌شود. علاوه بر این، در TLS 1.3 فنّاوری ECH (Encrypted Client Hello) معرفی شده که امکان رمزکردن کاملاً کلاینت‌هلوی TLS (به جز بخش ثابت اولیه) را فراهم می‌کند. SNI (Server Name Indication) بخشی از Client Hello در TLS 1.3 و پیش‌تر بود که نام دامنه مقصد (میزبان) را به صورت شفاف ارسال می‌کرد. نسخه‌های اولیه ESNI (Encrypted SNI) و سپس ECH کوشیدند این نشت اطلاعات را بپوشانند. بدون ECH، SNI به صورت متن ساده ارسال می‌شود و فایروال‌های سازمانی یا دولتی می‌توانند بر اساس آن دامنه‌ها را فیلتر کنند.
TLS (نسل‌کار امنیت لایه حمل و نقل): در TLS 1.2 و قبل، پیام ClientHello (شامل SNI) به صورت متن ساده ارسال می‌شد. در TLS 1.3، بخش اعظم دست‌دهی (ClientHello) رمزنگاری شده‌است، اما برخی پارامترهای اولیه (مانند ورژن‌ها) از مقادیری مشتق شده از اطلاعات قابل مشاهده است. در دست‌دهی TLS 1.3، مشتری پارامترهای رمزگذاری، و نام دامنه (در صورت فعال بودن ECH غیرمعمول) را ارسال می‌کند. یک تجهیزات DPI می‌تواند پارامترهایی چون نسخه TLS، فهرست Cipher Suiteها و فرمت ClientHello را تحلیل کند (معروف به اثر انگشت TLS یا JA3) و حدس بزند از چه نرم‌افزار/سیستمی استفاده می‌شود. TLS به طور کلی بر بستر TCP یا QUIC (TLS 1.3 روی QUIC) کار می‌کند. در TLS 1.3، برای رزومه جلسه نیز بلیتی مبادله می‌شود که در بازگشایی مجدد ارتباط مفید است.
2
HTTP/2 و HTTP/3: HTTP/2 یک پروتکل باینری روی TCP/ TLS است که امکان چندکارگی (multiplexing) و فشرده‌سازی هدر را دارد. HTTP/3 عملاً HTTP/2 روی QUIC است و از قابلیت‌های QUIC مانند تأخیر یک مرحله‌ای (0-RTT) و بهبود سرعت ارتباط بهره می‌برد. در HTTP/3، کل دست‌دادها رمزنگاری است ولی همچنان SNI می‌تواند نشت شود (مگر از ECH استفاده شود). به دلیل رمزنگاری سرآیندها، DPIها دیگر نمی‌توانند مستقیم محتوا یا URLها را ببینند؛ تنها فیلدهای اولیه نظیر SNI یا الگوهای ترافیکی (اندازه بسته، و تعداد پکت) باقی می‌ماند.
UDP و TCP: در TCP برقراری اتصال سه‌مرحله‌ای (سه‌راهه: SYN, SYN/ACK, ACK) وجود دارد و تضمین تحویل داده‌ها با مکانیزم بازفرست (RETRANSMISSION) انجام می‌شود. UDP پروتکلی بدون اتصال و فاقد کنترل خطاست؛ در UDP هر بسته‌ی مستقل فرستاده می‌شود و ترتیب یا تضمین رسیدن آن بر عهده پروتکل اپلیکیشن یا بالاسری است. جریان‌های TCP می‌توانند توسط DPI مانیتور و با TCP RST (قطع ارتباط) مسدود شوند، ولی UDP در برابر RST بی‌تاثیر است (مگر پکت‌های UDP خود مسدود شوند).
مهندسی ترافیک (Traffic Engineering): در شبکه‌های بزرگ از تکنیک‌های TE استفاده می‌شود تا ترافیک از مسیرهای مطلوب عبور کند (مثلاً MPLS-TE، RSVP-TE) تا سربار شبکه متعادل شود. در این زمینه ممکن است مسیرهای از پیش تعیین شده یا سوئیچینگ مبتنی بر MPLS به کار رود. اشاره به این موضوع فراتر از بحث DPI/فیلترینگ است، ولی در اینجا باید دانست که شبکه‌های ISP و CDNها (محتوا) مسیر ترافیک را بهینه می‌کنند تا تاخیر و ترافیک را کاهش دهند. DPIهای مدرن نیز گاهی در کنار سیستم‌های TE قرار می‌گیرند تا ترافیک‌های حساس را کنترل کنند بدون آنکه کل لینک اشباع شود.
Fingerprinting (اثر انگشت ترافیک): در سطوح مختلف شبکه می‌توان ترافیک را با الگوهای خاص شناسایی کرد. برای مثال، ترکیب‌های نسخه و Cipher Suite در دست‌دهی TLS می‌تواند اپلیکیشن یا سیستم‌عامل را حدس بزند. همین‌طور، الگوریتم‌های شناسایی آماری و رفتاری روی حجم، الگوی زمانی و جهت بسته‌ها، روش دیگری برای ردیابی خدمات است. در لایه TCP/IP هم نوع بسته (TCP vs UDP)، پورت‌های غیرمعمول یا اجزای ثابت سرآیند می‌تواند به عنوان اثرانگشت عمل کند؛ برای نمونه Wireshark می‌تواند با تحلیل توالی دست‌دادهای TCP کاسته نشده، تفاوت سیستم عامل‌ها را تشخیص دهد. این تکنیک‌ها پایه DPI اند تا پروتکل‌ها یا برنامه‌ها را «اثر انگشت» بزنند و در صورت لزوم مسدود یا محدود کنند.
VPN
PPTP: یک پروتکل قدیمی VPN که از PPP و تونل‌سازی GRE (پروتکل 47) استفاده می‌کند. پس از برقراری ارتباط TCP روی پورت 1723 برای فرمان‌دهی، ترافیک کاربر در تونل GRE عبور می‌کند و با رمزنگاری MPPE (معمولاً RC4 128) حفاظت می‌شود. معماری ساده‌ای دارد، اما امنیت ضعیفی دارد (MPPE تراست ندارد و آسیب‌پذیری‌های متعددی دارد). DPI به راحتی PPTP را تشخیص می‌دهد چون بسته‌های GRE مشخص‌اند و به سختی پنهان می‌شوند. PPTP در برابر فیلترینگ مقاوم نیست و در بسیاری نقاط (از جمله چین و ایران) بدون مشکل مسدود می‌شود.
L2TP/IPsec: شامل دو بخش است: L2TP خود تنها ارتباط نقطه‌به‌نقطه را روی UDP (پورت 1701) فراهم می‌کند و معمولاً با IPsec ترکیب می‌شود تا رمزنگاری لازم فراهم آید. معماری معمولاً از IKE (پورت 500 UDP) برای تبادل کلید استفاده می‌کند و پس از آن مجموعه SA (اهداف امنیتی) برای ESP (پروتکل 50 IP) و AH (51 IP) برقرار می‌شود. رمزنگاری قوی (AES, 3DES) به کار می‌رود. DPI می‌تواند L2TP/IPsec را با نگاه به بسته‌های IKE (تبادل پورت‌ها و پیام‌های شناخته‌شده) تشخیص دهد. مقاومت در برابر فیلترینگ متوسط است؛ چون ترافیک رمزنگاری‌شده است، اما پروتکل‌ها و پورت‌های خاص قابل شناسایی‌اند. حملات فعال یا پیکربندی نادرست ممکن است منجر به ردیابی شود.
2
part2
SSTP: پروتکل VPN مایکروسافت که از TLS 1.x (روی TCP/443) برای تونل‌سازی استفاده می‌کند. پس از برقراری TCP، handshake TLS انجام می‌شود، و سپس ترافیک PPP/PPPoe یا IPSec tunneled درون TLS. از نظر معماری، SSTP از پورت امن HTTPS بهره می‌برد. نحوه رمزنگاری و تبادل کلید همان TLS است (گواهی‌های X.509، RSA/DH). مزیت بزرگ SSTP امکان عبور از فایروال‌های بسته به پورت است (چون مشابه HTTPS است). معایب: صرفاً ویندوزی است (مایکروسافت) و در بین جامعه open-source کم استفاده است. DPI به سختی SSTP را از HTTPS واقعی تشخیص می‌دهد (مثل Trojan)، مگر اینکه گواهی/سرآیند غیرمعمولی داشته باشد. بنابراین مقاومت خوبی در برابر فیلترینگ دارد (در عمل گاهی سانسورها SSTP را به عنوان HTTPS باز می‌گذارند).
OpenVPN: یکی از محبوب‌ترین VPNهای متن‌باز. معماری معمولاً بر پایه TLS (نسخه 1.2 یا 1.3) است، استفاده از UDP یا TCP (پورت پیش‌فرض UDP 1194 یا TCP 443). کلیدها توسط TLS DHE/ECDHE مبادله شده و داده‌ها با AES/GCM (یا BF/CBC) رمز می‌شود. handshake اولیه TLS، به علاوه تبادل کلید (Certificate) صورت می‌گیرد. مزایا: امنیت بالا (بسته به تنظیمات)، پیکربندی انعطاف‌پذیر، جامعه بزرگ، پشتیبانی از چند پلتفرم. معایب: سربار TLS و مدیریت گواهی‌ها. DPI معمولاً OpenVPN را شناسایی می‌کند: محققان نشان داده‌اند که بسته‌های اولیه و اندازه پاسخ‌ها الگو دارد و می‌توان پروتکل را اثرانگشت‌گذاری کرد (مثلاً یک مطالعه USENIX نشان داد با تحلیل الگوها >85% اتصالات OpenVPN شناسایی می‌شوند). همچنین چون سرآیند TLS و حداکثر طول بسته مشخصی دارد، DPI می‌تواند دستورات خاص OpenVPN (opcode patterns) را ببیند. به دلیل استفاده از TLS و امکان فعالیت روی پورت 443، مقاومت OpenVPN در برابر فیلترینگ متوسط است: اگر DPI را قانع کنیم یا ترافیک را تغییر دهیم (مثلاً پراکسی کردن در پشت HTTPS) بهتر می‌شود، اما در حالت عادی ممکن است مسدود شود.
WireGuard: یک VPN جدید و سبک‌وزن مبتنی بر کرنل (که از UDP 51820 پیش‌فرض استفاده می‌کند). معماری دارای جفت کلیدهای عمومی/خصوصی است و بر پایه مبادله پیام‌های کلاینت و سرور (handshake Noise Protocol) عمل می‌کند. دست‌داد اول شامل یک مقدار ثابت 4 بایتی، و دو MAC 16 بایتی (MAC1، MAC2) است (که در ابتدا صفر هستند). مزایا: ساده، سریع، رمزنگاری مدرن (ChaCha20+Poly1305)، احراز هویت کلید عموم، تأخیر کم. معایب: اتصال فقط UDP، قابلیت NAT traversal نیازمند کار اضافی (دانگل‌ها)، سرویس رایگان DNS ندارد. DPI به راحتی WireGuard را شناسایی می‌کند: هر دست‌داد WireGuard یک بسته UDP با 3 بایت رزرو صفر و دو فیلد MAC صفر در ابتدای آن دارد؛ همین الگوی یکتا باعث می‌شود دستگاه‌های DPI شناسایی آسانی از آن داشته باشند. مقاومت در برابر فیلترینگ ضعیف است؛ به عبارتی بدون روش‌های مسدود سازی (مثلاً obfuscation) فیلترها به‌راحتی با شناسایی بایت‌های خاص WireGuard می‌توانند آن را مسدود کنند.
SoftEther: یک سویت VPN چندپروتکل (موسوم VPN Gate) است که می‌تواند جایگزین پروتکل‌های مختلف شود. می‌تواند به صورت HTTPS ترافیک را تونل کند یا پروتکل‌های VPN سنتی را فراهم کند. مزایا: بسیار چندمنظوره (پشتیبانی از L2TP/IPsec, OpenVPN, SSTP و …)، گرافیک کاربرپسند، OSS و پرتوان. معایب: تقریباً شناسایی‌پذیر از طریق اثرانگشت TLS است. مایکروسافت گزارش داد به سختی می‌توان ترافیک SoftEther را از HTTPS تمییز داد، اما تحقیقات اخیر نشان می‌دهد SoftEther به‌خاطر نحوه ساخت گواهی‌های TLS خود یک اثرانگشت JA4X منحصربه‌فرد دارد که می‌تواند باعث شناسایی آن شود. بنابراین DPIهای پیشرفته می‌توانند با استفاده از همین اثر انگشت خاص، ترافیک SoftEther را تشخیص داده و مسدود کنند.
Outline: فریم‌ورک VPN توسط Jigsaw است که در پس‌زمینه از پروتکل Shadowsocks استفاده می‌کند. ساختار ساده دارد: یک سرور Shadowsocks و مدیریت سرور (Outline Manager) برای پیکربندی. نحوه رمزنگاری و کلید مشابه Shadowsocks است. مزایا: سادگی نصب برای کاربران معمولی، متن باز. معایب: وابسته به Shadowsocks (بنابراین معایب Shadowsocks را دارد). DPI می‌تواند Outline را مثل Shadowsocks تشخیص دهد. مثلاً گزارش شده که GFW چین Shadowsocks و Outline را در کنار هم آزموده است (چون هر دو پروتکل مشابهی دارند). مقاومت Outline در برابر فیلترینگ مشابه Shadowsocks است: اگر فعال probing Shadowsocks کار کند، Outline هم در خطر است.
OpenConnect (دلیل ذکر): اشاره شده که Active probing در ایران مثلاً برای OpenConnect (پروتکل شرکت سیسکو) دیده نشده؛ اینجا لازم نیست چون موضوع اصلی VPNهای بالا بود.
برای هر VPN، روش تشخیص DPI به الگوی ارتباطی آن بستگی دارد. به طور خلاصه:
2
VPN‌های TCP/TLS (OpenVPN, SSTP, SoftEther): DPI با تحلیل TLS یا الگوی دست‌داد می‌تواند آنها را شناسایی کند، مگر اینکه ترافیک را با روش‌هایی چون obfsproxy مخفی کنند.
VPNهای UDP (WireGuard، OpenVPN UDP): بایت‌های ثابت پیام‌ها (WireGuard) یا سرآیند UDP خاص (OpenVPN 59-byte جهت کلاینتHello) اثرانگشت ایجاد می‌کنند.
VPN‌های قدیمی (PPTP, L2TP): چون از پروتکل‌های متفاوتی (GRE و ESP) استفاده می‌کنند، DPI می‌تواند آنها را سریع تشخیص دهد.
استقامت در برابر فیلترینگ: PPTP و L2TP که بر استانداردهای قدیمی متکی‌اند تقریباً مسدود می‌شوند. OpenVPN/TCP و SSTP از پورت 443 استفاده می‌کنند و اگر ترافیک TLS آنها عادی به نظر برسد معمولاً عبور می‌کنند، ولی فیلترهای عمیق ممکن است بسته‌های خاص آنها را تشخیص داده و ببندند. WireGuard و پروتکل‌های جدید UDP به طور پیش‌فرض ضعیف‌اند مگر آنکه راه‌های حفاظت اضافی (مانند UDP ساده‌تر یا پوشاندن ترافیک) اعمال شود.
DNS و رمزنگاری آن
DNS سنتی: درخواست‌های DNS معمولاً روی پورت 53/UDP ارسال می‌شوند و نام و پرسش به صورت متن ساده در بسته درج می‌شود. سانسورها می‌توانند این بسته‌ها را سوزانده، پاسخ‌های جعلی (cache poisoning) برگردانند یا دامنه‌ها را در مسیریاب‌ها تغییر دهند. روش‌هایی مانند DNS poisoning (بازنویسی پاسخ) یا DNS Hijacking (ارسال پاسخ به سرور تقلبی) استفاده می‌شود تا به دامنه‌های مسدود شده پاسخ نادرست داده شود.
DNS-over-TLS (DoT): در این روش، پرسش DNS در یک جلسه TLS معمولاً روی پورت TCP/853 ارسال می‌شود. رمزنگاری بالای UDP سنتی قرار می‌گیرد. DPI می‌تواند با مشاهده پورت 853 یا SNI در آغاز TLS آن را تشخیص دهد (معمولاً دامنه‌ای ثابت مثل cloudflare-dns.com). اگر SNI رمزنگاری نشده باشد، فیلتر می‌تواند نام سرویس DNS را مسدود کند. البته روی HTTPS معمولی امکان مانع است.
DNS-over-HTTPS (DoH): DNS پرسش‌ها را در قالب درخواست HTTPS (HTTP/2 یا HTTP/3) روی پورت 443 می‌فرستد. محتوای آن رمزنگاری است و حتی SNI ممکن است به نام DNS معمول نباشد. در عمل، DoH معمولاً به سرویسی خاص اشاره می‌کند (مثلاً Google dns.google یا Cloudflare). چون همه ترافیک روی پورت 443 است، DPI دشوار است مگر اینکه SNI و URL پنهان را بشناسد. اگر شرکت‌ها SNI پیش‌فرضِ DNS (مثلاً mozilla.cloudflare-dns.com) استفاده کنند، سانسورها می‌توانند آن را مسدود کنند؛ اما اگر از دامنه غیرمعمول یا ECH استفاده شود، تشخیص دشوارتر می‌شود. یک چالش این است که مرورگرها معمولاً برای شروع DoH نیاز به یک پرسش DNS اولیه (غیر رمز) دارند تا آدرس resolver را بیابند؛ این پرسش اولیه خود ممکن است مسدود شود.
DNS-over-QUIC (DoQ): مشابه DoH اما روی پروتکل QUIC. چون QUIC پیام دست‌دهی خود را رمز می‌کند (بجای TLS روی TCP)، ترافیک DoQ نیز در نگاه اول شبیه HTTP/3 روی UDP است. با این حال، می‌توان پورت 853 (QUIC DoT) یا فرآیندهای ویژه‌ی دست‌دهی QUIC را برای تشخیص به کار برد.
Encrypted Client Hello (ECH): تکنیکی برای رمز کردن کلاینت‌هلوی TLS است (از جمله SNI). برای شروع ارتباط ECH، کلاینت نیاز به دریافت ECH Config از DNS دارد (مثلاً دامنه‌ای مثل ech-alpn.cloudflare.com) که نشان می‌دهد سرویس‌دهنده از ECH پشتیبانی می‌کند. اگر DNS مسدود باشد، ECH شکست می‌خورد. پژوهشی در PETS نشان داد که برای برقراری ECH، کاربر باید DNS رمزنگاری‌شده (DoH/DoT/DoQ) برای پرسش ECH config استفاده کند؛ DoT/DoQ به دلیل پورت 853 قابل شناسایی هستند، اما DoH روی 443 معمولی است. علاوه بر این، در TLS/TCP (HTTP/2) نام SNI در ClientHello معمولاً به صورت متن ساده ارسال می‌شود. قبل از ECH، تلاش‌هایی تحت عنوان ESNI انجام شده که صرفاً بخش SNI را رمز می‌کرد، اما چین از سال 2020 شروع به مسدودسازی ESNI کرد (بدون توجه به اینکه دامنه چه هست).
2
part3:
مسدودسازی توسط سانسورها: سیستم‌های سانسور می‌توانند DNS را با روش‌های زیر محدود کنند: در لایه شبکه، ترافیک DNS را مقایسه یا دستکاری می‌کنند (DNS Poisoning/Manipulation)، یا در لایه IP مسیرها را مسدود می‌کنند تا بسته‌های DNS اصلاً به بیرون نرسند. ASN یا بلوک‌های IP ارائه‌دهندگان DNS عمومی (مانند گوگل یا کلودفلر) ممکن است کلی مسدود شود. علاوه بر این، با فعال کردن DPI روی ترافیک TLS، نام SNI و حتا برخی متادیتای پنهان TLS بررسی می‌شود تا ارتباطات مشکوک مسدود شود. در نهایت، حجم زیادی از مسدودسازی‌های زبانی قدیمی مانند DNS-to-HTTP or TCP-resetها می‌تواند منجر به جلوگیری از دسترسی به resolverها شود.
V2Ray و Xray
معماری کلی V2Ray/Xray: پلتفرم V2Ray (و شاخه پیشرفته‌تر Xray با توسعه‌های جدید) معماری مدولار دارد: چند پروتکل ورودی (Inbound) می‌تواند همزمان اجرا شود (مثلاً یک سرور همزمان پروتکل‌های VMess و Shadowsocks و SOCKS را بپذیرد) و هر کدام یک یا چند لایه ترنسپورت (TCP, UDP, QUIC, WS, gRPC و…) دارد. سپس مولفه Routing تصمیم می‌گیرد ترافیک ورودی چگونه به خروجی (Outbound) هدایت شود (مثلاً بر اساس دامنه، IP مقصد، موقعیت جغرافیایی، یا قواعد کاربر). به طور کلی V2Ray دارای سه بلوک اصلی است: Inbounds (پروکسی‌هایی که ترافیک را دریافت می‌کنند)، Outbounds (ترافیکی که به شبکه می‌فرستند)، و Routing که بین آن‌ها وصل می‌کند. هر مؤلفه قابل پیکربندی جداگانه است. برای مثال، مستند V2Fly ذکر می‌کند یک فرآیند V2Ray می‌تواند به طور همزمان چندین پروتکل ورودی/خروجی داشته باشد و ترافیک را بر اساس پیکربندی (مثل تقسیم بر اساس منطقه یا دامنه) مسیریابی کند. همچنین اشاره شده که نودهای V2Ray می‌توانند ترافیک خود را شبیه به وب‌سایت‌های عادی (HTTPS) استتار کنند.
در زیر لایه مبنای پروتکل (که گاهی Security Layer یا TLS Layer خوانده می‌شود) می‌توان از TLS معمولی یا XTLS استفاده کرد (XTLS نسخه خاصی از TLS است که چند لایه رمزگذاری را با هم ادغام می‌کند تا سربار کمتر باشد). لایه Transport (حمل و نقل) می‌تواند TCP خام، WebSocket (که بسته‌ها را در فریم‌های HTTP می‌فرستد)، gRPC (که پروتوکلی بر پایه HTTP/2 است)، HTTP/2 Upgrade، KCP (نسخه‌ای از UDP با کنترل خطا) و یا QUIC باشد. جریان داده (Stream Settings) مثل اجازه به دتاگ فشرده، رمزنگاری ثانویه یا تکثیر (Multiplexing) هم قابل تنظیم است.
مهم‌ترین بخش‌های پیکربندی V2Ray/Xray:
Inbound: نقطه آغاز ترافیک، مثلاً یک درگاه TCP برای پروتکل VMess با TLS.
Outbound: جایی که ترافیک فرعی به اینترنت فرستاده می‌شود، مثلاً به صورت مستقیم (Direct) یا به یک DNS خاص (Blackhole یا DNS) یا به یک سرور دیگر (با VMess/VLESS/Trojan...).
Routing: قوانین انتقال ترافیک از Inboundهای مختلف به Outboundهای مناسب، بر اساس فیلترهای مبتنی بر IP، دامنه، GeoIP، یا انواع دیگر.
Stream Settings: تنظیمات مربوط به چگونگی بسته‌بندی داده در هر لایه انتقال (مانند فعال‌سازی KeepAlive، TLS، or XTLS).
Transport Layer: پروتکل انتقال واقعی (TCP، UDP/KCP، QUIC، WS، gRPC، HTTPUpgrade).
Security Layer: معمولاً TLS یا XTLS برای رمزنگاری لایه اتصال. XTLS به عنوان جایگزینی برای TLS عادی توسط Xray ارائه شده که بهینه‌سازی‌هایی مثل Splice دارد (جلوگیری از رمزگذاری دوگانه).
فناوری‌های نوین: مثل Reality (استتفاده از رمزنگاری نسل بعد همراه با پروفایل QUIC شباهت به دست‌دهی TLS و SPDY برای مخفی‌سازی)، Vision Flow (XTLS) (یک حالت از XTLS برای پوشش ترافیک)، و FinalMask (Padding و obfuscation پس از دست‌دهی). این فناوری‌ها طراحی شده‌اند تا اثرانگشت پروکسی را مخفی کنند و شناسایی ترافیک سخت‌تر گردد.
پروتکل‌های مهم:
2
VMess: پروتکل اصلی قدیمی V2Ray که بر بستر TCP کار می‌کند. در مسیریابی این پروتکل، «EAuID» (کد شناسایی کاربر رمزگذاری‌شده) ارسال می‌شود که شامل UUID کاربر و زمان و CRC32 است. فیلدهای دیگر در پیام درخواست (Client Request) شامل طول رمزگذاری‌شده سرآیند، یک مقدار تصادفی (Nonce) و خود داده می‌شوند. VMess دارای دو حالت احراز هویت است: حالت جدید AEAD (استفاده از AES-128-GCM برای صحت‌سنجی هدر) و حالت قدیمی MD5+AES-128 (فعلاً منسوخ). از نقاط قوت VMess این است که یک ساختار رمزگذاری‌شده و استیت‌لس (بی‌حالت) دارد؛ سرورها پس از دریافت درخواست، هویت کاربر را بررسی می‌کنند و در صورت تأیید، آن را به مقصد هدایت می‌کنند. ضعفی که دارد این است که چون پیچیده و منحصربه‌فرد است، ممکن است اثرانگشت ترافیک آن توسط DPI قابل شناسایی باشد (مثلاً طول خاص بسته‌های شروع). به‌علاوه، برای حملاتی مانند اجرای زمان محدود (timing attacks)، وابسته به زمان بودن (در حالت MD5 قدیمی) می‌تواند مشکل‌ساز باشد؛ VLESS این مشکل را ندارد.
VLESS: نسخه جدیدتر VMess در Xray/V2Ray که سبک‌تر است. مستندات آن می‌گویند VLESS «بی‌حالت، سبک و بدون وابستگی به زمان سیستم است» و از یک UUID ثابت برای احراز هویت استفاده می‌کند. برخلاف VMess، هیچ CRC زمان‌بندی یا MD5ی در کار نیست. فقط UUID کاربر به طور خام (در چت TLS) احراز هویت می‌شود. این سادگی باعث می‌شود پیاده‌سازی و اثرانگشت‌پذیری آن کمتر شود. در عمل ساختار فنی VMess و VLESS شبیه‌اند، تفاوت عمده در حذف زمان و روش احراز است. چون VLESS هم معمولاً بر بستر TLS اجرا می‌شود (مثلاً XTLS یا ساده TLS)، دست‌دهی آن مثل یک TLS عادی به نظر می‌رسد. به طور خلاصه: ساختار بسته ساده‌تر و handshake کوتاه‌تر از VMess دارد.
Shadowsocks: پروتکل پراکسی سبک بر پایه رمزنگاری. معماری آن به طور ساده شامل یک سرور و کلاینت است، بدون handshake تعریف‌شده; کلاینت پس از برقراری TCP (یا UDP) اولین بسته را به صورت رمز شده به سرور ارسال می‌کند. در نسخه‌های قدیمی، اولین بسته شامل ۱ بایت نوع آدرس (IPv4/دامنه/IPv6)، آدرس مقصد و پورت (۲ بایت) بود. این حداقل handshake باعث می‌شد فایروال بتواند از حملات فعال پروبینگ استفاده کند: مثلاً یکی می‌تواند ۲۵۶ اتصال با یک بایت‌های اول متفاوت ایجاد کند، و در ۳۲ بایت مقدار قانونی (۱ یا ۳) سرور منتظر می‌ماند و بقیه موارد را قطع می‌کند؛ این الگو به فایروال می‌گوید که سرور Shadowsocks است. در نسخه‌های امروزی با استفاده از رمزنگاری‌های AEAD این نوع حمله خنثی شده‌ است (مگر کلید را حدس بزند). Shadowsocks عموماً به دلیل تشابه ترافیک با جریان‌های تصادفی قوی شناخته می‌شود، ولی DPIهای پیشرفته و probing فعال (مثلاً تزریق محتوی غیرقانونی و دیدن پاسخ رمز شده بزرگ) می‌تواند آن را تشخیص دهد. مقاومت در برابر فیلترینگ آن متوسط است؛ اگر ترافیک منتظر پکت‌ها شود و پاسخ‌های رمز شده حجیم بدهد، نشانه‌ی سرور Shadowsocks خواهد بود.
SOCKS: پروتکل پراکسی استاندارد بدون رمزنگاری که کلاینت می‌تواند روی آن پورت‌ها را فوروارد کند. شناسایی آن بسیار آسان است زیرا فرمت مشخص (مثلاً نسخه 5 در اول بسته و سپس درخواست TCP Connect) دارد. طبیعتاً رمزنگاری ندارد، پس به خودی خود مقاومتی در برابر سانسور ندارد و بر اساس قوانین محتوا توسط DPI مسدود می‌شود (اگر DNS یا IP مقصد حساس باشد).
HTTP Proxy (CONNECT): پروتکلی که به کلاینت امکان می‌دهد درخواست CONNECT به یک سرور HTTP بدهد تا یک تونل TCP ساده ایجاد کند. درخواست شامل خطی شبیه «CONNECT domain:port HTTP/1.1» است که به‌وضوح قابل تشخیص است. از آنجا که متن ساده است، DPI می‌تواند به راحتی این رشته را پیدا کرده و مسدود کند یا محدودیت بگذارد (مگر TLS روی آن برقرار شود). البته اگر روی TLS (HTTPS) اجرا شود، به صورت HTTPS عادی درآمده و فقط بسته‌های TLS دیده می‌شوند.
ترنسپورت‌های V2Ray/Xray:
TCP: معمول‌ترین ترنسپورت. اگر از TLS روی TCP استفاده شود، شبیه HTTPS حرکت می‌کند. بسته‌های TCP دارای سرآیند طول، شماره ترتیب، پرچم ACK/SYN و ... هستند. DPI به راحتی می‌تواند سرآیند و محتوای پلین‌تکست یا TLS (مثل SNI) را ببیند.
WebSocket (WS): لایه‌ای روی HTTP است که پس از یک درخواست Upgrade، اتصال دوطرفه «فریم» شده ایجاد می‌کند. هر فریم WS چند بایت سربرگ دارد (بین 2 تا 14 بایت سربرگ) و سپس داده باینری. چون ابتدا روی HTTP 1.1 و پورت 80/443 برقرار می‌شود، می‌توان آن را به‌عنوان ترافیک وب پنهان کرد. معایب: سربرگ‌های پی‌درپی قابل تشخیص و راه‌اندازی HTTP برای آن لازم است.
1
gRPC: پروتکلی است که روی HTTP/2 ساخته شده و داده را در چارچوب‌های protobuf ارسال می‌کند. اگر استفاده شود (V2Ray جدید)، عملاً شبیه HTTP/2 است و DPI ممکن است آن را مانند WS یا HTTP/2 تشخیص دهد.
HTTP/2 Upgrade (HTTPUpgrade): شبیه WS عمل می‌کند اما از ویژگی Upgrade پروتکل HTTP/1.1 استفاده می‌کند تا به H2 سوئیچ کند و ترافیک را باینری کند. DPI می‌تواند فیلد Upgrade را ببیند یا از محتوای HTTP2 متوجه موضوع شود.
QUIC: لایه حمل‌ونقل بر بستر UDP. QUIC تمام دست‌دادها را رمزنگاری می‌کند (با استفاده از TLS 1.3) و برای ناوبری از Connection ID استفاده می‌کند. بسته‌های QUIC شامل یک مقداری به نام Connection ID است که ممکن است در شبکه تغییر کند. DPI برای شناسایی QUIC معمولاً به فیلد نسخه (قسمت ابتدایی UDP payload) نگاه می‌کند؛ همچنین چون QUIC handshake همیشه دارای byte‌های خاص 0x01 0x00 0x00 0x00 در آغاز (نسخه 1) است، به راحتی قابل تشخیص است.
KCP (μTP): پیاده‌سازی سریع UDP برای ارتباطات با کنترل خطا سبک. شامل فیلدهای مانند Seq, Ack, Window در سرآیندش است. DPI می‌تواند بسته‌های KCP را بسته به نوع ساختار سرآیند تشخیص دهد (یک IP/UDP با داده‌های خاص).
فناوری‌های جدید:
Reality: تکنیک جدیدی مشابه QUIC است که handshake ترکیبی TLS+مکانیزم‌های Post-Quantum (مانند SIKE) دارد تا اثرانگشت ترافیک را مخفی کند. در آن، دامین در SNI نیست بلکه به صورت آدرس عمومی رمزنگاری‌شده ارسال می‌شود. این روش بسیار جدید است و هنوز توسط اکثر DPIها شناسایی نشده است، به شرط آن که دست‌دهی و یا SNI واقعی پنهان بماند.
XTLS: نسخه اصلاح‌شده TLS توسط Xray که تکرار رمزنگاری را حذف می‌کند تا سربار کمتر باشد. در XTLS دو لایه رمزنگاری (یکی TLS و یکی روی پروتکل) بهینه می‌شوند. برتری XTLS این است که کارایی بهتر (کمتر تأخیر) دارد. اثر انگشت آن هم مثل TLS است، یعنی دست‌دهی شبیه TLS اما کنترل اضافی دارد.
Vision (Flow): اشاره به ویژگی Xray دارد که «mskFlow» یا «Vision» نامیده می‌شود؛ این لایه داده را به شکل خاصی (مانند حداقل padding) ارسال می‌کند تا آسان‌تر قابل تشخیص نباشد.
برای هر پروتکل می‌توان ویژگی‌هایی ارائه داد:
ساختار بسته: مثلاً VMess با AEAD، بدنه اول 16 بایت EAuID, 18 بایت طول، 8 بایت نانس و غیره است. Shadowsocks ابتدا سرآیند SOCKS ساده ارسال می‌کند. Trojan پس از TLS فقط یک خط SHA224+SNI می‌فرستد.
Handshake: VMess ساده است (بدون handshake جداگانه)، VLESS هم تنها ارسال UUID. Shadowsocks هیچ handshake پیچیده ندارد (فقط رمزنگاری AES/ChaCha بر روی TCP). Trojan handshake در واقع TLS استاندارد است (ClientHello/X25519/ certificado) سپس آدرس‌دهی.
اثر انگشت شبکه: به طور کلی پروتکل‌هایی که شبیه HTTPS (مانند Trojan با TLS، یا V2Ray-Over-TLS) کار می‌کنند، اثرانگشتی ندارند (مانند HTTPS عادی). اما پروتکل‌هایی با سرآیند یا طول ثابت (مثل WireGuard، VMess بدون TLS) اثرانگشت واضح دارند.
الگوی ترافیکی: مثلاً Shadowsocks معمولاً جریان داده‌های تصادفی دارد که DPI با نداشتن ساختار متن قابل تشخیص می‌کند. Trojan و همه پروتکل‌های TLS، شبیه ترافیک وب می‌افتند (یک بسته ClientHello، سپس ACKها).
نقاط ضعف: VMess/VLESS/Trojan نیاز به تنظیم و کلیدگذاری دارد (هر گونه لو رفتن UUID یا رمز می‌تواند مخاطراتی باشد). Shadowsocks قدیمی به حملات فعال آسیب‌پذیر بود (که با AEAD رفع شد). WireGuard فقدان TLS باعث شناسایی آسان است.
نقاط قوت: همه این پروتکل‌ها برای عبور از فیلتر طراحی شده‌اند: Trojan با استتار کامل در HTTPS، VLESS/VMess با رمزنگاری قوی، Shadowsocks با سادگی و عملکرد مناسب. در عین حال اگر یک پروتکل شناسایی شود، باقی فیلترها مجبور به بلاک هستند (مثلاً فیلتر ایران غالباً فقط TLS را مجاز می‌کند).
تکنولوژی‌های تونلینگ
در تونلینگ، ترافیک از یک نوع پروتکل یا مسیر عبور پیدا می‌کند در حالی که در لایه دیگری کپسوله شده است. برخی نمونه‌ها:
SSH Tunnel: از پروتکل SSH (TCP/22) برای ایجاد یک تونل امن استفاده می‌شود. مثلاً کاربر ممکن است یک SSH local port forwarding یا Dynamic SOCKS proxy برقرار کند. هر داده درون بسته‌های SSH رمزنگاری‌شده گنجانده می‌شود (با الگوریتم‌هایی مانند AES). در SSH، پس از احراز هویت کاربر، کاربر می‌تواند درخواست‌ها را از طریق SSH به مقصد دیگری (به عنوان proxy) بفرستد. ساختار یک بسته SSH شامل فیلدهایی مثل اندازه، نوع بسته (data, keep-alive) و داده رمزنگاری‌شده است. DPI معمولاً نمی‌تواند محتوای SSH را بخواند؛ بلکه تنها می‌تواند ارتباط TCP روی پورت 22 را ببیند. مقاومت: به عنوان ترافیک TCP امن به نظر می‌رسد، پس معمولاً قابل دور زدن است (مگر اینکه خود پورت TCP/22 مسدود شده باشد).
1
TLS Tunnel (مانند Stunnel): شبیه SSH Tunnel عمل می‌کند ولی به جای SSH از TLS/SSL استفاده می‌کند. به عنوان مثال یک سرویس Stunnel روی سمت سرور ممکن است به صورت TLS روی پورت 443 داده‌ها را بگیرد و به یک مقصد TCP دیگر بفرستد. در این‌جا بسته‌های TLS عادی (ClientHello, ServerHello, Application Data رمزنگاری شده) شکل می‌گیرند. این تونل شبیه HTTPS عادی است؛ DPI نمی‌تواند داده‌ها را ببیند، فقط سرآیند TLS (SNI, Certificate) را می‌بیند.
Reverse Tunnel: معمولاً به معناست که سرور و کلاینت نقش‌های معکوسی بازی می‌کنند؛ مثلاً سرور SSH با گزینه reverse port forwarding به کلاینت اجازه می‌دهد ورودی‌هایی را که به سرور می‌آیند روی یک پورت به کلاینت منتقل کند. به بیان دیگر، کاربر در پشت NAT یا فایروال قرار می‌گیرد و با این روش امکان دسترسی به سرویس‌های داخلی را ممکن می‌کند. ساختار بسته در اینجا مثل SSH است (چون از SSH استفاده می‌کند).
WebSocket Tunnel: داده‌های معمولی را در فریم‌های WebSocket می‌فرستد. به عنوان مثال، یک ابزاری مثل ws-tunnel به کاربر اجازه می‌دهد تا یک پورت محلی را بر روی یک سرور وب‌ساکت در اینترنت port-forward کند. در ابتدا یک HTTP Upgrade برای ایجاد WebSocket انجام می‌شود، سپس داده‌هایی که نیاز به انتقال دارند در قالب Binary WebSocket Frame ارسال می‌شوند. هر فریم WS دارای چند بایت هدر (MASK, طول و…) است. DPI ممکن است با مشاهده handshake HTTP اول و هدرهای خاص WebSocket متوجه استفاده از WS شود، اما اگر پورت TCP/443 باز باشد این تکنیک می‌تواند ترافیک را در ظاهر ترافیک وب قرار دهد.
1
part4
HTTP Tunnel: می‌تواند دو معنا داشته باشد. یکی استفاده از روش CONNECT در یک پراکسی HTTP: مرورگر یا برنامه درخواست CONNECT می‌فرستد تا TCP مستقیم روی آدرس دیگری باز کند (این همان اساسی‌ترین حالت یک پراکسی HTTP است). در این روش پس از CONNECT، داده‌های TCP کاربر از لایه HTTP عبور می‌کنند. DPI به متن CONNECT درخواستی نگاه می‌کند («CONNECT host:port HTTP/1.1») و بر اساس آن تشخیص می‌دهد. راه دیگر، استفاده از payload داخل HTTP POST یا GET است؛ مثلاً یک تونل HTTP که داده را در بدنه POST می‌فرستد (مانند تعدادی ابزار قدیمی). این هم سرآیندهای HTTP عادی و مسیر URL دارد که به راحتی قابل تشخیص است.
QUIC Tunnel: انتقال داده از طریق پروتکل QUIC به عنوان لایه تونل. مثلاً تکنیکی چون WireGuard-over-QUIC یا Google’s QuicTransport. بسته‌های UDP شبیه QUIC (شامل 3 بایت رزرو و Connection ID) هستند. چون QUIC پشتیبانی TLS 1.3 دارد، ClientHello هم رمزنگاری است. DPI اگر نخواهد آن را شناسایی کند، باید نشانه‌های UDP/QUIC را ببیند؛ ولی به هر حال چون QUIC هنوز مرسوم نیست در بسیاری از کشورها ممکن است قابل شناسایی و بلاک باشد.
UDP Tunnel: مثالی مانند GUE (Generic UDP Encapsulation, RFC8085) یا تونل‌های ساده‌تر GRE/UDP. بسته‌های UDP با سربرندی مخصوص (مثلاً header مربوط به پروتکل tunneled و مقادیری از قبیل نوع Next Header) ارسال می‌شوند. DPI معمولاً بسته‌های UDP غیرمعمول را رد می‌کند یا شناسایی می‌کند. به عنوان مثال، GUE دارای یک مقدار Version، Flags و Next Header است که اگر توسط فایروال شناخته شود، می‌توان جریان را مسدود کرد.
در همه این روش‌ها، ترافیک ورودی توسط پروتکل امن تونل رمزگذاری و حمل می‌شود و در لایه پایین‌تر (مانند TCP یا UDP) کپسوله می‌گردد. به عبارت دیگر، محتویات اصلی درون بسته‌های امن (SSH/TLS/QUIC) قرار گرفته و سپس روی کانال عمومی (مثلاً اینترنت) فرستاده می‌شود. به دلیل لایه‌بندی امن، DPI نمی‌تواند محتوای اصلی را بخواند؛ اما ممکن است با مشاهده سرآیندها و الگوها حدس بزند که تونل وجود دارد (برای نمونه، TLS روی پورت‌های غیرمعمول یا اتصال TCP/22 در شبکه‌ای که استفاده از SSH متداول نیست).
DPI (بازرسی عمیق بسته)
DPI چیست و چگونه عمل می‌کند: در DPI، هر بسته یا جریان شبکه تا لایه کاربرد باز می‌شود تا محتوای آن (آدرس‌ها، پورت‌ها، پروتکل‌ها و حتی محتوی داخل را) بررسی کند. DPI با استفاده از موتورهای بازرسی (مثل قواعد Snort/Suricata) به دنبال الگوهای خاص (مانند رشته‌های متنی، ابرداده پروتکل، اثرانگشت TLS/SSH) می‌گردد. بر اساس آن، تصمیم می‌گیرد بسته را عبور دهد یا بلاک کند. به نقل از ویکی‌پدیا، DPI «به صورت مفصل همه یا بخشی از بسته‌ها (مثلاً صفحه وب یا مکالمه VoIP) را بازرسی می‌کند و ممکن است به محض تشخیص الگو، اقداماتی مانند هشدار، بلاک، مسیریابی مجدد یا ضبط اطلاعات انجام دهد». در SANSo تر نت، DPI معمولاً در لبه شبکه (مراکز IX) و با استفاده از آینه کردن ترافیک (splitter) انجام می‌شود تا بررسی محاسباتی سنگین، سرعت اصلی را کم نکند.
روش‌های تشخیص ترافیک: چند رویکرد عمومی در DPI وجود دارد:
Flow Analysis: تحلیل کلی جریان پکت‌ها (تعداد، زمان‌بندی، طول). مثلاً سرویس‌های استریم ویدیویی الگوهای بسته‌های متمایزی دارند. DPI می‌تواند از آن برای تشخیص نوع سرویس استفاده کند.
Signature (Content/Keyword) Matching: یافتن الگوهای شناخته شده در داده (مانند امضاءها یا کلمات کلیدی). برای پروتکل‌های متن‌باز مفید است. اما در داده‌های رمزنگاری‌شده کارایی کمی دارد.
Statistical Detection: روش‌های آماری (مثلاً برچسب‌گذاری با یادگیری ماشین) که سعی می‌کنند پروتکل/سرویس را بر اساس ویژگی‌های آماری تعیین کنند (مانند توزیع اندازه بسته).
Behavioral Detection: تشخیص بر اساس رفتار کلاینت/سرور (مثل توالی دست‌دادها در TLS یا SSH). مثلا ترکیب نسخه و مجموعه Cipherهای ClientHello را می‌توان مثل اثر انگشت تفسیر کرد (JA3/JA4 برای TLS, HASSH برای SSH).
TLS Fingerprinting (JA3/JA4): JA3 روش ایجاد هَش (MD5) بر اساس لیست CipherSuites, Extensions, Curves, PointFormats در ClientHello است. JA4 نسخه تکامل‌یافته‌تر است که پارامترهای جدید مثل ALPN را هم شامل می‌شود و نسبت به ترتیب تصادفی Extensionها مقاوم است. DPIهایی مثل nDPI کلید SHA-1 گواهی TLS (یا نسخه JA3S) را هم در fingerprint جدید خود وارد می‌کنند. حتی JA4X که در Xray/SoftEther مطرح شده، از اطلاعات گواهی برای تشخیص SoftEther استفاده می‌کند (SoftEther به خاطر روش تولید گواهی منحصر به فرد است و اثرانگشت دارد). به طور خلاصه: DPI پیشرفته دست‌دهی TLS را هَش می‌زند و با پایگاه امضاء خود مقایسه می‌کند.
1
HASSH (SSH Fingerprint): مشابه JA3 برای SSH. در آغاز یک ارتباط SSH، کلاینت آرایه‌ای از الگوریتم‌ها (KEX, Cipher, MAC, Compression) را می‌فرستد. HASSH یک هش از این لیست می‌گیرد (SHA-256) و می‌تواند عامل SSH را تشخیص دهد. DPI یا IDS می‌تواند HASSH را استفاده کند تا کلاینت‌های SSH مختلف را بیابد.
Active Probing: برخی سانسورها به روش Passive (فقط مانیتور) اکتفا نمی‌کنند، بلکه به آدرس‌های مشکوک متصل می‌شوند و سعی می‌کنند پاسخ پروتکل را دریافت کنند. مثلاً چین سرور Shadowsocks را شناسایی کرده، سپس با ارسال پکت‌های آزمایشی «اولین بسته‌شناخت» یا داده تصادفی، پاسخ سرور را می‌سنجد (اگر سرور مقدار زیادی ciphertext برگرداند، آن را Shadowsocks تشخیص می‌دهد). DPIها یا خود فایروال‌ها ممکن است این کار را انجام دهند تا اطمینان حاصل کنند سرویس ممنوع واقعاً در آن IP فعال است. این روش برای پروکسی‌هایی مانند Shadowsocks یا V2Ray که handshake‌های ساده دارند، کارساز است.
Passive Monitoring: در حالت معمول، DPI ترافیک را فقط نظاره می‌کند و بر اساس امضاها یا آمار تصمیم می‌گیرد. یک DPI پیشرفته می‌تواند مثلاً از JA3/JA4/TLS Certificate fields، فیلد SNI یا حتی HTTP headers استفاده کند تا ارتباط را تشخیص دهد.
تشخیص پروتکل‌ها توسط DPI:
VPNها: DPI جدید می‌تواند اکثر VPNها را تشخیص دهد. برای مثال محققان دریافته‌اند الگوهای خاص OpenVPN (مثل ترتیب بسته‌ها و اندازه‌ها) امکان تشخیص بالای ۸۵٪ را دارند. SSTP و SoftEther ترافیک HTTPS را تقلید می‌کنند، اما SoftEther به دلیل ساختار گواهی‌ها اثرانگشت دارد (گواهی‌اش JA4X منحصربه‌فرد است). WireGuard معمولاً بایت‌های آغازین مشخص (سه بایت صفر + 32 بایت MAC) دارد که به راحتی قابل شناسایی است.
V2Ray/VMess/VLESS/Trojan/Shadowsocks: همان‌طور که اشاره شد، برخی از اینها بر بستر TLS یا HTTP هستند. پروتکل‌هایی مانند Trojan که دقیقاً از HTTPS استفاده می‌کنند، به سختی توسط DPI قابل تمییزند (مثل یک سایت امن به نظر می‌رسند). ولی تحقیقات نشان داده‌اند که حتی vmess/shadowsocks/vless/tr0jan معمولاً قابل‌تشخیص‌اند: جریان‌های TLS آنها اغلب یک اثرانگشت آماری دارند؛ مثلاً مقاله USENIX 2024 نشان داد می‌توان بیش از ۷۰٪ جریان vmess, Shadowsocks, vless, Trojan را با بازرسی دست‌دهی TLS تشخیص داد.
Shadowsocks: DPI معمولاً مستقیماً آن را تشخیص نمی‌دهد (چون داده کاملاً رمز است)، اما ترکیب شناسایی محتوا و کارگاه فعال می‌تواند آن را پیدا کند. GFW چین برای Shadowsocks از فعال‌پروبینگ استفاده می‌کند.
Trojan: چون Trojan عملاً HTTPS است (ClientHello استاندارد TLS) و پس از آن یک خط رمز شده کوتاه، DPIهای معمول آن را جز ترافیک وب عادی نمی‌بینند. اگر TLS 1.2 یا 1.3 استفاده کند، SNI، گواهی و دیگر پارامترها مانند یک سایت معمولی خواهد بود. تنها روش ممکن شناسایی می‌تواند پیدا کردن تفاوت‌های بسیار جزئی در Certificate (مثلاً شرکت صدور یا Validity) باشد، اما عملاً حمله بسیار دشوار است. Trojan به طور فنی هیچ لایه اضافه‌ای فراتر از TLS ندارد (بر خلاف VMess که یک رمز مستقل می‌افزاید)، پس از نظر DPI تقریبا نامرئی است (مزیتش در برابر فیلترینگ عالی است).
WireGuard: همانطور که گفته شد با الگوی باینری ثابت قابل تشخیص است.
SoftEther: به رغم ادعای مقاومتش، DPI با توجه به JA4X آن می‌تواند شناسایی کند.
TLS Fingerprinting: DPI می‌تواند از JA3/JA4 استفاده کند تا مشخصات TLS کلی یک ابزار را شناسایی کند و بعضاً حتی تشخیص دهد سرویس چیست (مثلاً نهادهایی مانند کلودفلر قابلیتی به اسم JA3+ دارند که می‌تواند نوع کلاینت را بیابد). افزون بر این‌ها، DPI می‌تواند ترافیک TLS را بسته به ویژگی‌هایی مثل زمان دست‌دهی یا طول پیام‌ها طبقه‌بندی کند.
فیلترینگ و سانسور اینترنت
انواع مکانیزم‌های سانسور و فیلترینگ اینترنت شامل موارد زیر است:
DNS Poisoning (من‌جمله DNS Mangling): سانسورچی‌ها به پاسخ‌های DNS دسترسی پیدا کرده و آن‌ها را با مقادیر جعلی جابجا می‌کنند. به عنوان مثال در چین هر درخواست DNS عبوری از یک فایروال بررسی شده و اگر دامنه‌ای ممنوع باشد، فایروال فورا یک پاسخ ساختگی (معمولاً آی‌پی مخصوص گنگ) برمی‌گرداند. به این تکنیک «DNS mangling» می‌گویند. در حالت دیگر، سانسورها از cache poisoning استفاده می‌کنند: در مسیر پاسخ DNS حضور پیدا می‌کنند و پاسخ درست سرور اصلی را با پاسخ بدتر (NXDOMAIN یا آی‌پی اشتباه) جایگزین می‌کنند. در عمل، با این روش نام دامنه‌های ممنوع هرگز با آی‌پی واقعی بازنویسی می‌شوند، بنابراین حتی اتصال TCP موفق روی پورت‌های دیگر نیز نتایج مشابهی خواهد داد.
3
DNS Hijacking: مشابه poisoning است ولی روی تجهیزات سمت ISP یا نودهای انتقال رخ می‌دهد. مثلاً وقتی کاربر سعی می‌کند روی هر DNS سرور جهانی درخواست کند، سانسورچی درخواست را می‌رباید (مثلاً توسط روتینگ یا تلوزیون) و پاسخ جعلی می‌دهد. در ایران هم گاهی ISPها دستورات دولتی برای تغییر DNS منتشر کرده‌اند.
IP Blocking: مسدودسازی آدرس‌های IP سرورها. اگر فیلتر (مثلاً ISP یا روتینگ) یک IP مقصد را مسدود کند، هیچ بسته‌ای به آن IP نمی‌رسد. این کار می‌تواند روی یک IP خاص، رنج IPها، یا کل ASNهای یک اپراتور انجام شود (ASN blocking). برای نمونه، چین و ایران گاهی IPهای CDN سرویس‌های ممنوع را به طور کلی مسدود می‌کنند. این روش مؤثر است ولی ممکن است سایت‌های مشروعی را هم تحت تأثیر قرار دهد.
BGP Manipulation: تغییر مسیرهای BGP برای جلوگیری از رسیدن ترافیک به خارج یا برای وارد کردن یک مسیر فیک. مثلاً سانسورچی می‌تواند یک مسیر جعلی به سمت یک مقصد تعریف کند که در یک منطقه جغرافیایی بسته باشد، یا کل یک پویش BGP غیرمجاز به منابع داخلی ارسال کند. این کار به ندرت استفاده عمومی دارد ولی می‌تواند سبب قطع بین‌الملل یا دور زدن بخشی از حریم شود.
SNI Filtering: بررسی اسم دامنه در سرآیند TLS (SNI) و مسدود کردن ارتباط در صورت تطابق با فهرست سیاه. مثلاً مقامات چینی و ایرانی سرآیندهای حاوی facebook.com یا نام سایت‌های ممنوعه را خوانده و ارتباط TLS را با TCP RST قطع می‌کنند. SNI به دلیل شفاف بودن یکی از نقاط اصلی عمل DPI در فیلترینگ HTTPS است. بعد از معرفی ECH، شناسایی سخت‌تر شد، اما برخی کشورها حتی ترافیک ESNI/ECH را خود به خود مسدود می‌کنند (به علت ترس از پنهان شدن دامنه). دامنه fronting (در SNI نام دیگری دادن نسبت به HTTP Host) نیز قبلاً استفاده می‌شد تا از فیلتر SNI فرار کنند، اما این کار در سرویس‌دهنده‌های بزرگ معمولاً مسدود شد یا فرستنده‌ها از آن خودداری کردند.
TLS Filtering: بازرسی گواهی سرور و handshake هم می‌تواند استفاده شود. بعضی DPIها فیلتر را روی فیلد‌های گواهی سرور یا محل صدور آن اعمال می‌کنند. برای نمونه در دهه گذشته برخی ISPها (مثلاً در هند) از اطلاعات داخل گواهی (CN یا SAN) برای بلوکه کردن استفاده کرده‌اند. اما در TLS 1.3 این مسیر محدودتر شده است. به هر حال TLS fingerprinting (JA3/JA4) نیز در این دسته قرار می‌گیرد که به شناسایی نرم‌افزار‌ها کمک می‌کند.
TCP Reset Injection: تزریق بسته‌های RST (بازنشانی TCP) از سوی فیلتر تا ارتباط TCP را برهم بزند. فیلتر، با رهگیری جریان TCP، یک بسته RST ساختگی به کلاینت و سرور می‌فرستد تا هر دو فکر کنند طرف مقابل اتصال را بسته است. این روش در ایران و چین و سایر کشورها بسیار رواج دارد؛ مثلاً GFW چین به طور گسترده در مورد ترافیک Tor یا VoIPها از RST استفاده می‌کند. مزیت RST injection این است که کارایی بالایی دارد و خارج از خط ارتباطی کار می‌کند (نیاز به نگهداری وضعیت چندانی ندارد). عیب آن ضرورت حدس صحیح شماره توالی (برای فریب گیرنده) است، اما در کنار DPIهای اولیه معمولاً ممکن است.
TCP/UDP Throttling (Traffic Shaping): کاهش سرعت یا تخصیص کم پهنای‌باند برای بعضی ترافیک‌ها. روش ساده این است که وقتی DPI تشخیص دهد فلان ارتباط حساس است، آن را به شدت محدود می‌کند (QoS Abuse). به عنوان مثال ممکن است اتصالات SSL/TLS با الگوهای مشکوک را پشت صف پهنای‌باند قرار دهند تا کاربر به‌ندرت مکالمه برقرار کند. این تکنیک غیرمستقیم است (بلاک قطعاً کامل نیست اما سرویس عملاً غیرقابل استفاده می‌شود). در برخی موارد دیده شده که فیلتر، حجم یا سرعت VPNها/تور را کاهش می‌دهد تا استفاده از آنها بی‌صرفه شود.
Active Probing: سیستمی که جریان‌های مشکوک را می‌یابد، سپس آدرس آن‌ها را با تلاش اتصال تست می‌کند. مثلاً اگر DPI متوجه الگویی شد که ممکن است سرور پراکسی باشد، سیستم فیلترینگ به عنوان کلاینت مجازی به آن وصل می‌شود و چند بسته تست می‌فرستد. مانند روش Shadowsocks: ایران/چین سرور Shadowsocks احتمالی را با پکت تصادفی یا نسخه‌برداری شده از اولین بسته مشتری پروب می‌کنند؛ اگر سرور پاسخ رمز شده بزرگ داد، تشخیص می‌دهند Shadowsocks است. این مرحله فعال می‌تواند به عنوان فیلتر تکمیلی در DPI دیده شود.
Packet Dropping (Packet Shaping): می‌توانیم جز آنچه گفته شد، اشاره کنیم که سانسورها ممکن است بسته‌ها را رندوم بیاندازند (پرتاب کنند)، یا ترافیک را بخش‌بندی کنند. مثال‌ها: جلوگیری از Fragmentation (مسدود کردن بسته‌های فرگمنت‌شده)، یا کاهش «QoS» بعضی کاربران. OONI و سایر محققان نشان داده‌اند که اگر بسته‌ها را عمداً کوچک کنند یا ترتیب TCP را دستکاری کنند، گاهی ارتباطات خاصی مسدود می‌شوند (روش brdgrd و GoodbyeDPI در خارج نشات می‌گیرد).
3
شناخت، طبقه‌بندی، محدودسازی، مسدودسازی: DPI بسته‌ها را ابتدا شناسایی می‌کند (مثلاً می‌گوید فلان اتصال HTTPS است یا DNS است یا VPN). سپس بر اساس سیاست‌ها طبقه‌بندی می‌شود (مثلاً ترافیک اسکایپ، بیت‌تورنت یا VPN). اگر تصمیم به سانسور باشد، می‌تواند ارتباط را مسدود (Drop یا RST Injection) یا محدود (Throttle) کند. در نهایت ممکن است اطلاعاتی را ذخیره یا گزارش کند (مانند لاگ کردن سایت‌های بازدیدشده). مثلاً در ایران، دیده شده برخی ارتباطات غیرHTTP (مانند SSH, WireGuard, v2ray بدون tls) به طور کامل توسط پروتکل‌فیلتر رد می‌شوند، DNSهای خاص با پاسخ NXDOMAIN تزریق می‌شوند، و ترافیک TLS مربوط به شبکه‌های اجتماعی خاص با RST قطع می‌گردد.
3
part5
تحلیل موردی ایران
از لحاظ فنی، ایران یک سیستم فیلترینگ‌-در-عمق ترکیبی اجرا کرده است. این شامل فیلتر پروتکل (Protocol Filter) سطح پایین و DPI عمیق در لایه بالاتر می‌شود.
معماری فیلترینگ: گزارش‌ها نشان می‌دهد ایران تنها اجازه ترافیک DNS (پروتکل‌های شناسایی‌شده)، HTTP و HTTPS را داده و همه پروتکل‌های دیگر را مسدود کرده است. یعنی اگر بسته‌ای شبیه یک پروتکل غیرمجاز (مثل SSH، OpenVPN، یا WireGuard) در شبکه دیده شود، فیلتر آن را می‌اندازد. این فیلتر روی درگاه‌ها (پورت‌ها) و نیز امضای بسته تمرکز دارد: مثلاً اگر در TCP/443 دست‌دهی «TLS ClientHello» نیايد یا «HTTP GET» نیايد، قطع می‌شود. یافته‌ها نشان می‌دهد که فقط TLS «معمولی» و HTTP با Verbs خاص (GET, POST, HEAD, CONNECT, OPTIONS, DELETE, PUT) مجاز هستند؛ دو Verb دیگر (PATCH و TRACE) مسدودند. از نظر IP، فیلتر روی برخی IPها و نشانی‌های عمومی اعمال نمی‌شود (مثلاً آی‌پی‌های داخلی یا برخی CDNها)، اما روی بیشتر شبکه‌های خارجی فعال است.
نقش DPI: علاوه بر فیلتر پروتکل، ایران از DPI برای فیلتر محتوا استفاده می‌کند. به ویژه TLS Inspection دیده شده است: در جریان اعتراضات ۲۰۱۸، مشخص شد این DPI ترافیک TLS را بازرسی می‌کند تا دست‌دهی را برای سرویس‌های مانند Instagram شناسایی کند. آزمایش‌ها نشان داد هم فیلد SNI و هم Common Name گواهی TLS بازرسی می‌شوند و ارتباطی با Instagram در هر کجا که ظاهر شود قطع می‌شود. DPI در ایران معمولاً روی فیلدهای واضح TLS (و HTTP) متمرکز است، چرا که اتصال TLS را درون HTTPS مسدود می‌کند و پس از آن معمولاً بازگشت ترافیک (TCP RST) می‌فرستد. همچنین گزارش شده که برخی مبتنی بر TLS (مانند SoftEther یا پروکسی‌های مشابه) در صورت عدم انطباق دقیق با فیلتر (مثلاً SNI اشتباه) توسط DPI مسدود می‌شوند.
نقش DNS Filtering: ایران برای مسدودسازی گسترده، همواره DNS را دستکاری کرده. طی سال‌ها غالباً دامنه‌های داخلی و خارجی با پاسخ‌های NXDOMAIN یا IPهای داخلی پاسخ داده شده‌اند. با نصب DNS رمزنگاری‌شده (DoH/DoT) کاربران می‌توانند از سانسور DNS اجتناب کنند، اما فیلتر پروتکل ایران احتمالاً تلاش می‌کند پورت 853 و 443 غیرمرتبط را نیز مسدود کند. همچنین ممکن است DNS عمومی محبوب مثل Google یا Cloudflare را روی DNSهای محلی مسدود کنند. از لحاظ DPI، حتی یک پرسش DoH به میزبان خاص قابل تشخیص است (مثلاً SNI درخواست HTTPS به سرور DNS).
نقش SNI Filtering: همان‌طور که گفته شد، SNI در ایران با DPI بررسی می‌شود (مشخصاً امثال مطبوعات و شبکه‌های اجتماعی). به علاوه، استفاده از SNI رمزنگاری‌شده (ECH) فعلاً رایج نیست. از آنجایی که کلاینت ECH نیاز دارد اول ECHConfig را در DNS یا SNI (بخوانید: در handshake اصلی) دریافت کند، فایروال می‌تواند با بازرسی آن مبادله اولیه از ECH جلوگیری کند. به نظر می‌رسد ایران هنوز عمدتاً به مدل سنتی SNI متکی است (و به محض دیدن یک نام ممنوعه در SNI، ارتباط را قطع می‌کند).
نقش Active Probing: مستندات موثق کمتری در مورد پروب فعال در ایران وجود دارد، ولی گزارش‌های مردمی نشان می‌دهد IPهای پراکسی (مثلاً VPSهای تحت ترافیک اینترنت) گاهی ناگهان قطع می‌شوند و مجدداً برای کارهای غیرمعمول آزمایش می‌گردند. مثلاً گفته شده که قبل از قرار دادن پراکسی، یک سرور HTTPS روی همان آدرس بررسی می‌شود تا ببیند آیا «سیاه‌لیست» نیست. اگر ربات‌های فعال در ایران وجود داشته باشند، احتمالا سرورهای پرترافیک VPN/V2Ray را اسکن می‌کنند. تا کنون تایید رسمی نشده اما به نظر فعال هستند.
نقش Traffic Analysis: DPI ابزار اصلی ایران است، اما ممکن است شبکه در برخی نقاط از تحلیل همزمان بهره ببرد. برای مثال، در زمان اعتراضات اخیر، مشخص شد بسیاری از Probeها (مانند probeهای RIPE Atlas) قطع شدند که گواه آغاز اختلال عمیق بود. ممکن است رفتار بسته‌ها (مثلا تعداد اتصالات باز، یا الگوی ترافیک) زیر نظر باشد تا فعالیت غیرعادی تشخیص داده شود.
نقش IP Reputation: ایران فهرست‌های سیاه IP خاص (اغلب متعلق به سرویس‌های پروکسی، CDNها یا کشورهای خارجی) را نگه می‌دارد. اگر IP یک سرور متعلق به کشوری باشد که عموماً برای عبور از فیلتر استفاده می‌شود (مثلاً سوئد، آمریکا)، احتمال دارد در لیست انسداد قرار گیرد. همچنین، ISPهای ایرانی گاهی جستجوی IPهایی را که تحت تأثیر فایروال است مستقیماً سیاه‌لیست می‌کنند (مثلاً آی‌پی‌هایی که برای Tor یا L2TP شناخته شده‌اند). گزارش‌های مردمی هم اشاره کرده‌اند برخی IPهای VPS حتی قبل از نصب VPN مسدودند، که ظاهراً ناشی از این IP Reputation است.
شناسایی تکنولوژی‌های عبور:
1
برای هر روش عبور، بردار شناسایی مخصوص آن وجود دارد: VPNهای سنتی و V2Ray بدون TLS به روش اول (فیلتر پروتکل) فوراً مسدود می‌شوند؛ به طوری که «فیلتر ایران فقط DNS, HTTP, HTTPS» را قبول دارد. پروتکل‌هایی که دقیقا HTTPS را تقلید می‌کنند (Trojan، XTLS, OpenVPN/TCP) معمولاً عبور می‌کنند اما ممکن است توسط DPI محتوا یا زیرساخت‌های TLS تشخیص داده شوند. Shadowsocks/Outline توسط active probing/امضاء در نگاه اول قابل تشخیص است؛ VPNهای UDP (WireGuard) به دلیل الگوی باینری مشخص شناسایی می‌شوند.
در مجموع، ایران ابزارهای مختلفی در لایه‌های گوناگون به کار می‌گیرد:
ابتدا جریان را شناسایی می‌کند (انتخاب بر اساس آدرس/پورت/امضاء بسته)
سپس محتوا را (با DPI و امضاءها) طبقه‌بندی می‌کند
و در صورت لزوم ارتباط را با RST، DNS جعلی یا Drop مسدود/محدود می‌سازد.
این گزارش نتیجه تحقیقات گوناگون و گزارش‌های فنی است که برای هر موضوع به منابع معتبر (IETF, IEEE, USENIX, Cloudflare, متون TLS, DPI, گزارشات سانسور) استناد کرده‌ایم. اطلاعات مربوط به ایران عمدتاً از گزارش‌های میدان و تحقیقات مستقل استخراج شده است.
3
Mr. Nothing
V0IDNETWORK is an ongoing, open research effort to document — rigorously and accurately — how the modern Internet's circumvention and surveillance technologies actually work at the protocol level, in support of a more open and resilient Internet. 🌐 Website…
کانال یوتیوب و داشته باشین بزودی دوره c و شروع به آپلود میکنم
سر فصل ها:
مقدماتی C (حدود ۱۵ ساعت)
فصل 1: آشنایی با برنامه‌نویسی و زبان C (۱ ساعت)
برنامه‌نویسی چیست؟
زبان‌های سطح بالا و پایین
تاریخچه C
کاربردهای C
کامپایلر چیست؟
Interpreter و Compiler
نصب GCC
نصب VS Code
اجرای اولین برنامه
فصل 2: ساختار برنامه در C (۴۵ دقیقه)
تابع main
فایل‌های source
Header ها
دستورات
کامنت‌ها
استانداردهای نام‌گذاری
فصل 3: متغیرها و انواع داده (۱ ساعت)
مفهوم حافظه
متغیر چیست؟
int
float
double
char
bool
size_t
sizeof
محدوده انواع داده
فصل 4: ورودی و خروجی (۱ ساعت)
printf
scanf
فرمت‌ها
دریافت چند ورودی
خطاهای رایج scanf
فصل 5: عملگرها (۱ ساعت)
عملگرهای حسابی
تقدم عملگرها
عملگرهای مقایسه‌ای
عملگرهای منطقی
عملگرهای انتساب
افزایش و کاهش
فصل 6: شرط‌ها (۱.۵ ساعت)
if
if else
else if
switch case
عملگر سه‌تایی
مثال‌های عملی
فصل 7: حلقه‌ها (۱.۵ ساعت)
while
do while
for
break
continue
حلقه‌های تو در تو
فصل 8: توابع (۲ ساعت)
تعریف تابع
اعلان تابع
آرگومان‌ها
مقدار بازگشتی
Scope
توابع بازگشتی (Recursion)
فصل 9: آرایه‌ها (۱.۵ ساعت)
آرایه یک بعدی
پیمایش آرایه
جستجو
مرتب‌سازی ساده
آرایه دوبعدی
فصل 10: رشته‌ها (۱.۵ ساعت)
String چیست؟
آرایه char
fgets
strlen
strcpy
strcmp
strcat
فصل 11: پروژه‌های مقدماتی (۲ ساعت)
پروژه ماشین حساب
چهار عمل اصلی
پروژه حدس عدد
تولید عدد تصادفی
پروژه مدیریت نمرات
دریافت و محاسبه معدل
دوره پیشرفته C (حدود ۲۵ ساعت)
فصل 1: مرور سریع مباحث مقدماتی (۱ ساعت)
فصل 2: حافظه و مدل اجرای برنامه (۲ ساعت)
Stack
Heap
Data Segment
Code Segment
چرخه عمر متغیرها
فصل 3: Pointer ها از پایه تا پیشرفته (۴ ساعت)
مفهوم آدرس
Pointer Variables
Dereference
Pointer Arithmetic
Pointer و Array
Pointer و String
Pointer به Pointer
Void Pointer
Const Pointer
فصل 4: حافظه پویا (۲ ساعت)
malloc
calloc
realloc
free
Memory Leak
Dangling Pointer
فصل 5: ساختارها (Struct) (۲ ساعت)
تعریف Struct
Nested Struct
Struct Array
Struct و Pointer
فصل 6: Union و Enum (۱ ساعت)
Union
Enum
کاربردهای واقعی
فصل 7: فایل‌ها (۲ ساعت)
fopen
fclose
fprintf
fscanf
fread
fwrite
فایل‌های متنی
فایل‌های باینری
فصل 8: Preprocessor (۱.۵ ساعت)
#include
#define
Macro
Conditional Compilation
فصل 9: پروژه چند فایلی (۱.۵ ساعت)
Header File
Source File
Linker
Modular Programming
فصل 10: تابع‌های پیشرفته (۱.۵ ساعت)
Function Pointer
Callback
Variadic Functions
فصل 11: ساختمان داده با C (۴ ساعت)
Linked List
Single
Double
Stack
Queue
Circular Queue
فصل 12: الگوریتم‌ها در C (۲ ساعت)
Bubble Sort
Selection Sort
Insertion Sort
Binary Search
Linear Search
فصل 13: Debugging و Error Handling (۱ ساعت)
GDB
Debug در VS Code
Segmentation Fault
Buffer Overflow
فصل 14: پروژه‌های حرفه‌ای (۵ ساعت)
پروژه مدیریت کتابخانه
ذخیره در فایل
پروژه مدیریت کارمندان
CRUD کامل
پروژه دفترچه تلفن
جستجو
ذخیره
پروژه Student Management System
استفاده از Struct
File
Dynamic Memory
باج افزار
کیلاگر
رمز نگاری های پیشرفته

یه اپدیتم قراره بزودی ظبط کنم
بخش 1: معماری نرم‌افزارهای دسکتاپ (۱ ساعت)
Console Application
Desktop Application
Event Driven Programming
Message Loop
معماری GUI
طراحی پروژه‌های واقعی
بخش 2: آشنایی با GUI در C (۱ ساعت)
GUI چیست؟
Widget چیست؟
Button
TextBox
Label
Menu
Dialog

مقایسه:

GTK
Qt
WinAPI
SDL
بخش 3: GTK برای ساخت رابط گرافیکی (۴ ساعت)
نصب GTK
اولین پنجره
ساخت Window
Label
Button
Event Handling
Click Event
Keyboard Event
Layout
Grid
Box Layout
فرم‌ها
Text Entry
Combo Box
Check Box
پروژه
ماشین حساب گرافیکی
بخش 4: کار با فایل در اپلیکیشن‌ها (۱ ساعت)
Open File Dialog
Save File Dialog
خواندن فایل
ذخیره اطلاعات
بخش 5: ساخت نرم‌افزار Notepad (۲ ساعت)
Text Editor
Open
Save
Save As
Menu
بخش 6: پروژه مدیریت کاربران (۲ ساعت)
فرم ثبت
جستجو
ویرایش
حذف
ذخیره در فایل
بخش حرفه‌ای: Packaging و انتشار نرم‌افزار (۳ ساعت)
مفهوم Build
Debug Build
Release Build
ساخت فایل اجرایی
ویندوز
exe
dll
لینوکس
ELF
Shared Libraries
Dependency Management
کتابخانه‌های موردنیاز
Runtime Libraries
Installer سازی
Windows
Inno Setup
NSIS
Linux
deb
rpm
امضای نرم‌افزار
Code Signing
Versioning
∆ Join VOID
3
VOID pinned «part ۰ شبکه (Networking) در مدل مرجع OSI، داده‌ها از لایه کاربرد (مانند HTTP، DNS) به ترتیب به لایه‌های انتقال (TCP/UDP)، شبکه (IP)، پیوند داده (Ethernet) و فیزیکی منتقل می‌شوند. برای مثال یک بسته HTTP ابتدا در لایه کاربرد ساخته شده، در لایه انتقال با سرآیند…»
The One That Got Away
Katy Perry, B.o.B
In another life
I would make you stay
So I don't have to say
You were the one that got away
The one that got away
∆ Join VOID
3