━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

مثال واقعی

فرض کنید مهاجم:

GenericWrite

روی یک Computer Object داشته باشد.

در نگاه اول:

Low Risk

به نظر می‌رسد.

اما همین مجوز می‌تواند منجر شود به:

Computer Takeover
↓
RBCD
↓
Kerberos Impersonation
↓
Service Takeover
↓
Domain Escalation

یک ACL ساده.

یک Forest نابود شده.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فصل ششم
چرا BloodHound انقلابی ایجاد کرد؟

قبل از BloodHound تحلیل AD تقریباً غیرممکن بود.

زیرا ذهن انسان توان تحلیل میلیون‌ها رابطه را ندارد.

BloodHound برای اولین بار نشان داد:

امنیت Active Directory
=
مسئله Graph Theory

است.

سؤال اصلی دیگر این نبود:

آیا آسیب‌پذیری وجود دارد؟

بلکه:

آیا مسیر وجود دارد؟

بود.

و تقریباً همیشه پاسخ:

بله

است.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فصل هفتم
AD CS؛ کابوس جدید مدافعان

سال‌ها تصور می‌شد Kerberos بزرگ‌ترین Attack Surface هویتی است.

اما کشف حملات ESC نشان داد:

PKI از بسیاری جهات خطرناک‌تر است.

چرا؟

زیرا Password قابل تغییر است.

Hash قابل چرخش است.

Ticket منقضی می‌شود.

اما Certificate می‌تواند هویت را بازتعریف کند.

زمانی که مهاجم بتواند:

Enrollment Policy

Template

CA Configuration

Certificate Mapping

را تحت کنترل بگیرد، عملاً می‌تواند:

Identity Forge

انجام دهد.

یعنی خلق هویت معتبر بدون نیاز به Credential واقعی.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

نمونه حملات مشهور AD CS

ESC1

ESC3

ESC4

ESC8

ESC13

ESC16

هر کدام نمونه‌ای از سوءاستفاده از زنجیره اعتماد PKI هستند.

نکته ترسناک:

بسیاری از این حملات حتی نیازمند Domain Admin نیستند.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فصل هشتم
Trust؛ میدان واقعی جنگ

بیشتر تیم‌های دفاعی در سطح Domain فکر می‌کنند.

اما مهاجم حرفه‌ای در سطح Forest فکر می‌کند.

زیرا Forest واحد واقعی اعتماد است.

مفاهیم کلیدی:

Parent-Child Trust

Forest Trust

External Trust

SID Filtering

Selective Authentication

Cross Forest Kerberos

Trustها تعیین می‌کنند:

یک نفوذ محلی

چگونه

به یک بحران سازمانی

تبدیل شود.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فصل نهم
Tier-0؛ تاج پادشاهی

بسیاری تصور می‌کنند:

Domain Admin

بالاترین سطح دسترسی است.

اما در معماری مدرن مایکروسافت این تصور اشتباه است.

هدف واقعی:

Tier-0

است.

Tier-0 شامل:

Domain Controllers

Enterprise CA

ADFS

Entra Connect

Azure AD Connect

Privileged Access Workstations

Identity Management Systems

است.

کنترل Tier-0 یعنی:

کنترل اعتماد

کنترل اعتماد یعنی:

کنترل سازمان

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فصل دهم
چرا AD از Exploit Development سخت‌تر است؟

Exploit Development معمولاً ساختار مشخصی دارد:

Bug
↓
Primitive
↓
Weaponization
↓
Exploit

اما Active Directory هیچ ساختار ثابتی ندارد.

هر سازمان:

Trust متفاوت

PKI متفاوت

Delegation متفاوت

ACL متفاوت

Tiering متفاوت

Architecture متفاوت

دارد.

بنابراین هیچ Playbook جهانی وجود ندارد.

هر عملیات نیازمند:

Threat Modeling

Identity Mapping

Trust Analysis

Graph Traversal

Privilege Correlation

است.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

فرمول ذهنی Red Teamهای سطح بالا

Initial Access
+
Identity Intelligence
+
Trust Analysis
+
Graph Traversal
+
Privilege Escalation Primitive
+
Tier-0 Path Discovery
=
Enterprise Compromise

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

جمع‌بندی نهایی

