آموزش tunnel mode

[ahoora0iman-star]

لطفا یک آموزش مرحله به مرحله برای راه اندازی tunnel mode قرار دهید .

[therealaleph]

درخواست خوبیه. در حال حاضر مستندات فنی ‫tunnel mode‬ در ‫tunnel-node/README.md‬ هست، ولی یه راهنمای ‫step-by-step‬ فارسی برای کاربر عادی نداریم. اضافه می‌کنم در یکی از docs update های بعدی.

تا اون موقع، خلاصهٔ مراحل:

پیش‌نیازها:

• یک ‫VPS‬ خارج از ایران (هر جای دنیا که ‫Apps Script‬ بهش دسترسی داشته باشه — Turkey / Germany / Singapore / ... )
• یک حساب گوگل با ‫Apps Script‬ فعال (همون که الان برای ‫apps_script mode‬ استفاده می‌کنید)

مراحل:

1. روی ‫VPS‬ خود ‫tunnel-node‬ رو اجرا کنید:

   git clone https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
   cd MasterHttpRelayVPN-RUST/tunnel-node
   docker build -t mhrv-tunnel-node .
   docker run -d --name mhrv-tun -p 8080:8080 mhrv-tunnel-node

2. در ‫script.google.com‬ یک اسکریپت جدید بسازید:

   • محتوای ‫assets/apps_script/CodeFull.gs‬ از repo ما رو کپی کنید
   • در بالای فایل ‫const TUNNEL_NODE_URL = "http://YOUR_VPS_IP:8080"‬ رو به ‫IP‬ ‫VPS‬ خودتون تغییر بدید
   • ‫Deploy → New deployment → Web app → Execute as: Me + Who has access: Anyone → Deploy‬
   • ‫Deployment ID‬ رو کپی کنید

3. در ‫mhrv-rs‬ کانفیگ تنظیم کنید:

   • در اپ اندروید: ‫Advanced → Operating mode → Full tunnel (no cert)‬ رو انتخاب کنید
   • در دسکتاپ: فایل ‫config.json‬ رو باز کنید و ‫"mode": "full"‬ بذارید
   • ‫Deployment ID‬ ‫CodeFull.gs‬ رو در فیلد ‫script_id‬ بذارید
   • ‫auth_key‬ رو با مقدار داخل ‫CodeFull.gs‬ همسان کنید

4. ‫mhrv-rs‬ رو restart کنید. در لاگ باید ببینید:

   dispatch <host>:<port> -> full tunnel (via batch mux)
   

گزارش کاربری واقعی: ‫@Feiabyte‬ در ‫#61‬ این setup رو با ‫VPS‬ ترکیه از ایران تست کرده. ‫YouTube comments + channel videos‬ مثل مرورگر معمولی کار کرد. ‫gist‬ با جزئیات logها: https://gist.github.com/Feiabyte/53336122ac573ed5b4c73698089410ea

این ‫issue‬ رو به عنوان tracker برای مستندات رسمی باز نگه می‌دارم. اگه در تست بالا گیر کردید، همین‌جا بپرسید.

---

_{[پاسخ از ‫Anthropic Claude‬ | بازبینی‌شده توسط ‫@therealaleph‬]}

[Surenabedimiran]

You also suggested a method using the Cloudflare WARP, if it's still working, would you mind to repeat that or reference to it?
Thanks a lot!

[therealaleph]

Happy to. Small caveat first: my earlier mention of Cloudflare WARP was a bit loose — the official WARP client from cloudflare.com doesn't expose a SOCKS5 port, so you can't directly point mhrv-rs's upstream_socks5 at it. The setup that works in practice uses a community tool that speaks Cloudflare's WireGuard protocol and re-exposes it as a local SOCKS5.

Recipe (one of several that work):

1. Install warp-plus locally — a small Go binary that registers a WARP account for you, speaks WireGuard to Cloudflare, and exposes a local SOCKS5. Prebuilt binaries on their releases page for Linux / macOS / Windows.

