پیش از موج اخیر قطع و اختلال اینترنت در یک سال گذشته، بسیاری از روش‌های شناخته‌شده برای عبور از سانسور، مانند dnstt و PingTunnel یا Champa، برای گروهی محدود از کاربران حرفه‌ای، توسعه‌دهندگان و علاقه‌مندان شبکه آشنا بودند. این ابزارها در ادبیات فنی جهانی، نمونه‌هایی پیشرو و خلاقانه در حوزه censorship circumvention به شمار می‌رفتند، اما در عمل برای کاربران داخل ایران اغلب کند، پیچیده، ناپایدار و غیرقابل اتکا بودند. تجربه کاربران ایرانی نشان آنچه از بیرون به‌عنوان راه‌حل فنی جذاب و پیشرفته دیده می‌شود، لزوما در برابر معماری سانسور جمهوری اسلامی و محدویت‌های شبکه ملی اطلاعات، کارآمدی لازم را ندارد. در همین فاصله، برخی توسعه‌دهندگان ایرانی به جای تکرار همان الگوها، مسیرهای تازه‌ای ساختند که با شرایط ایران سازگارتر بود؛ روش‌هایی که با مدل‌های رایج قبلی تفاوت جدی دارند و نشان می‌دهند خلاقیت فنی در ایران فقط مصرف‌کننده راه‌حل‌های خارجی نیست، بلکه در شرایط فشار می‌تواند مدل‌های تازه‌ای برای زنده نگه داشتن اتصال بسازد.

در هفته‌های گذشته چند پروژه تازه یا پررنگ شده در جامعه فنی فارسی‌زبان توجه جلب کرده‌اند. نقطه مشترک آنها این است که به جای اتکا به مسیرهای کلاسیک VPN، تلاش می‌کنند ترافیک کاربر را از مسیرهایی عبور دهند که در شرایط عادی برای سرویس‌های پرکاربرد و عمومی استفاده می‌شوند؛ از Google Apps Script و Google Drive گرفته تا سرورهای DNS عمومی. این روش‌ها لزوما برای استفاده عمومی، پایدار یا کم خطر طراحی نشده‌اند، اما از نظر فنی نشان می‌دهند که چگونه کاربران و توسعه‌دهندگان ایرانی در برابر معماری سانسور جمهوری اسلامی و پیاده‌سازی فناوری فیلترینگ لیست سفید، به سراغ مسیرهای غیرمستقیم، چندلایه و خلاقانه می‌روند.

عبور از مسیر گوگل؛ تونل‌سازی با Google Apps Script

یکی از این پروژه‌ها GooseRelayVPN است.

گیت: https://github.com/Kianmhz/GooseRelayVPN

کاری از: کیان حداد، واترلو، آنتاریو، کانادا

این ابزار خود را به عنوان یک VPN مبتنی بر SOCKS5 معرفی می‌کند که ترافیک خام TCP را از مسیر Google Apps Script به یک سرور خروجی شخصی منتقل می‌کند. در توضیح پروژه آمده است که کلاینت کاربر فقط یک اتصال TLS به IP گوگل با SNI برابر با www.google.com برقرار می‌کند و داده‌ها پیش از ارسال با AES 256 GCM رمزنگاری می‌شوند؛ یعنی Google Apps Script صرفا نقش یک رله را دارد و متن خام داده‌ها را نمی‌بیند.

در معماری GooseRelayVPN، مرورگر یا اپلیکیشن کاربر به یک پراکسی محلی SOCKS5 وصل می‌شود. سپس ابزار، داده‌ها را در قالب فریم‌های رمزنگاری شده بسته بندی می‌کند و از مسیر HTTPS به یک وب اپ Google Apps Script می‌فرستد. آن اسکریپت داده‌ها را به سرور خروجی کاربر منتقل می‌کند و سرور خروجی، مقصد واقعی را باز می‌کند. به بیان ساده، برای ناظر شبکه مسیر ظاهری شبیه ارتباط با گوگل است، اما مقصد نهایی از طریق سرور خروجی کاربر ساخته می‌شود. خود پروژه تاکید می‌کند که برای این مدل، یک VPS کوچک لازم است و برخلاف پراکسی‌های صرفا مبتنی بر Apps Script، این ابزار برای انتقال TCP خام طراحی شده است.