Active Directory درباره هک کردن سیستم‌ها نیست.

درباره فهمیدن اعتماد است.

Kerberos درباره Ticket نیست.

درباره جریان اعتماد است.

PKI درباره Certificate نیست.

درباره حاکمیت هویت است.

Trustها درباره اتصال Domainها نیستند.

درباره گسترش مرزهای نفوذ هستند.

و Tier-0 درباره Administratorها نیست.

درباره مالکیت کامل Fabric هویتی سازمان است.

اپراتوری که بتواند:

• Kerberos را در سطح State Machine تحلیل کند
• Graphهای دسترسی را مدل‌سازی کند
• Delegation Chainها را کشف کند
• PKI را به‌عنوان Attack Surface مستقل بررسی کند
• Trust Boundaryها را مهندسی معکوس کند
• و Tier-0 را از منظر معماری امنیتی درک کند

دیگر صرفاً یک Pentester یا Red Teamer نیست.

او در حال تحلیل و تسخیر پیچیده‌ترین دارایی امنیتی سازمان است:

Identity Fabric

لایه‌ای که امروز ارزشمندتر از سرورها،
حساس‌تر از داده‌ها،
و حیاتی‌تر از زیرساخت فیزیکی محسوب می‌شود.

زیرا در نهایت:

کسی که هویت را کنترل می‌کند،
سازمان را کنترل می‌کند.

∆ Join VOID ∆

چرا امنیت BGP یکی از پیچیده‌ترین مباحث شبکه محسوب می‌شود؟

بیشتر متخصصان شبکه در طول فعالیت حرفه‌ای خود با VLAN، OSPF، VPN و حتی MPLS کار می‌کنند، اما تعداد بسیار کمی از مهندسان وارد لایه‌ای می‌شوند که اینترنت جهانی بر روی آن ساخته شده است.

در این لایه، صحبت از یک سازمان یا یک دیتاسنتر نیست؛ صحبت از هزاران Autonomous System، میلیون‌ها Prefix و صدها هزار Policy Routing است که به صورت همزمان اینترنت را زنده نگه می‌دارند.

BGP صرفاً یک پروتکل مسیریابی نیست؛ بلکه یک سیستم توزیع اعتماد در مقیاس جهانی است.


---

مشکل اصلی BGP: اعتماد پیش‌فرض

برخلاف تصور بسیاری از افراد، BGP در طراحی اولیه تقریباً هیچ مکانیزم ذاتی برای اعتبارسنجی مسیرها نداشت.

زمانی که یک AS اعلام می‌کند:

> من مالک این Prefix هستم.



همسایه‌ها معمولاً این ادعا را قبول می‌کنند.

این مدل اعتماد باعث شکل‌گیری یکی از خطرناک‌ترین حملات تاریخ اینترنت شده است:

Route Hijacking

در این سناریو یک Autonomous System مسیرهایی را اعلام می‌کند که در واقع متعلق به آن نیست.

در نتیجه:

ترافیک منحرف می‌شود.

اطلاعات رهگیری می‌شوند.

سرویس‌ها از دسترس خارج می‌شوند.

مسیرهای اینترنت تغییر می‌کنند.



---

Route Leak؛ حمله‌ای که همیشه عمدی نیست

یکی از پیچیده‌ترین مشکلات اینترنت مدرن Route Leak است.

در این حالت یک اپراتور یا ISP به اشتباه Routeهایی را منتشر می‌کند که نباید منتشر شوند.

نتیجه می‌تواند شامل موارد زیر باشد:

افزایش شدید Latency

Congestion

قطع ارتباط بین قاره‌ها

Blackholing ترافیک


برخی از بزرگ‌ترین اختلال‌های اینترنت در دهه گذشته ناشی از Route Leak بوده‌اند، نه حملات سایبری کلاسیک.


---

Traffic Engineering؛ هنر کنترل اینترنت

در شبکه‌های سازمانی معمولاً مسیر کوتاه‌تر انتخاب می‌شود.

اما در BGP موضوع متفاوت است.

مهندسان Carrier-Level دائماً با Attributeهایی مانند:

Local Preference

MED

AS Path

Community

Extended Community


کار می‌کنند تا رفتار ترافیک را کنترل کنند.

هدف همیشه کوتاه‌ترین مسیر نیست.