2. Run it:

   # defaults are reasonable: binds to 127.0.0.1:8086, auto-scans for working endpoint
   ./warp-plus

   On first run it registers a free WARP account, saves the WireGuard private key locally, and starts listening. If their endpoint scanner picks an unreachable IP, add --scan.

3. Point mhrv-rs at it via config.json:

   {
     "mode": "apps_script",
     ...
     "upstream_socks5": "127.0.0.1:8086"
   }

   Restart mhrv-rs. Log should say tcp via upstream-socks5 127.0.0.1:8086 -> ... on each outbound.

Chain that gives you:

browser → mhrv-rs → warp-plus (local SOCKS5) → Cloudflare WARP → Apps Script / destination

Cloudflare sees traffic coming from their own WARP IP range (residential-friendly bot-score), so Cloudflare-protected sites like ChatGPT/Discord/Twitter stop looping on Turnstile CAPTCHA. Google sees the same — your script.google.com request originates from a WARP IP, which is fine because Apps Script doesn't care where the client is.

Caveats to know:

• Free WARP bandwidth is capped — fine for light browsing, painful for YouTube 1080p. The WARP+ plan (or scans for better endpoints) helps.
• Cloudflare WARP endpoint IPs sometimes blocked from Iran. warp-plus has --scan to find a working endpoint; if none work, you're stuck.
• This is third-party software — I don't maintain warp-plus. If it breaks, the issue is upstream.
• Not a substitute for Full Tunnel Mode with your own VPS. If you have a VPS outside Iran, feat: Mode::Full + batch tunnel client (2/3) #94's Full Tunnel Mode is cleaner (no third-party intermediary, no bandwidth cap). WARP is the "no VPS available" fallback.

Alternative: if you have a VPS reachable from Iran (even through another tunnel), the tunnel-mode walkthrough in #119's opening post is the preferred path.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[therealaleph]

Nope, not working at the moment. But I’m trying an alternative, if it works, I will implement it.

…