مزیت چنین مدلی این است که می‌تواند برای انواع ترافیک TCP استفاده شود، نه فقط وب‌گردی ساده. اما محدودیت آن نیز روشن است: کاربر باید سرور خروجی داشته باشد، کلید تونل را امن نگه دارد و با سقف‌های مصرف Google Apps Script کنار بیاید. در مستندات پروژه آمده که هر Deployment ID در Google Apps Script حدود ۲۰ هزار اجرا در روز دارد و این محدودیت می‌تواند در استفاده گسترده، به گلوگاه تبدیل شود.

گوگل درایو به‌عنوان صندوق پستی ترافیک

پروژه دوم Skirk است.

گیت:‌ https://github.com/ShahabSL/Skirk

کاری از: شهاب لواسانی، هیوستون، تگزاس، ایالات متحده

پروژه Skirk به جای Google Apps Script، از گوگل درایو به عنوان مسیر واسط استفاده می‌کند. این ابزار یک پراکسی محلی SOCKS5، یک پراکسی HTTP اختیاری یا در برخی محیط‌ها یک رابط VPN برای اندروید ارائه می‌دهد و فریم‌های رمزنگاری شده TCP را از طریق یک پوشه گوگل درایو میان کلاینت و ماشین خروجی جابه‌جا می‌کند. در توضیح پروژه آمده که Skirk برای استفاده قانونی، حساب‌های متعلق به خود کاربر و شبکه‌های مجاز طراحی شده و وابسته یا مورد تایید گوگل و دیگر ارائه‌دهندگان سرویس نیست.

تفاوت مهم Skirk با GooseRelayVPN در مسیر حمل داده است. در Skirk، گوگل درایو مانند یک «صندوق پستی» عمل می‌کند. کلاینت بسته‌های رمزنگاری شده را در مسیر Drive بارگذاری می‌کند، ماشین خروجی آنها را می‌خواند و پاسخ را دوباره در همان مسیر برمی‌گرداند. همین مدل باعث می‌شود تاخیر اولیه بیشتر به زمان دیده شدن، بارگذاری، فهرست شدن، دانلود و پاک سازی فایل‌ها در گوگل درایو وابسته باشد، نه به یک پرس وجوی DNS یا یک اتصال مستقیم کلاسیک. خود مستندات Skirk نیز تاکید می‌کند که عملکرد آن به شرایط مسیر، سهمیه‌ها و رفتار Google Drive وابسته است و نتیجه بنچمارک‌ها تضمین سرعت در همه محیط‌ها نیست.

بازگشت به DNS؛ مسیر کم‌ظرفیت اما مقاوم

پروژه سوم MasterDnsVPN است.

گیت: https://github.com/masterking32/MasterDnsVPN

کاری از: امین محمودی، آمستردام، هلند

این پروژه خود را یک ابزار پژوهشی برای حمل ترافیک TCP از طریق پرسش و پاسخ‌های DNS معرفی می‌کند و می‌گوید از نظر هدف کلی به پروژه‌هایی مانند dnstt یا SlipStream شباهت دارد، اما در ساختار و پیاده سازی مسیر متفاوتی را دنبال می‌کند. مستندات پروژه می‌گوید هدف آن سازگاری با رفتارهای مختلف Resolver و حفظ پایداری در شرایط سخت شبکه است.