گاهی اوقات:

ارزان‌ترین مسیر

پایدارترین مسیر

کم‌ترافیک‌ترین مسیر

امن‌ترین مسیر


اولویت بالاتری دارد.


---

RPKI؛ تلاش برای حل بحران اعتماد

با افزایش حملات BGP، مکانیزمی به نام Resource Public Key Infrastructure ایجاد شد.

RPKI تلاش می‌کند مشخص کند:

کدام Autonomous System مجاز است یک Prefix خاص را Advertise کند.

اما پیاده‌سازی RPKI در مقیاس جهانی چالش‌های متعددی دارد:

پیچیدگی عملیاتی

وابستگی به Trust Anchorها

ناسازگاری برخی تجهیزات قدیمی

مشکلات سیاست‌گذاری بین اپراتورها


به همین دلیل هنوز هم اینترنت کاملاً در برابر Hijack ایمن نشده است.


---

BGP در محیط‌های Red Team

بیشتر افراد BGP را صرفاً موضوعی برای مهندسان ISP می‌دانند.

اما تیم‌های Red Team پیشرفته و گروه‌های APT به خوبی می‌دانند که کنترل مسیرهای شبکه گاهی از نفوذ به یک سرور ارزشمندتر است.

زیرا در صورت کنترل مسیر:

امکان رهگیری ترافیک فراهم می‌شود.

حملات Man-in-the-Middle ساده‌تر می‌شوند.

سامانه‌های امنیتی دور زده می‌شوند.

Visibility مدافعان کاهش می‌یابد.


به همین دلیل امنیت Routing Infrastructure یکی از بخش‌های حیاتی دفاع سایبری در سطح ملی محسوب می‌شود.


---

چرا یادگیری این حوزه دشوار است؟

زیرا برای درک واقعی آن باید همزمان بر چند حوزه مسلط باشید:

Routing پیشرفته

Architecture اینترنت

MPLS

Carrier Networking

Internet Exchange Point

PKI

Cryptography

Traffic Engineering

Incident Response


این حجم از دانش باعث شده امنیت BGP و Routing Infrastructure یکی از معدود حوزه‌هایی باشد که حتی بسیاری از متخصصان ارشد امنیت نیز در آن تجربه عملی محدودی دارند.


---

نتیجه

اگر Active Directory را قلب شبکه‌های سازمانی بدانیم، BGP قلب اینترنت است.

درک عمیق BGP دیگر صرفاً یک مهارت شبکه نیست؛ بلکه شناخت مکانیزمی است که کل اینترنت بر پایه آن تصمیم می‌گیرد هر بسته داده از کدام مسیر عبور کند. به همین دلیل امنیت BGP، Route Hijacking، Route Leak و RPKI از پیچیده‌ترین و تخصصی‌ترین مباحث دنیای شبکه و امنیت سایبری محسوب می‌شوند.

∆ Join VOID ∆

مطالب بالا آماده سازیشون یکم طول کشید، احتمالا چند وقت دیگه یکسری مطلب از اثراتی که وایب کدینگ و استفاده از Ai برای برنامه نویسی روی جامعه گذاشته آماده کنم و بزارم ❤️

∆ Join VOID ∆

لینوکس در معنای دقیقش کرنل است، نه کل سیستم‌عامل. کرنل مسئول مدیریت سخت‌افزار، منابع سیستم و سرویس‌های پایه‌ای برای نرم‌افزارهای دیگر است؛ به همین دلیل هم اسناد رسمی کرنل، آن را «هستهٔ هر سیستم‌عامل لینوکسی» توصیف می‌کنند. خود پروژهٔ کرنل هم بسیار بزرگ است: در مستندات رسمی از بیش از ۸ میلیون خط کد و بیش از ۱۰۰۰ مشارکت‌کننده برای هر انتشار صحبت می‌شود. این اندازه و پیچیدگی باعث می‌شود که لینوکس را بهتر است نه یک محصول واحد، بلکه یک اکوسیستم مهندسی‌شده ببینیم.

