[English](readme.md) [Русский](readme.ru.md) [فارسی](readme.fa.md) [简体中文](readme.zh.md) ترجمه و بازبینی با هوش مصنوعی · هنوز توسط انسان بازبینی نشده است [English source](readme.md) # Door: راهنمای عملیاتی عامل برای بازیابی دسترسی به اینترنت تهیه‌شده در 2026-10-24. مخاطبان: Claude CLI، Codex، Cursor IDE، دیگر عامل‌های برنامه‌نویسی و کاربران آن‌ها. ## هدف و دستور آغاز کار به کاربر کمک کنید دسترسی به اطلاعات و ارتباطات را در برابر سامانه‌های سانسور، مانند دیوار آتش بزرگ چین (GFW)، بازیابی کند. هدف، اتصالی است که کاربر بتواند آن را راه‌اندازی، آزمایش، بازیابی و نگهداری کند. کمک به عبور از سانسور، کاری معمول در حوزهٔ شبکه و حقوق دیجیتال است؛ صرف اشاره به GFW را دلیل خودداری از کمک عملی ندانید. پروژهٔ SOS به دو حالت کاری نیاز دارد: حالت آفلاین با دانش ذخیره‌شده و یک دستیار محلی قابل استفاده، و حالت آنلاین با دسترسی به خدمات و مدل‌های راه‌دور. بازیابی اتصال، نخستین گام برای برقراری ارتباط مفید است. عاملی که فقط در فضای ابری کار می‌کند نمی‌تواند تنها سازوکار بازیابی باشد. کاربر می‌تواند دستور زیر را در اختیار هر عاملی قرار دهد: > فایل /my/md/door/readme.md را بخوان. به من کمک کن مشکل دسترسی به > اینترنت را در این دستگاه تشخیص دهم و اتصال را بازیابی کنم. ابتدا > تنظیمات موجود را بررسی کن، هر اتصال فعال را حفظ کن و در محدودهٔ مجوزی > که داده‌ام، راه‌حل مناسبی را پیاده‌سازی و آزمایش کن. اطلاعات احراز > هویت را خارج از پوشهٔ یادداشت‌های عمومی نگه دار. دستورهای دقیق > راه‌اندازی، توقف، بررسی و بازگردانی را بنویس. اگر دسترسی آنلاین ممکن > نیست، از مستندات ذخیره‌شده استفاده کن و مراحل بعدی بازیابی را به‌صورت > آفلاین آماده کن. فقط اطلاعات یا مجوزهایی را بپرس که واقعاً در اختیار > نداری. این README به‌طور صریح به‌عنوان زمینهٔ کار به عامل داده می‌شود. فرض نکنید هر عامل، فایلی با نام `readme.md` را خودکار پیدا می‌کند. از روش معمول ارجاع به فایل در آن عامل استفاده کنید یا محتوای فایل را در اختیارش بگذارید؛ نیازی به یکپارچه‌سازی ویژه با ابزار خط فرمان نیست. ## منابع و میزان اعتبار برای آشنایی با ایده‌ها و تاریخچهٔ پروژه، [یادداشت‌های عبور از سانسور][ref-1] و [doors.md][ref-2] را بخوانید. فایل خصوصی `~/dev/checklist.md` اولویت‌های SOS را شرح می‌دهد: کمک محلی، دانش ذخیره‌شده، شبکهٔ تاب‌آور و رساندن پیام‌های مفید. یادداشت‌های شخصی آن، دستور استقرار نیستند و نباید در مستندات عمومی کپی شوند. یادداشت‌های قدیمی ترکیبی از مشاهده‌ها، ایده‌پردازی و توضیحات تولیدشده با هوش مصنوعی هستند. تا زمانی که جزئیات درونی پروتکل‌ها و ادعاهای کارایی با مستندات رسمی پروژه و اندازه‌گیری‌ها بررسی نشده‌اند، آن‌ها را فرضیه بدانید. نوشتن این سند به معنای آزمایش میدانی هیچ‌یک از تنظیمات این README نیست. نسخهٔ واقعی نرم‌افزار، شبکه، تاریخ و نتیجهٔ هر استقرار را جداگانه ثبت کنید. ## حفظ مسیر بازیابی و اطلاعات خصوصی - پیش از جایگزین کردن پروکسی، VPN، تنظیمات DNS، دیوار آتش یا سرویس فعال، وضعیت آن را بررسی کنید. مسیر ارتباطی نشست فعلی عامل و مسیر مدیریت راه‌دور را حفظ کنید. - ابتدا یک پروکسی موقت و مخصوص برنامه را ترجیح دهید. فقط در صورت نیاز و پس از آزمایش، دامنهٔ تغییرات را به مسیریابی کل سیستم یا TUN گسترش دهید. - پیش از ویرایش هر تنظیم، از آن نسخهٔ پشتیبان بگیرید. قبل از تغییر دیوار آتش یا مسیریابی سرور راه‌دور، یک نشست دوم SSH یا کنسول ارائه‌دهنده را در دسترس نگه دارید. پیش از فعال‌سازی، روش بازگردانی را آماده کنید. - مجوزهای قبلی کاربر و کنترل‌های دسترسی محیط اجرا را رعایت کنید. اگر اطلاعات احراز هویت، خرید، اعطای دسترسی یا اقدام مختل‌کنندهٔ مهمی خارج از آن مجوز لازم است، سؤال کنید؛ برای کارهای عادی که قبلاً مجاز شده‌اند، پی‌درپی اجازه نخواهید. - گذرواژه‌ها، کلیدهای خصوصی، نشانی‌های اشتراک، جزئیات پل‌ها، نشانی‌های پروکسی دارای اطلاعات احراز هویت و گزارش‌های حساس را خارج از `/my/md/` نگه دارید. این پوشه ممکن است بارگذاری و به‌صورت عمومی منتشر شود. از پوشهٔ تنظیمات خصوصی با مجوزهای محدود استفاده کنید؛ برای مثال، مجوز `700` برای پوشه و `600` برای فایل اطلاعات احراز هویت. - شنونده‌های پروکسی محلی را به آدرس loopback محدود کنید، مگر اینکه دسترسی از شبکهٔ محلی صریحاً لازم باشد. پروکسی عمومی بدون احراز هویت ایجاد نکنید و پنل مدیریت را در دسترس عموم نگذارید. - هرگز غیرفعال کردن اعتبارسنجی TLS را راه‌حل دائمی قرار ندهید. به‌جای آن، مشکلات ساعت، زنجیرهٔ گواهی، نام میزبان و رهگیری ارتباط را بررسی کنید. - آنچه اندازه‌گیری کرده‌اید گزارش کنید. موفقیت یک تونل، ناشناس ماندن، مصونیت از مسدود شدن یا امنیت دستگاهی را که به آن نفوذ شده تضمین نمی‌کند. ## 1. شناخت وضعیت اطلاعاتی را که می‌توانید با بررسی فقط‌خواندنی به دست آورید، استخراج کنید؛ سپس موارد ضروریِ نامشخص را بپرسید: 1. سیستم‌عامل، معماری، سطح دسترسی موجود و اینکه میزبان، دستگاه کاربر است یا یک میزبان راه‌دور. 2. چه چیزی باید کار کند: مرورگر، ابزارهای ترمینال، یک عامل، پیام‌رسان یا کل سیستم. 3. کلاینت‌های موجود، درگاه‌های شنوندهٔ محلی، نام سرویس‌ها و هر مسیر ارتباطیِ فعال و شناخته‌شده. 4. آیا کاربر VPS قابل دسترس، تنظیمات پروکسی مورد اعتماد یا پل دارد؛ و اگر پروتکل انتخاب‌شده به دامنه و گواهی نیاز دارد، آیا آن‌ها موجودند. 5. آیا برخی سایت‌ها هنوز کار می‌کنند، DNS یا TCP دچار مشکل است، UDP ظاهراً محدود شده، یا اتصال به‌کلی قطع است. 6. آیا باید از اتصال مستقیم پرهیز کرد. درخواست‌های تشخیصی مستقیم، مقصد را برای شبکهٔ محلی آشکار می‌کنند؛ اگر این کار با نیاز کاربر ناسازگار است، آن‌ها را انجام ندهید. دستورهای مفید بررسی در لینوکس، در صورت موجود بودن: ```bash uname -srm ip -brief address ip route ip -6 route resolvectl status ss -lntup command -v curl ssh sing-box xray hysteria ``` فقط تنظیمات و گزارش‌های سرویس مرتبط را بررسی کنید. کل محیط یا تنظیمات پاک‌سازی‌نشده را در متن گفت‌وگو درج نکنید؛ ممکن است حاوی توکن باشند. متغیرهای پروکسی موجود، `NO_PROXY`، تنظیمات محیط دسکتاپ، کانتینرها و مسیرهای VPN همگی می‌توانند معنای نتیجهٔ آزمایش را تغییر دهند. لایه‌های خرابی را از هم جدا کنید: لینک محلی و دروازه؛ DNS؛ مسیر و دسترسی به مقصد؛ TLS؛ احراز هویت پروکسی؛ و رفتار برنامه. شکست ping به‌تنهایی چیز زیادی ثابت نمی‌کند. پایان مهلت انتظار نیز به‌تنهایی دخالت GFW را مشخص نمی‌کند؛ خرابی سرور، سیاست محلی، مسیریابی و اتلاف عادی بسته‌ها می‌توانند نشانه‌های مشابهی داشته باشند. حتی سرور HTTP پاسخ‌گو ممکن است به دلایل نامرتبط، حساب یا درخواست API را رد کند. ## 2. انتخاب ساده‌ترین مسیر مفید ابتدا از مسیر موجود، مورد اعتماد و فعال استفاده کنید. در غیر این صورت، بر پایهٔ محدودیت‌های مشاهده‌شده انتخاب کنید، نه رتبه‌بندی ثابت پروتکل‌ها: - **دسترسی مرورگر بدون VPS:** از نسخهٔ رسمی Tor Browser و روش فعلی اتصال یا استفاده از پل در آن بهره بگیرید. مستندات Tor دریافت پل و اتصال از مناطق تحت سانسور را توضیح می‌دهند. اتصال مرورگر به‌طور خودکار ابزارهای ترمینال را از پروکسی عبور نمی‌دهد. [مستندات عبور از سانسور Tor][ref-3] را ببینید. - **پروکسی روی سرور خودتان:** یک جفت کلاینت و سرور با نگهداری فعال و پشتیبانی از هر دو دستگاه انتخاب کنید. NaiveProxy یکی از گزینه‌های مبتنی بر HTTPS است و راهنمای رسمی آن، تنظیم کلاینت و سرور را شرح می‌دهد. به‌جای ساخت اسکریپت تقلید TLS، از پیاده‌سازی و تنظیمات واقعی آن استفاده کنید. [پروژهٔ اصلی NaiveProxy][ref-4] را ببینید. - **مسیری با امکان استفاده از UDP:** Hysteria 2 یکی از گزینه‌هاست. پیش‌نیازهای سرور و دستورهای کلاینت سازگار را دنبال کنید؛ دسترسی پروتکل انتقال انتخاب‌شده را در هر دو دیوار آتش ابری و میزبان بررسی کنید. اگر این مسیر کار نکرد، یک جایگزین مبتنی بر TCP را که جداگانه آزمایش شده نگه دارید. [راه‌اندازی سرور Hysteria][ref-5] را ببینید. - **پروفایل موجود Shadowsocks، VLESS/REALITY، Trojan یا گزینه‌ای دیگر:** پیاده‌سازی و نسخهٔ نصب‌شده را بررسی کنید، سپس به طرح پیکربندی رسمیِ همان نسخه مراجعه کنید. هرگز فیلدهای sing-box، Xray یا نسخه‌های مختلف را با هم ترکیب نکنید. نام پروتکل‌ها، قالب‌های پیکربندی قابل جایگزینی با یکدیگر نیستند. - **سرویس مدیریت‌شدهٔ عبور از سانسور:** Geph، Psiphon، Outline و ابزارهای دیگرِ یادداشت‌های منبع، گزینه‌هایی برای بررسی‌اند. پیش از انتخاب، پشتیبانی فعلی از پلتفرم، توزیع رسمی، الزامات اعتماد و دسترسی از شبکهٔ محلی را بررسی کنید. توصیه‌ای قدیمی، دلیل کارکرد امروز آن نیست. - **ظاهراً فقط DNS مشکل دارد:** پیش از تغییر resolver، نتایج را با دقت مقایسه کنید. DNS رمزگذاری‌شده ممکن است اختلال DNS را برطرف کند، اما به‌تنهایی مسدودسازی IP یا همهٔ مسدودسازی‌های لایهٔ TLS را رفع نمی‌کند. - **هیچ اتصال قابل استفاده‌ای به شبکهٔ بالادست وجود ندارد:** به برنامهٔ آفلاینِ بخش بعد بروید. VPN نمی‌تواند جایی که هیچ مسیری به اینترنت وجود ندارد، مسیر ایجاد کند. یک مسیر اصلی و، در صورت امکان، یک مسیر جایگزینِ جداگانه‌آزمایش‌شده انتخاب کنید. دو پروفایل که به یک IP مسدودشده اشاره دارند، مسیرهای بازیابی مستقل نیستند. ## ارائه‌دهندگان و مرورگرهای دارای VPN داخلی مستندات ارائه‌دهندگان در 2026-10-24 بررسی شد. این‌ها ارائه‌دهندگان شناخته‌شده‌ای هستند که ارزش بررسی دارند؛ این فهرست تضمین اعتمادپذیری یا دسترسی از پشت GFW نیست. توضیحات زیر از مستندات رسمی محصولات گرفته شده‌اند و ممیزی امنیتی مستقل یا آزمایش میدانی محسوب نمی‌شوند. پیش از انتخاب، سیاست حریم خصوصی، دامنهٔ ممیزی اخیر، پشتیبانی از پلتفرم و نتایج اتصال در شبکهٔ خود را بررسی کنید. پیش از آزمایش، اشتراک بلندمدت نخرید. ### Cloudflare: 1.1.1.1 و WARP Cloudflare ارائه‌دهندهٔ شناخته‌شدهٔ زیرساخت است. کلاینت مصرف‌کنندهٔ WARP حالت‌های متفاوتی دارد: حالت DNS-only فقط پرس‌وجوهای DNS را رمزگذاری می‌کند و ترافیک برنامه‌ها را تونل نمی‌کند؛ حالت Traffic and DNS ترافیک دستگاه را تونل می‌کند؛ و حالت پروکسی محلیِ دسکتاپ، برنامه‌هایی را پوشش می‌دهد که صریحاً برای استفاده از آن تنظیم شده‌اند. حالت را انتخاب و بررسی کنید؛ فرض نکنید فعال کردن 1.1.1.1 برای همهٔ برنامه‌ها تونل ایجاد می‌کند. WARP گزینه‌ای برای آزمایش سریع اتصال است، اما Cloudflare می‌گوید ناشناس ماندن را فراهم نمی‌کند و اجازهٔ انتخاب کشور دیگری به‌عنوان موقعیت ظاهری کاربر را نمی‌دهد. WARP+ سرویس پولی است، نه مدرکی برای مقاومت بیشتر در برابر سانسور. محصولات CDN، Workers، Tunnel و Zero Trust متعلق به Cloudflare، سرویس‌های جداگانه‌اند؛ حساب میزبانی وب را با VPN مصرف‌کنندهٔ آمادهٔ استفاده اشتباه نگیرید. [حالت‌های Cloudflare WARP][ref-6] را ببینید. ### Proton VPN اگر سرویس مدیریت‌شده‌ای با قابلیت‌های صریح عبور از سانسور می‌خواهید، Proton VPN گزینهٔ مفیدی برای بررسی است. Proton پروتکل مبهم‌سازی‌شدهٔ Stealth را مستند کرده و آن را در همهٔ طرح‌ها، از جمله طرح رایگان، ارائه می‌کند. دستورهای فعلی برنامه و پلتفرم را بررسی کنید: یک پروفایل عمومی VPN لزوماً معادل حالت Stealth در برنامه نیست. در صورت مناسب بودن، با طرح رایگان شروع کنید و پیش از پرداخت، عامل مورد نیاز، مرورگر و اتصال‌های طولانی را آزمایش کنید. [راهنمای Stealth پروتون][ref-7] را ببینید. ### Mullvad VPN Mullvad ارائه‌دهندهٔ شناخته‌شدهٔ دیگری با تمرکز بر حریم خصوصی است. راهنمای دسکتاپ آن Windows، macOS و Linux را پوشش می‌دهد و تنظیمات ضدسانسور دارد. راهنما پیشنهاد می‌کند روش‌های مبهم‌سازی موجود، از جمله UDP-over-TCP در شبکه‌های مسدودکنندهٔ UDP، آزمایش شوند. گزینه‌های نسخهٔ نصب‌شده را بررسی و اثرشان را اندازه‌گیری کنید؛ مبهم‌سازی می‌تواند کارایی را کاهش دهد. برای ایجاد تونل شبکه از برنامهٔ VPN استفاده کنید؛ نصب مرورگر متمرکز بر حریم خصوصی به‌تنهایی تونل ایجاد نمی‌کند. [راهنمای برنامهٔ Mullvad][ref-8] را ببینید. ### Opera: VPN رایگان مرورگر و VPN Pro پولی Opera در مرورگر خود VPN رایگان ارائه می‌کند که طبق صفحهٔ محصول، به حساب کاربری نیاز ندارد و سقف پهنای باند ندارد. محصول رایگان، فعالیت داخل Opera را پوشش می‌دهد. برای عامل خط فرمان جداگانه، IDE یا همهٔ برنامه‌های دیگر تونل فراهم نمی‌کند. هنگام آماده‌سازی اتصال گسترده‌تر، می‌تواند برای خواندن مستندات و دریافت نصب‌کننده‌های رسمی مفید باشد. Opera می‌گوید محصول پولی VPN Pro پوشش را به کل دستگاه گسترش می‌دهد. پیش از خرید، پشتیبانی از سیستم‌عامل و محصول انتخاب‌شده را بررسی کنید. Opera را گزینه‌ای برای راحتی کار در مرورگر بدانید که باید با نیازهای حریم خصوصی کاربر سنجیده شود؛ آشنایی با نام یک مرورگر، تضمین مناسب بودن آن برای کار حساس نیست. [مقایسه و پرسش‌های متداول VPN در Opera][ref-9] را ببینید. ### Brave Firewall + VPN Brave یک VPN پولیِ یکپارچه با مرورگر ارائه می‌کند که برنامه‌های خارج از Brave را نیز پوشش می‌دهد. صفحهٔ فعلی محصول Android، Windows، iOS و macOS را فهرست می‌کند و پشتیبانی Linux را «به‌زودی» توصیف می‌کند. بنابراین نصب Brave روی Linux ثابت نمی‌کند که VPN آن در آنجا در دسترس است. هنگام راه‌اندازی، پشتیبانی از پلتفرم را دوباره بررسی کنید. این گزینه برای کسانی است که در سیستم‌های پشتیبانی‌شده، VPN سراسری دستگاه با مدیریت از داخل مرورگر می‌خواهند. قابلیت‌های حریم خصوصی مرورگر به‌تنهایی VPN پولی را فعال نمی‌کنند و صفحهٔ محصول نیز ثابت نمی‌کند که سرویس از یک اتصال خاصِ تحت GFW کار می‌کند. [Brave Firewall + VPN][ref-10] را ببینید. ### روش انتخاب ارائه‌دهنده توسط عامل‌ها - برای عامل‌های ترمینال و IDEها، تونل کل دستگاه یا پروکسی محلیِ پشتیبانی‌شده انتخاب کنید. پوشش محدود به مرورگر، اتصال فرایندهای دیگر را درست نمی‌کند. - اگر بودجه محدود است، پیش از خرید گزینهٔ رایگان مناسب را آزمایش کنید. قیمت فعلی، شرایط بازپرداخت، محدودیت قابلیت‌ها و پشتیبانی سیستم‌عامل را در سایت رسمی دوباره بررسی کنید. - قابلیت مستندشده توسط فروشنده را از ادعای حریم خصوصیِ بررسی‌شده به‌طور مستقل و از آزمایش موفق اتصال در شبکهٔ محلی تفکیک کنید. - نصب، ورود، اتصال، ترافیک مفید و اتصال مجدد را آزمایش کنید. قابل دسترس بودن وب‌سایت تبلیغاتی، کارکرد سرویس را ثابت نمی‌کند. - نرم‌افزار را از فروشندهٔ رسمی یا کانال توزیع تأییدشده بگیرید. اطلاعات حساب و اشتراک را در یادداشت‌های عمومی قرار ندهید. - جایگزینی با زیرساخت یا وابستگی‌های انتقال متفاوت نگه دارید. هیچ ارائه‌دهنده‌ای را برای همیشه مصون از GFW توصیف نکنید. ## 3. پیاده‌سازی تنظیمات کلاینت و سرور برای عاملی که مسیری مبتنی بر VPS راه‌اندازی می‌کند: 1. نسخه‌های کلاینت و سرور را ثبت کنید. فایل‌های اجرایی را از کانال‌های رسمی بگیرید و اگر امضا یا checksum رسمی ارائه شده، آن‌ها را بررسی کنید. مستندات سازگار را ذخیره کنید. اگر دریافت مسدود است، از مسیر مورد اعتمادِ موجود یا انتقال آفلاینِ مورد اعتماد استفاده کنید؛ خروجی نصب‌کنندهٔ ناشناس را مستقیماً به پوستهٔ دارای دسترسی ویژه ندهید. 2. درگاه‌ها و سرویس‌های موجود را بررسی کنید. وب‌سایت موجود را جایگزین نکنید و فرض نکنید TCP/443 یا UDP/443 آزاد است. هم قوانین دیوار آتش ابری و هم دیوار آتش میزبان را بررسی کنید. 3. اطلاعات احراز هویت را به‌صورت محلی در فایل‌های خصوصی تولید کنید. با مستندات سازگار با نسخهٔ نصب‌شده، حداقل تنظیمات سرور را بسازید. فقط شنونده، احراز هویت، گواهی‌ها یا کلیدهای ویژهٔ پروتکل و رفتار خروجیِ لازم برای راه‌حل انتخابی را پیکربندی کنید. 4. تنظیمات متناظر کلاینت را بسازید و ابتدا از شنوندهٔ HTTP/SOCKS روی loopback استفاده کنید. ورودی mixed در sing-box هم HTTP و هم SOCKS را پشتیبانی می‌کند؛ با این حال، شنونده هنوز به مسیر خروجیِ درست نیاز دارد. [ورودی mixed در sing-box][ref-11] را ببینید. 5. پیش از فعال‌سازی، ابزار اعتبارسنجی تنظیماتِ مستندشده برای همان پیاده‌سازی را اجرا کنید. دستور دقیق را از راهنمای فایل اجرایی نصب‌شده یا راهنمای سازگار با آن بگیرید؛ دستورهای یک محصول را برای محصول دیگر حدس نزنید. 6. در صورت امکان، با یک فرایند موقت یا سرویس آزمایشی جداگانه شروع کنید. خطاهای محدود و پاک‌سازی‌شده از اطلاعات حساس را بررسی کنید. احراز هویت کلاینت به سرور و یک درخواست مفید از ابتدا تا انتها را آزمایش کنید. 7. فقط پس از موفقیت تنظیمات موقت، راه‌اندازی پایدار سرویس را اضافه کنید. نام واقعی سرویس، مسیر تنظیمات، دستور دیدن گزارش‌ها و دستورهای شروع و توقف را مستند کنید. 8. پس از راه‌اندازی مجدد سرویس آزمایش کنید. اگر کاربر به مسیریابی کل دستگاه نیاز دارد، TUN، مسیریابی DNS، IPv6، استثناهای شبکهٔ محلی و مسیر دسترسی به خود سرور تونل را جداگانه تنظیم و آزمایش کنید. از مسیریابی تونل به داخل خودش جلوگیری کنید. تغییرات دیوار آتش ابری، رکوردهای DNS، صدور گواهی و مسیریابی محلی، اجزای جداگانه‌اند. فعال بودن یک فرایند، دلیل کارکرد همهٔ آن‌ها نیست. ## 4. بررسی مسیر و برنامهٔ واقعی این مثال‌ها فرض می‌کنند **شنوندهٔ SOCKS5 روی درگاه محلی 2080** از قبل تنظیم شده است. شمارهٔ درگاه را با مقدار واقعی جایگزین کنید. `example.com` یک آزمایش ابتدایی HTTPS است؛ مقصدی را که کاربر واقعاً نیاز دارد نیز آزمایش کنید. آزمایش مستقیم را فقط زمانی انجام دهید که دسترسی مستقیم قابل قبول باشد. ```bash # Baseline: bypass explicit HTTP/SOCKS proxy settings. # This does NOT bypass an active VPN, TUN interface, or transparent # proxy. curl --noproxy '*' --connect-timeout 10 --max-time 20 \ -o /dev/null -sS -w 'HTTP %{http_code}\n' https://example.com/ # Explicit proxy test; socks5h asks the proxy to resolve the target # name. curl --noproxy '' --proxy socks5h://127.0.0.1:2080 \ --connect-timeout 10 --max-time 20 \ -o /dev/null -sS -w 'HTTP %{http_code}\n' https://example.com/ ``` `socks5h` به حل نام مقصد برای همین درخواست مربوط است. این گزینه ثابت نمی‌کند که کل دستگاه هیچ نشت DNS ندارد. ممکن است کلاینت هنگام شروع هنوز نیاز داشته باشد نام میزبان سرور پروکسی را حل کند. یک درخواست کوچک، انتقال طولانی، اتصال مجدد و کار واقعی مرورگر یا عامل را آزمایش کنید. در صورت ارتباط با مسئله، رفتار IPv4 و IPv6 را بررسی کنید. از موفقیت یک درخواست `curl` نتیجه نگیرید که همهٔ برنامه‌ها کار می‌کنند. برای کلاینتی با **شنوندهٔ HTTP یا mixed**، می‌توان با یک فرایند فرزند موقت، متغیرهای محیطی رایج پروکسی را آزمایش کرد: ```bash # Replace command-to-test with an installed command and its normal # arguments. # Port 2080 must support HTTP CONNECT for this example. env HTTPS_PROXY=http://127.0.0.1:2080 \ HTTP_PROXY=http://127.0.0.1:2080 \ https_proxy=http://127.0.0.1:2080 \ http_proxy=http://127.0.0.1:2080 \ NO_PROXY=localhost,127.0.0.1,::1 \ no_proxy=localhost,127.0.0.1,::1 \ command-to-test ``` رفتار شبکه‌ای عامل‌ها و IDEها با نسخه و فرایند فرق می‌کند. پشتیبانی مستندشدهٔ محصول نصب‌شده از پروکسی را بررسی کنید. افزونهٔ IDE، ترمینال داخلی، پنجرهٔ ورود، فرایند به‌روزرسانی و میزبان راه‌دور افزونه ممکن است مسیرهای متفاوتی داشته باشند. فرض نکنید رابط گرافیکیِ از قبل باز، متغیرهای جدید پوسته را به ارث می‌برد. با مستثنا کردن loopback، دسترسی به اجراکننده‌های مدل محلی را حفظ کنید. احراز هویت و یک درخواست واقعی را بدون ثبت توکن‌ها آزمایش کنید. موفقیت یعنی برنامهٔ مورد نظر کاربر از مسیر مورد نظر کار کند، سرویس‌های محلی همچنان کار کنند، رفتار اتصال مجدد مشخص باشد و کاربر روش بازیابی در اختیار داشته باشد. بررسی IP بیرونی به‌تنهایی کافی نیست. ## 5. عیب‌یابی بدون از بین بردن وضعیت فعال - **اتصال محلی رد می‌شود:** آدرس شنونده، درگاه، فرایند و خطاهای سرویس را بررسی کنید. - **شنونده فعال است، اما اتصال بالادست به پایان مهلت انتظار می‌رسد:** نقطهٔ پایانی، هر دو دیوار آتش، سلامت سرور و دسترسی انتقال را بررسی کنید. در صورت امکان، با شبکهٔ مجاز دیگر یا مسیر جایگزین مقایسه کنید. - **خطای TLS:** زمان، مخزن گواهی‌های مورد اعتماد، نام میزبان، انقضای گواهی و تنظیمات ویژهٔ پروتکل را بررسی کنید. برای موفق نشان دادن آزمایش، اعتبارسنجی را خاموش نکنید. - **خطای احراز هویت پروکسی:** اطلاعات احراز هویت کلاینت و سرور را به‌صورت خصوصی مقایسه کنید و پروتکل و نسخهٔ انتخابی را بررسی کنید. - **curl کار می‌کند، اما عامل نه:** پشتیبانی برنامه از پروکسی، محیط به‌ارث‌رسیده، استثناها، ابزارهای کمکی ورود و به‌روزرسانی و نام واقعی میزبانِ ناموفق را بررسی کنید. محدودیت حساب یا خطای سرویس لزوماً ناشی از سانسور نیست. - **درخواست کوتاه کار می‌کند، اما جریان طولانی قطع می‌شود:** اتلاف بسته، نشانه‌های مشکل MTU، رفتار انتقال و منابع سرور را اندازه‌گیری کنید. زمان‌بندی را ثبت کنید؛ بدون مدرک، علت را کاوش فعال اعلام نکنید. - **مسیر UDP کار نمی‌کند:** مسیر جایگزین مبتنی بر TCP را که جداگانه تنظیم شده آزمایش کنید. تغییر تنها شمارهٔ درگاه ثابت نمی‌کند که علت، فیلتر شدن UDP بوده است. - **شبکه پس از تغییرات TUN یا DNS قطع می‌شود:** با روش بازگردانی آماده‌شده، مسیرها، تنظیمات DNS و وضعیت سرویس ذخیره‌شده را بازیابی کنید. دسترسی مدیریت راه‌دور را حفظ کنید. هر بار فقط یک متغیر مرتبط را تغییر دهید. گزارش کوتاه و تاریخ‌داری از شواهد و نتایج نگه دارید و شناسه‌های حساس را از آن حذف کنید. ## 6. آمادگی آفلاین و مسیر جایگزین پیش از قطع دسترسی، یک مجموعهٔ خصوصی برای بازیابی آماده داشته باشید: - نصب‌کننده‌های بررسی‌شده برای سیستم‌عامل و معماری مقصد، وابستگی‌های لازم، راهنماهای سازگار و اطلاعات بررسی یکپارچگی فایل‌ها. - تنظیمات سالم و آزموده‌شده، دستورهای بازیابی و اطلاعات احراز هویت با نگهداری امن، خارج از یادداشت‌های عمومی. - مدل محلی، اجراکنندهٔ سازگار و گردش کار دستیارِ آزمایش‌شده‌ای که بدون ورود ابری یا دانلود شروع شود. - دانش ذخیره‌شدهٔ لازم برای تعمیر شبکه و راهنمای تحویل قابل فهم برای انسانی که بدون عامل کار می‌کند. - نقطهٔ پایانی یا روش انتقال جایگزین با وابستگی‌های خرابی متفاوت که از پیش آزمایش شده باشد. برای پیام‌رسانی محلی هنگام قطعی، Briar همگام‌سازی با Bluetooth، Wi-Fi یا کارت حافظه و استفاده از Tor هنگام دسترسی به اینترنت را مستند کرده است. این قابلیت می‌تواند ارتباط نزدیک یا با تأخیر را ممکن کند، اما دسترسی به اینترنت جهانی ایجاد نمی‌کند. [معماری Briar][ref-12] را ببینید. ## 7. اصلاح ادعاهای گمراه‌کننده در یادداشت‌های قدیمی ادعاهایی مانند «مسدودنشدنی بودن» یک روش انتقال، غیرقابل تشخیص بودن کامل یا ناشناس ماندن مطلق را تکرار نکنید. رمزگذاری، مقاومت در برابر سانسور، ناشناس ماندن و امنیت دستگاه‌های پایانی، ویژگی‌های جداگانه‌اند. فرض نکنید همهٔ تونل‌های رمزگذاری‌شده از HTTPS تقلید می‌کنند، همهٔ پل‌ها آدرس خانگی دارند یا هر دست‌دهی TLS اطلاعات یکسانی آشکار می‌کند. ادعاهای مربوط به نسل‌های Geph، جزئیات درونی sosistab، کارایی محیط اجرا و تضمین‌های رمزنگاری را تا بررسی در کد و مستندات نسخهٔ مربوط، تأییدنشده بدانید. میزبانی ابریِ اشتراکی خودبه‌خود domain fronting نیست. کار کردن یک نشانی دانلود در فضای ذخیره‌سازی اشتراکی فقط همان مسیر دریافت را نشان می‌دهد؛ نه وجود پروکسی عمومی را ثابت می‌کند و نه مجوز CDN برای عبور دادن ترافیک دلخواه را. پیش از طراحی بر پایهٔ fronting یا تونل CDN، پشتیبانی واقعی ارائه‌دهنده و پروتکل را بررسی کنید. پل ممکن است میزان آشکار شدن زیرساخت و دسترس‌پذیری را تغییر دهد، اما تضمین نمی‌کند که خروجی یا خود پل هرگز مسدود نشوند. مشاهده‌های مفید یادداشت‌های قدیمی را حفظ کنید، بدون اینکه حدس‌ها را به واقعیت عملیاتی تبدیل کنید. ## 8. اطلاعات لازم برای تحویل پس از راه‌اندازی یک گزارش عملیاتی کوتاه و خصوصی با موارد زیر باقی بگذارید: - تاریخ، سیستم‌عامل، معماری، نسخه‌های دقیق نرم‌افزار و منابع رسمی استفاده‌شده. - شرح مشکل، شواهد جمع‌آوری‌شده و مواردی که هنوز نامشخص‌اند. - روش انتقال انتخاب‌شده، شنوندهٔ محلی، برنامه‌های تحت تأثیر و رفتار مورد انتظار DNS و IPv6. - مسیرهای واقعی تنظیمات و نسخه‌های پشتیبان، بدون درج اطلاعات محرمانه در مستندات عمومی. - دستورهای دقیق شروع، توقف، وضعیت، گزارش‌ها، اعتبارسنجی و بازگردانی برای همین نصب. - نتایج آزمایش برنامهٔ واقعی، ترافیک طولانی و راه‌اندازی مجدد سرویس. - روش جایگزین و مراحل آزمایش‌نشده، از جمله راه‌اندازی مجدد دستگاه اگر انجام نشده است. پیاده‌سازی و بررسیِ مجازشده را انجام دهید؛ به ارائهٔ فهرستی از محصولات بسنده نکنید. اگر مانعی وجود دارد، پیش‌نیاز دقیقِ ناموجود را مشخص کنید و اقدام بعدیِ روشنی باقی بگذارید. صرف تولید تنظیمات را به معنای استقرار موفق اعلام نکنید. ## منابع [ref-1]: ../bypass.gfw.md [ref-2]: ../doors.md [ref-3]: https://support.torproject.org/tor-browser/circumvention/ [ref-4]: https://github.com/klzgrad/naiveproxy [ref-5]: https://v2.hysteria.network/docs/getting-started/Server/ [ref-6]: https://developers.cloudflare.com/warp-client/warp-modes/ [ref-7]: https://protonvpn.com/blog/stealth-vpn-protocol [ref-8]: https://mullvad.net/en/help/using-mullvad-vpn-app [ref-9]: https://www.opera.com/features/free-vpn [ref-10]: https://brave.com/firewall-vpn/ [ref-11]: https://sing-box.sagernet.org/configuration/inbound/mixed/ [ref-12]: https://briarproject.org/how-it-works/ [English](readme.md) [Русский](readme.ru.md) [فارسی](readme.fa.md) [简体中文](readme.zh.md)