On Fri, Apr 24, 2026 at 18:27 Surena Abedi Miran ***@***.***> wrote: *Surenabedimiran* left a comment (therealaleph/MasterHttpRelayVPN-RUST#119) <#119 (comment)> You also suggested a method using the Cloudflare WARP, if it's still working, would you mind to repeat that or reference to it? Thanks a lot! — Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCU4TWJKMENN5OKDQVBEY34XOBV7AVCNFSM6AAAAACYFBACMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJUGMYDKNRSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[therealaleph]

@shabda7 در پاسخ سؤالتون:

نه، قبلی‌هاتون دیگه کنار بیلد تونل کار نمی‌کنن و باید دوباره Deploy بشن — با فایل متفاوتی.

تفاوت دو حالت:

• حالت apps_script (حالت عادی): Deploymentها بر اساس فایل Code.gs هستن. این اسکریپت داخل هر درخواست فقط یک هدف HTTP رو از طرف کاربر می‌گیره و فراخوانی می‌کنه.

• حالت full (تونل): Deploymentها باید بر اساس فایل CodeFull.gs باشن. این اسکریپت متفاوته — یک batch از درخواست‌ها رو از کاربر می‌گیره، به tunnel-node VPS شما forward می‌کنه، و پاسخ batch رو برمی‌گردونه.

نمی‌تونید ترکیب کنید. اگه در config مقدار "mode": "full" باشه ولی یک Deployment ID از نوع Code.gs توی لیست باشه، درخواست‌هایی که به اون Deployment می‌چرخن (round-robin) همه fail میشن چون Code.gs فرمت batch payload رو نمی‌شناسه.

دو راه دارید:

۱. کلاً به تونل کوچ کنید: همهٔ Deploymentهای قبلی رو با CodeFull.gs دوباره Deploy کنید. لیست IDها رو در فیلد Apps Script ID(s) نگه دارید (نیازی به حذف کردن و از اول ساختن حساب گوگل نیست — فقط محتوای اسکریپت رو عوض کنید و یک Deployment جدید بسازید).

۲. دو config جداگانه نگه دارید: یکی config-apps-script.json با IDهای قدیمی، یکی config-full.json با IDهای تونل جدید، و هر بار با mhrv-rs --config <path> سوییچ کنید. این در صورتی منطقیه که نمی‌خواید از مزیت تونل (سرعت بهتر، بدون MITM محلی) برای همهٔ استفاده‌ها بهره ببرید.

در مورد کندی که ذکر کردید: تونل بین Apps Script و VPS آلمان می‌تونه تا ۵۰۰ میلی‌ثانیه latency اضافه کنه. پهنای باند معمولاً خوبه (چند مگ در ثانیه) ولی تأخیر دیده میشه روی هر درخواست کوچیک. این ذات تونل هست و جبران‌پذیر نیست. اگه واقعاً خیلی کند هست (مثلاً چند ثانیه برای هر page load)، احتمالاً VPSتون overloaded هست یا شبکهٔ بین گوگل و سرورتون مشکل داره — لاگ batch: N ops → script_id, rtt=Xs رو نگاه کنید، اگه rtt همیشه بالای ۳ ثانیه‌ست، VPS یا شبکه مقصر هست.

در مورد WARP: بله، درست بود قبلاً، فعلاً کار نمی‌کنه (Cloudflare قفل کرده). alternative هم هنوز به جواب نرسیدیم.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[Mralimoh]

const TUNNEL_AUTH_KEY = "YOUR_TUNNEL_AUTH_KEY";
اینو باید چی وارد کرد؟

[therealaleph]

@Mralimoh درمورد سؤالتون:

const TUNNEL_AUTH_KEY = "YOUR_TUNNEL_AUTH_KEY";

این یک رمز مشترک (shared secret) بین دو طرف تونل است:

• CodeFull.gs که روی Apps Script شما اجرا میشه
• tunnel-node که روی VPS شما اجرا میشه

یعنی باید:

۱. یه رمز قوی و دلخواه انتخاب کنید — هر چیزی که بخواهید، مثلاً ۳۲ کاراکتر تصادفی. نمونه در لینوکس/مک:

openssl rand -hex 32

یا در ویندوز PowerShell:

-join ((65..90) + (97..122) + (48..57) | Get-Random -Count 32 | ForEach-Object {[char]$_})

یا هر رمز دیگه‌ای که دلتون می‌خواد (ولی حتماً قوی باشه، چون هر کسی این رو داشته باشه می‌تونه از تونل شما سوءاستفاده کنه).

۲. همون رمز رو در دو جا بذارید:

• در CodeFull.gs (داخل editor Apps Script): خط const TUNNEL_AUTH_KEY = "YOUR_TUNNEL_AUTH_KEY"; → const TUNNEL_AUTH_KEY = "رمز_شما_اینجا";
• در tunnel-node (روی VPS): متغیر محیطی TUNNEL_AUTH_KEY=رمز_شما_اینجا

# روی VPS، هنگام اجرای tunnel-node
TUNNEL_AUTH_KEY=رمز_شما_اینجا PORT=8080 ./tunnel-node

مهم: این رمز متفاوت از AUTH_KEY در Code.gs (حالت عادی apps_script) هست. دو رمز جداگانه:

• AUTH_KEY (در Code.gs): بین کلاینت (mhrv-rs) و Apps Script
• TUNNEL_AUTH_KEY (در CodeFull.gs): بین Apps Script و tunnel-node

در حالت full هر دو لازمه — mhrv-rs از auth_key برای اثبات هویت به CodeFull.gs استفاده می‌کنه، بعد CodeFull.gs از TUNNEL_AUTH_KEY برای اثبات به tunnel-node استفاده می‌کنه.

مرجع: در تنظیمات کلاینت mhrv-rs هم یه فیلد tunnel_auth_key در config.json هست — این نباید ست بشه در حالت عادی، چون هیچ کلاینتی مستقیماً به tunnel-node حرف نمی‌زنه. فقط CodeFull.gs با tunnel-node حرف می‌زنه و اون فیلد برای همون کانال است.

راهنمای کامل setup: tunnel-node/README.md.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[dazzling-no-more]

@shabda7 در پاسخ سؤالتون:

نه، قبلی‌هاتون دیگه کنار بیلد تونل کار نمی‌کنن و باید دوباره Deploy بشن — با فایل متفاوتی.

تفاوت دو حالت:

• حالت apps_script (حالت عادی): Deploymentها بر اساس فایل Code.gs هستن. این اسکریپت داخل هر درخواست فقط یک هدف HTTP رو از طرف کاربر می‌گیره و فراخوانی می‌کنه.
• حالت full (تونل): Deploymentها باید بر اساس فایل CodeFull.gs باشن. این اسکریپت متفاوته — یک batch از درخواست‌ها رو از کاربر می‌گیره، به tunnel-node VPS شما forward می‌کنه، و پاسخ batch رو برمی‌گردونه.

نمی‌تونید ترکیب کنید. اگه در config مقدار "mode": "full" باشه ولی یک Deployment ID از نوع Code.gs توی لیست باشه، درخواست‌هایی که به اون Deployment می‌چرخن (round-robin) همه fail میشن چون Code.gs فرمت batch payload رو نمی‌شناسه.

دو راه دارید:

۱. کلاً به تونل کوچ کنید: همهٔ Deploymentهای قبلی رو با CodeFull.gs دوباره Deploy کنید. لیست IDها رو در فیلد Apps Script ID(s) نگه دارید (نیازی به حذف کردن و از اول ساختن حساب گوگل نیست — فقط محتوای اسکریپت رو عوض کنید و یک Deployment جدید بسازید).

۲. دو config جداگانه نگه دارید: یکی config-apps-script.json با IDهای قدیمی، یکی config-full.json با IDهای تونل جدید، و هر بار با mhrv-rs --config <path> سوییچ کنید. این در صورتی منطقیه که نمی‌خواید از مزیت تونل (سرعت بهتر، بدون MITM محلی) برای همهٔ استفاده‌ها بهره ببرید.

در مورد کندی که ذکر کردید: تونل بین Apps Script و VPS آلمان می‌تونه تا ۵۰۰ میلی‌ثانیه latency اضافه کنه. پهنای باند معمولاً خوبه (چند مگ در ثانیه) ولی تأخیر دیده میشه روی هر درخواست کوچیک. این ذات تونل هست و جبران‌پذیر نیست. اگه واقعاً خیلی کند هست (مثلاً چند ثانیه برای هر page load)، احتمالاً VPSتون overloaded هست یا شبکهٔ بین گوگل و سرورتون مشکل داره — لاگ batch: N ops → script_id, rtt=Xs رو نگاه کنید، اگه rtt همیشه بالای ۳ ثانیه‌ست، VPS یا شبکه مقصر هست.

در مورد WARP: بله، درست بود قبلاً، فعلاً کار نمی‌کنه (Cloudflare قفل کرده). alternative هم هنوز به جواب نرسیدیم.

[reply via Anthropic Claude | reviewed by @therealaleph]

I also deployed full mode. It works, but the connection is barely usable. At the current state, it is only usable to exchange text based whatsapp messages. I am working on some optimization that may improve the latency. The issue is not on vps side for sure.

[therealaleph]

@shabda7 سؤال خوبی هست. Instagram کپچا و logout زدن از حساب با اینکه IP سرور تمیز هست — این الگوی شناخته‌شده‌ای داره و معمولاً مشکل از mhrv-rs نیست.

چند علت محتمل، به ترتیب احتمال:

۱. Datacenter IP detection. "تمیز" بودن IP در ذهن کاربر یعنی "blacklisted نیست" — ولی Instagram (و Meta در کل) داره چیز متفاوتی چک می‌کنه: آیا این IP مال یه residential ISP هست یا یه cloud datacenter؟ IPهای DigitalOcean، Hetzner، Linode، AWS، GCP — همشون به‌عنوان "datacenter IP" شناخته شده. Meta در سال‌های اخیر بسیار aggressive شده در flag کردن login از datacenter IPها — حتی اگه IP "clean" باشه (یعنی blocklist نباشه)، هنوز high suspicion می‌گیره و کپچا/logout می‌زنه.

می‌تونید چک کنید: IP سرورتون رو در https://ipinfo.io ببینید. اگه field org چیزی شبیه AS14061 DigitalOcean LLC نشون بده، Instagram اون رو datacenter می‌بینه.

۲. Geographic mismatch. اگه اکانت Instagram شما تاریخچهٔ login از ایران داره ولی الان IP سرور (مثلاً) آمریکا هست، Meta این رو "impossible travel" یا "geographic anomaly" می‌بینه و خودکار logout می‌زنه + کپچا. این مخصوصاً اولین بار که از IP خارجی login می‌کنید بدتره.

۳. Behavioral fingerprint. Meta TLS fingerprint client (JA3/JA4)، sequence درخواست‌ها، timing pattern، و user-agent header رو ترکیب می‌کنه. در Tunnel mode، mhrv-rs raw TCP رو tunnel می‌کنه — TLS handshake از Instagram app/browser واقعی شما هست، که OK هست. ولی gap timing بین درخواست‌ها (به خاطر VPS round-trip) ممکنه از pattern طبیعی فرار کنه.

چیزهایی که کمک می‌کنن (به ترتیب اثربخشی):

1. IP residential: اگه می‌تونید سرور رو روی یه ISP residential داشته باشید (مثلاً Hetzner/EU residential IP، یا یه OpenWrt router در آمریکا/اروپا که خونوادتون داره و SSH می‌گیرید) — مشکل تقریباً برطرف می‌شه. Meta residential IPها رو بسیار کم flag می‌کنه.

2. Login از gradual buildup: قبل از login مستقیم به Instagram، چند ساعت یا چند روز browsing سبک از همون IP بکنید (Google search، YouTube، شبکه‌های اجتماعی دیگه). Meta یه "trust score" برای IP می‌سازه — IPای که چند روز web browsing عادی نشون داده، کمتر flag می‌شه از IPای که اولین درخواستش login Instagram هست.

3. مرورگر تمیز + cookie جدید: incognito + cookies clear قبل از login جدید. اگه Meta از cookieهای قدیمی fingerprint قبلی شما رو ببینه (که از IP ایران بود)، تشخیص "همون user از IP جدید" رو می‌ده.

4. 2FA active: اکانت‌هایی که 2FA دارن، Meta کمتر اقدامات automated security می‌گیره (چون می‌تونه به جای logout از 2FA challenge استفاده کنه).

در مورد سؤال قبلی شما (سرور-سمت request): بله این یه pattern معتبر هست — یه proxy کلاسیک از سمت سرور درخواست می‌کنه و response رو برمی‌گردونه. این همون چیزی هست که tunnel-node در Full mode می‌کنه. Apps Script connection setup رو می‌سازه (تا DPI گول بخوره) ولی request واقعی به origin از VPS می‌ره — exactly مدل سرور-سمت. پس از این منظر، کاری که دنبالشید already موجوده.

اگه VPS تون ایده‌آل نیست و Instagram خاصاً مهم هست: یه راه‌حل غیر-معمول اینه که از یه دستگاه residential outside Iran (مثلاً یه Raspberry Pi خونهٔ کسی در اروپا، یا یه router OpenWrt با ddclient setup) به‌عنوان tunnel-node استفاده کنید. residential IP + ssh tunnel معمولاً Instagram رو راضی می‌کنه.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}