از نظر فنی، کرنل لینوکس به زیرسامانه‌های مشخصی مثل شبکه، حافظه، پشتیبانی معماری‌ها و درایورها تقسیم شده و هر زیرسامانه معمولاً نگه‌دارندهٔ مخصوص خودش را دارد. در نتیجه، توسعهٔ کرنل «یک تکه کد عظیم» نیست؛ یک ساختار لایه‌دار با فرایند merge window، بازبینی، و نگه‌داری زیرسامانه‌ای است. همین‌طور، کد کرنل عمدتاً با C نوشته می‌شود و به‌طور معمول با گویش GNU C11 کامپایل می‌شود، با بخش‌هایی هم به اسمبلی وابسته به معماری.

شاخه‌بندی انتشار هم مهم است: upstream لینوکس فقط «mainline» نیست، بلکه شاخه‌های stable و longterm هم دارد. در عین حال، خود kernel.org صریح می‌گوید کرنل‌هایی که توزیع‌ها با backport و patch نگه می‌دارند ممکن است بر پایهٔ شاخه‌های رسمی باشند یا نباشند، و این کرنل‌های توزیعی لزوماً تحت پشتیبانی مستقیم توسعه‌دهندگان kernel.org نیستند. این نکته برای درک تفاوت «کرنلِ upstream» با «کرنلِ توزیع» حیاتی است.

اینجا به نقطهٔ اصلی می‌رسیم: توزیع فقط «لینوکس» نیست، بلکه یک بستهٔ کامل از سیاست‌ها، ابزارها، مخازن، مدیر بسته، انتخاب کرنل، سیکل انتشار، و سطح نگه‌داری است. بنابراین وقتی می‌گوییم «Debian بهتر است» یا «Arch بهتر است»، در واقع داریم دربارهٔ یک مدل عملیاتی حرف می‌زنیم: چه‌قدر تازگی بسته‌ها مهم است، چه‌قدر پایداری مهم است، و چه‌قدر می‌خواهی خودت مدیر سیستم باشی.

دسته‌بندی حرفه‌ای توزیع‌ها

Debian Stable نمایندهٔ کلاس «پایداری محافظه‌کارانه» است. طبق مستند رسمی، هر انتشار stable در مجموع پنج سال چرخهٔ عمر دارد: سه سال پشتیبانی کامل و دو سال LTS. این مدل برای سرور، زیرساخت، و سیستم‌هایی که تغییر کم و پیش‌بینی‌پذیری بالا می‌خواهند بسیار مناسب است؛ اما بهایش این است که بسته‌ها معمولاً از نوترین نسخه‌ها عقب‌تر می‌مانند.

Ubuntu LTS نسخهٔ «تعادل میان دسترسی‌پذیری و پایداری» است. مستند رسمی اوبونتو می‌گوید LTSها هر دو سال منتشر می‌شوند، ۵ سال پشتیبانی استاندارد امنیتی دارند، و در مجموع ۱۰ سال نگه‌داری می‌شوند؛ با Ubuntu Pro و Legacy support حتی می‌تواند بیشتر هم بشود. به همین دلیل Ubuntu LTS برای دسکتاپ عمومی، سرور، و محیط‌هایی که هم اکوسیستم بزرگ می‌خواهند هم دردسر کم، بسیار محبوب است.

Fedora توزیعی است که عمداً سریع حرکت می‌کند. مستندات رسمی فدورا می‌گویند انتشارها تقریباً هر شش ماه یک‌بار انجام می‌شود و هر انتشار حدود ۱۳ ماه پشتیبانی می‌گیرد. فلسفهٔ فدورا این است که فناوری‌های جدید را زودتر وارد چرخه کند؛ برای توسعه‌دهنده‌ها، تسترها، و کسانی که سخت‌افزار یا نرم‌افزار جدید دارند، این مزیت بزرگی است. اما همین سرعت، آن را برای کسانی که هر چند سال یک‌بار سیستم را «راه بینداز و فراموش کن» می‌خواهند، کمتر مناسب می‌کند.

Arch Linux نمایندهٔ مدل rolling release است. سایت رسمی Arch می‌گوید این توزیع lightweight و flexible است و با مدل «rolling release» نصب یک‌باره و به‌روزرسانی پیوسته را دنبال می‌کند. این یعنی بعد از نصب اولیه، قرار نیست از نسخه‌ای به نسخهٔ دیگر مهاجرت بزرگ داشته باشی؛ سیستم دائماً جلو می‌رود. این مدل برای کاربرانی که کنترل دقیق، بسته‌های تازه، و حداقل تزئینات پیش‌فرض می‌خواهند عالی است، اما به همان اندازه هم انتظار می‌رود که نگه‌داری و مطالعهٔ سیستم را جدی بگیری.