اهمیت MasterDnsVPN در این است که به یکی از قدیمی‌ترین ایده‌های عبور از فیلترینگ برمی‌گردد: استفاده از DNS به عنوان مسیر حامل داده. در بسیاری از شبکه‌ها، حتی وقتی دسترسی به وب، پیام‌رسان‌ها یا VPNها محدود می‌شود، DNS همچنان برای کارکرد پایه شبکه باز می‌ماند یا دست کم دیرتر و با احتیاط بیشتری بسته می‌شود. DNS tunneling از همین شکاف استفاده می‌کند و داده‌ها را در قالب پرسش‌ها و پاسخ‌های DNS جابه‌جا می‌کند. MasterDnsVPN می‌گوید برای این کار از پروتکل سفارشی، ARQ کم سربار، توزیع بار میان Resolverها و طراحی مقاوم در برابر packet loss استفاده می‌کند.

اما DNS tunneling هم راه حل جادویی نیست. ظرفیت DNS محدود است، بسیاری از شبکه‌ها روی DNS نظارت جدی دارند، الگوهای غیرعادی قابل تشخیص هستند و عملکرد چنین ابزارهایی به کیفیت Resolver، سیاست شبکه و میزان سختگیری فیلترینگ بستگی دارد. در بهترین حالت، این روش‌ها می‌توانند برای اتصال اضطراری، پیام رسانی سبک، دسترسی محدود یا باز نگه داشتن یک مسیر کم ظرفیت مفید باشند؛ نه لزوما جایگزینی کامل برای اینترنت آزاد، پرسرعت و پایدار.

خلاقیت فنی، بدون بی‌خطری امنیتی نیست

اهمیت این سه پروژه فقط در کاربرد احتمالی آنها نیست. نکته مهم‌تر این است که هرکدام بخشی از واکنش جامعه فنی ایران به یک وضعیت غیرعادی را نشان می‌دهند. GooseRelayVPN از اعتماد ظاهری شبکه به سرویس‌های گوگل و Google Apps Script استفاده می‌کند. Skirk تلاش می‌کند گوگل درایو را به مسیر حمل داده تبدیل کند. MasterDnsVPN به DNS به عنوان یکی از لایه‌های پایه شبکه برمی‌گردد. هر سه پروژه، با وجود تفاوت‌های فنی، یک پیام مشترک دارند: هرچه حکومت مسیرهای عادی اتصال را بیشتر ببندد، کاربران و توسعه‌دهندگان به سمت مسیرهای پیچیده‌تر، غیرمستقیم‌تر و خلاقانه‌تر می‌روند.

این روند البته فقط داستان امید نیست. هر ابزار تازه‌ای که در شرایط بحران اینترنتی منتشر می‌شود، ممکن است برای کاربران غیرحرفه‌ای خطرهای امنیتی هم ایجاد کند. اجرای ابزارهای ناشناخته، وارد کردن کلیدها و توکن‌ها، استفاده از حساب‌های شخصی گوگل، اتصال به VPSهای ناشناس، یا دریافت فایل‌های باینری از منابع غیرقابل اعتماد می‌تواند خود به نقطه آسیب پذیری تبدیل شود. به همین دلیل، چنین پروژه‌هایی باید با احتیاط، بررسی کد، استفاده از منابع رسمی و درک محدودیت‌های امنیتی ارزیابی شوند.

با این حال، نمی‌توان واقعیت اصلی را نادیده گرفت. قطع و اختلال اینترنت در ایران، برخلاف تصور طراحان آن، فقط مسیر ارتباط را نمی‌بندد؛ هم زمان یک میدان بزرگ آزمایش فنی ایجاد می‌کند. در این میدان، کاربرانی که پیش تر مصرف کننده ساده ابزارهای آماده بودند، به تدریج به سمت فهم شبکه، آزمون مسیرهای جایگزین و مشارکت در توسعه ابزارهای مقاوم‌تر می‌روند. این همان جایی است که سانسور، ناخواسته، بخشی از جامعه را فنی‌تر، حساس‌تر و خلاق‌تر می‌کند.

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