openSUSE Tumbleweed یکی از حرفه‌ای‌ترین rolling releaseهاست، چون rolling بودن را با کنترل کیفی جدی ترکیب می‌کند. صفحهٔ رسمی Tumbleweed می‌گوید که این توزیع «latest stable versions» را ارائه می‌کند، با تست‌های گسترده و حتی امکان rollback با snapshot. این یعنی اگر rolling release می‌خواهی ولی از ایدهٔ «rolling بی‌مهار» می‌ترسی، Tumbleweed یک گزینهٔ بسیار بالغ است.

openSUSE Leap در سوی دیگر این طیف است: نسخه‌ای با تمرکز قوی بر ثبات و lifecycle طولانی. مستندات رسمی Leap 16 از چرخهٔ ۲۴ ماهه برای هر minor release و رویکرد هیبریدیِ مبتنی بر SLE و توسعهٔ جامعه صحبت می‌کنند. Leap برای کسانی که از پایداری سطح enterprise خوششان می‌آید ولی فضای open-source و ابزارهای openSUSE را ترجیح می‌دهند، بسیار جذاب است.

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 ∆

و اگرم دیدین شخصی بشدت بر روی یک توزیع تعصب دارد
نمونه های مانند کالی لینوکس و بلک ارچ
بهش سخت نگیرید

در کل نباید بر سیستم ها و ابزار ها تعصب داشت
آنها توسعه دیدن که مورد استفاده قرار گیرند و نیازی به تعصب ندارند
خوده بنده به شخصه ویندوز و گاها ارچ استفاده میکنم

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، برای رزومه جلسه نیز بلیتی مبادله می‌شود که در بازگشایی مجدد ارتباط مفید است.

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 (تبادل پورت‌ها و پیام‌های شناخته‌شده) تشخیص دهد. مقاومت در برابر فیلترینگ متوسط است؛ چون ترافیک رمزنگاری‌شده است، اما پروتکل‌ها و پورت‌های خاص قابل شناسایی‌اند. حملات فعال یا پیکربندی نادرست ممکن است منجر به ردیابی شود.

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 به الگوی ارتباطی آن بستگی دارد. به طور خلاصه:

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 کرد (بدون توجه به اینکه دامنه چه هست).

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 پس از دست‌دهی). این فناوری‌ها طراحی شده‌اند تا اثرانگشت پروکسی را مخفی کنند و شناسایی ترافیک سخت‌تر گردد.
پروتکل‌های مهم:

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 برای آن لازم است.

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 مسدود شده باشد).

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 باز باشد این تکنیک می‌تواند ترافیک را در ظاهر ترافیک وب قرار دهد.

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 را هَش می‌زند و با پایگاه امضاء خود مقایسه می‌کند.

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 موفق روی پورت‌های دیگر نیز نتایج مشابهی خواهد داد.

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 در خارج نشات می‌گیرد).

شناخت، طبقه‌بندی، محدودسازی، مسدودسازی: DPI بسته‌ها را ابتدا شناسایی می‌کند (مثلاً می‌گوید فلان اتصال HTTPS است یا DNS است یا VPN). سپس بر اساس سیاست‌ها طبقه‌بندی می‌شود (مثلاً ترافیک اسکایپ، بیت‌تورنت یا VPN). اگر تصمیم به سانسور باشد، می‌تواند ارتباط را مسدود (Drop یا RST Injection) یا محدود (Throttle) کند. در نهایت ممکن است اطلاعاتی را ذخیره یا گزارش کند (مانند لاگ کردن سایت‌های بازدیدشده). مثلاً در ایران، دیده شده برخی ارتباطات غیرHTTP (مانند SSH, WireGuard, v2ray بدون tls) به طور کامل توسط پروتکل‌فیلتر رد می‌شوند، DNSهای خاص با پاسخ NXDOMAIN تزریق می‌شوند، و ترافیک TLS مربوط به شبکه‌های اجتماعی خاص با RST قطع می‌گردد.