راه اندازی Cloudflare Tunnel بدون باز کردن پورت در VPS

عملکرد Cloudflare Tunnel و معنای واقعی باز نبودن پورت‌ها

سرویس Cloudflare Tunnel یک daemon کوچک به نام cloudflared را روی VPS شما اجرا می‌کند. این daemon یک اتصال خروجی به سمت Cloudflare برقرار کرده و آن را باز نگه می‌دارد. درخواست‌های مربوط به نام دامنه شما به لبه شبکه (edge) Cloudflare می‌رسند و از طریق همان اتصال موجود به سمت سرور شما هدایت می‌شوند؛ بنابراین هیچ اتصالی نباید به‌صورت مستقیم به داخل سرور شما برقرار شود.

مرحله‌ای که اکثر راهنماها به آن نمی‌پردازند این است: نصب tunnel به تنهایی چیزی را نمی‌بندد. اگر پورت‌های 80 و 443 همچنان در فایروال شما باز باشند و برنامه شما همچنان روی 0.0.0.0 گوش دهد، شما در واقع راه دومی برای ورود ایجاد کرده‌اید، نه اینکه راه اول را جایگزین کنید. IP اصلی (origin IP) شما همچنان در دسترس است و هر کسی که آن را پیدا کند، بدون عبور از Cloudflare مستقیماً به سرور شما دسترسی خواهد داشت. بستن آن پورت‌ها یک اقدام دستی است و همین مرحله است که ارزش تمام کارهای قبلی را تعیین می‌کند.

سرویس cloudflared برای کارکرد صحیح به دسترسی خروجی به region1.v2.argotunnel.com و region2.v2.argotunnel.com روی پورت 7844 نیاز دارد. این سرویس از پروتکل UDP برای QUIC استفاده می‌کند و در صورت عدم موفقیت، به TCP برای HTTP/2 تغییر وضعیت می‌دهد. در شبکه‌ای که فیلترینگ خروجی (egress filtering) دارد، هر دو پروتکل را مجاز کنید یا با استفاده از --protocol http2، مسیر را روی TCP اجبار کنید.

پیش از شروع

• دامنه‌ای که از قبل در حساب Cloudflare ثبت شده باشد و از DNS سرورهای Cloudflare برای مدیریت zone استفاده کند. cloudflared tunnel route dns رکوردها را در این zone می‌نویسد، بنابراین zone باید از قبل وجود داشته باشد.
• دسترسی خروجی روی پورت 7844 از سمت VPS، هم برای پروتکل UDP و هم TCP.
• برنامه‌ای که از قبل به‌صورت محلی در حال گوش دادن باشد؛ حتی اگر برای اولین تست فقط از python3 -m http.server 8080 استفاده کنید.
• sudo روی سیستم نصب باشد و پیش از تغییر تنظیمات فایروال، یک نشست SSH دوم باز نگه دارید.

نصب cloudflared روی Ubuntu یا Debian

Cloudflare برای هر cloudflared یک بسته .deb ارائه می‌دهد، بنابراین نصب آن تنها با یک دانلود و یک فراخوانی dpkg انجام می‌شود.

curl -fsSL -o /tmp/cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

اگر از معماری سیستم خود مطمئن نیستید، ابتدا dpkg --print-architecture را اجرا کنید. در سیستم‌های 64-bit ARM، نام فایل به جای amd64 به arm64 ختم می‌شود و هیچ تغییر دیگری وجود ندارد. چاپ رشته نسخه توسط cloudflared --version تنها تأییدی است که پیش از ادامه کار به آن نیاز دارید.

بسته‌ای که به این روش نصب می‌شود خارج از مسیر به‌روزرسانی apt قرار می‌گیرد، بنابراین apt-get upgrade هرگز آن را تغییر نمی‌دهد و به‌روزرسانی آن بر عهده شماست. sudo cloudflared update جدیدترین نسخه را دریافت کرده و فایل باینری را جایگزین می‌کند؛ پس از اینکه سرویس ایجاد شد، آن را با sudo systemctl restart cloudflared دنبال کنید تا پردازش در حال اجرا، فایل باینری جدید باشد. این کار را در همان زمان‌بندی سایر عملیات‌های وصله‌گذاری (patching) خود قرار دهید، زیرا daemon تونل نرم‌افزاری است که با اینترنت در ارتباط است، حتی اگر هیچ پورتی را باز نکند.

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

cloudflared tunnel login

در یک VPS بدون رابط گرافیکی (headless)، هیچ مرورگری باز نمی‌شود؛ بنابراین URL چاپ‌شده را کپی کرده و در مرورگر لپ‌تاپ خود باز کنید و zone مورد نظر را انتخاب نمایید. پس از پایان این فرآیند، فایل ~/.cloudflared/cert.pem ایجاد می‌شود.

فایل cert.pem اعتبارنامه حساب کاربری شماست. این فایل مجوز ایجاد تونل‌ها، نوشتن رکوردهای DNS در آن zone و حذف تونل‌ها را صادر می‌کند. تونل در حال اجرا هرگز از این فایل استفاده نمی‌کند. با آن مانند یک رمز عبور رفتار کنید، زیرا داشتن یک کپی از این فایل برای هر کسی کافی است تا بتواند نام‌های میزبان (hostname) جدیدی روی دامنه شما منتشر کند.

cloudflared tunnel create homelab

اجرای موفقیت‌آمیز دستور، هر دو خط زیر را چاپ می‌کند و UUID موجود در آن‌ها مقداری است که باید در فایل پیکربندی جای‌گذاری کنید.

Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

آن فایل JSON هویت تونل است و تنها اعتبارنامه‌ای است که سرویس در حال اجرا به آن نیاز دارد. هر کسی که آن را در اختیار داشته باشد می‌تواند به عنوان تونل شما ثبت‌نام کرده و ترافیک شما را دریافت کند. راهی برای چرخش (rotate) مستقل آن وجود ندارد: ابطال آن به معنای حذف cloudflared tunnel delete homelab و ایجاد یک تونل جدید است.

فایل اعتبارنامه‌ها را در مکانی امن نگهداری کنید

این سرویس با دسترسی root اجرا می‌شود، بنابراین فایل را در دایرکتوری متعلق به root قرار دهید. آن را در دایرکتوری home رها نکنید، چرا که ممکن است توسط یک job پشتیبان‌گیری یا یک حساب کاربری اشتراکی در دسترس قرار گیرد.

sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
  ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
  /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel list

ls -l باید -rw------- root root را روی فایل JSON نشان دهد. cloudflared tunnel list فایل cert.pem را می‌خواند، بنابراین به کار خود ادامه می‌دهد و باید نام تونل، UUID آن و تعداد اتصالاتی که در حال حاضر برقرار است را چاپ کند.

نوشتن فایل config.yml با قوانین ingress واقعی

فایل پیکربندی را در /etc/cloudflared/config.yml بنویسید، نه در دایرکتوری home خود. دلیل آن این است: cloudflared service install هر فایلی که در آنجا بیابد را به /etc/cloudflared/config.yml کپی می‌کند و سپس --config /etc/cloudflared/config.yml را در unit مربوط به systemd هاردکد می‌کند. اگر فایل را در ~/.cloudflared/config.yml ایجاد کنید، آن کپی فقط یک snapshot یک‌باره خواهد بود. هر ویرایش بعدی در نسخهٔ موجود در home هیچ تغییری ایجاد نمی‌کند، سرویس همچنان قوانین قدیمی را اجرا می‌کند و هیچ هشداری هم دریافت نخواهید کرد. نوشتن فایل در مسیر اصلی، این مشکل را به‌طور کامل حل می‌کند.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - hostname: files.example.com
    service: http://127.0.0.1:8081
  - hostname: grafana.example.com
    path: ^/api/
    service: http://127.0.0.1:3000
  - service: http_status:404

قوانین از بالا به پایین خوانده می‌شوند و اولین تطابق (match) اعمال می‌گردد. قانونی که فاقد hostname باشد با هر نام دامنه‌ای مطابقت دارد، به همین دلیل است که قانون catch-all باید در انتها قرار گیرد. اگر آن را حذف کنید، پیکربندی با خطای The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter) رد می‌شود. http_status:404 یک سرویس داخلی است که به درخواست‌ها پاسخ 404 می‌دهد و کار دیگری انجام نمی‌دهد. وجود آن ضروری است: بدون آن، درخواستی برای نام دامنه‌ای که قصد انتشار آن را نداشته‌اید، به آخرین قانون واقعی موجود هدایت می‌شود.

در URL مربوط به service:، به‌جای localhost از 127.0.0.1 استفاده کنید. در اوبونتو، localhost ابتدا به ::1 ترجمه می‌شود و برنامه‌ای که فقط روی IPv4 loopback گوش می‌دهد، این اتصال را رد می‌کند. خط لاگ در این حالت dial tcp [::1]:8080: connect: connection refused است و کاربر با خطای 502 مواجه می‌شود.

استفاده از http:// ساده در اینجا صحیح است زیرا این hop هرگز از ماشین خارج نمی‌شود. فقط زمانی از https:// استفاده کنید که برنامهٔ محلی بر TLS (امنیت لایه انتقال) اصرار داشته باشد، و در صورتی که گواهی آن با نامی که فراخوانی کرده‌اید مطابقت نداشته باشد، منتظر خطای x509: certificate is valid for example.com, not localhost باشید. این مشکل را با originServerName در زیر originRequest برطرف کنید، یا با استفاده از noTLSVerify: true ریسک آن را بپذیرید.

پیش از شروع هر کاری، قوانین را بررسی کنید:

sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/login

ingress validate معتبر بودن پیکربندی را گزارش می‌دهد یا نام قانونی که باعث شکست آن شده را اعلام می‌کند. ingress rule یک URL را دریافت کرده و اولین قانونی که با آن مطابقت دارد را چاپ می‌کند؛ این سریع‌ترین راه برای فهمیدن این است که یک regex در path با آنچه تصور می‌کردید مطابقت ندارد.

اشاره کردن DNS به تونل

cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.com

هر فراخوانی، یک رکورد CNAME پروکسی‌شده ایجاد می‌کند که به 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com اشاره دارد. آن مقصد فقط در داخل شبکه Cloudflare قابل حل (resolve) است، بنابراین پاسخ DNS عمومی برای نام دامنه شما یک آدرس Cloudflare است و IP سرور VPS شما هرگز در آن ظاهر نمی‌شود. یک رکورد wildcard در hostname در config.yml همچنان به یک رکورد DNS منطبق برای هر نامی که واقعاً استفاده می‌کنید، نیاز دارد.

هنگامی که یک رکورد از قبل وجود داشته باشد، دستور با خطای زیر مواجه می‌شود:

Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.

آن رکورد موجود، تقریباً همیشه همان رکورد A قدیمی است که به IP عمومی VPS شما اشاره دارد؛ دقیقاً همان رکوردی که می‌خواهید حذف شود. آن را در داشبورد Cloudflare حذف کنید و سپس دستور را دوباره اجرا کنید. باقی گذاشتن آن به این معنی است که DNS همچنان IP اصلی شما را منتشر می‌کند و در نتیجه، تونل هیچ چیزی را مخفی نمی‌کند.

نصب آن به عنوان یک سرویس برای پایداری پس از راه‌اندازی مجدد

ابتدا آن را یک بار در پیش‌زمینه (foreground) اجرا کنید، زیرا خواندن خطا در ترمینال شخصی بسیار آسان‌تر از بررسی آن در journal است.

sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelab

یک شروع موفق، چندین خط Registered tunnel connection را لاگ می‌کند که برای هر edge location یک مورد است و هر کدام connIndex مخصوص به خود را دارد. یکی از نام‌های میزبان (hostname) خود را در مرورگر باز کنید و تأیید کنید که قوانین ورودی (ingress rules) شما را به مقصد مورد نظر هدایت می‌کنند، سپس با استفاده از Ctrl-C آن را متوقف کنید.

sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflared

این دستور /etc/systemd/system/cloudflared.service را به همراه cloudflared-update.service و cloudflared-update.timer می‌نویسد و سپس systemctl enable cloudflared.service و systemctl start cloudflared.service را برای شما اجرا می‌کند. بخش enable در اینجا اهمیت دارد، زیرا همان چیزی است که تونل را پس از راه‌اندازی مجدد (reboot) دوباره فعال می‌کند. مقدار ExecStart در unit برابر با cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run است، به همین دلیل است که مسیر پیکربندی در آن قابل تغییر نیست.

سه خطا در این مرحله پیام‌های مشخصی دارند. possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml به این معنی است که هر دو فایل وجود دارند و cloudflared از حدس زدن خودداری می‌کند: فایلی که نیاز ندارید را حذف کنید. configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE) به این معنی است که پیکربندی شما از میان‌بر سریع url: به جای کلیدهای تونل نام‌گذاری‌شده استفاده می‌کند و آن میان‌بر نمی‌تواند به عنوان یک سرویس اجرا شود. cloudflared service is already installed به این معنی است که یک unit قدیمی هنوز در جای خود قرار دارد، بنابراین ابتدا sudo cloudflared service uninstall را اجرا کنید.

گزینه‌ای برای reload وجود ندارد. پس از ویرایش /etc/cloudflared/config.yml، دستور sudo systemctl restart cloudflared را اجرا کنید. سپس به جای فرض کردن، ادعای پایداری پس از راه‌اندازی مجدد را اثبات کنید:

sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.com

چاپ شدن enabled توسط is-enabled و چاپ شدن active توسط is-active، هدف اصلی این بخش است. هنگامی که مسیرها (routes) وجود دارند و سرویس در حال اجراست، cert.pem دیگر وظیفه‌ای روی سرور ندارد: rm ~/.cloudflared/cert.pem. افزودن یک نام میزبان در آینده، صرفاً به معنای اجرای مجدد cloudflared tunnel login است.

پورت‌های 80 و 443 را ببندید، در غیر این صورت تونل فقط یک مسیر اضافی است

شما به دو تغییر نیاز دارید و باید هر دو را انجام دهید. انجام یکی بدون دیگری باعث می‌شود مبدأ همچنان در دسترس باقی بماند.

ابتدا، برنامه را به آدرس loopback متصل کنید. در Nginx این به معنای استفاده از listen 127.0.0.1:8080; به‌جای listen 80; است؛ همان تغییری که در این راهنمای پیکربندی reverse proxy در Nginx بررسی شد. در Docker Compose این کار به معنای استفاده از ports: - "127.0.0.1:8080:80" است. فرم ساده "8080:80" پورت را روی تمام اینترفیس‌ها منتشر می‌کند و Docker قوانین NAT (ترجمه آدرس شبکه) خاص خود را می‌نویسد که بسته‌ها پیش از رسیدن به ufw با آن‌ها برخورد می‌کنند، بنابراین یک قانون deny در ufw مانع آن نخواهد شد. این تله مقاله جداگانه‌ای دارد: چرا پورت‌های منتشر شده توسط Docker قوانین ufw را نادیده می‌گیرند.

sudo ss -lntp

اکنون هر سرویسی که منتقل کرده‌اید باید در ستون Local Address مقدار 127.0.0.1:8080 را نشان دهد. خطی که 0.0.0.0:8080 یا *:8080 را نشان می‌دهد، همچنان در حال گوش دادن به درخواست‌های عمومی است.

دوم، پورت‌ها را ببندید.

sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw status

به‌جای انباشتن قوانین deny روی قوانین allow، قوانین allow مربوط به 80 و 443 را حذف کنید، زیرا ufw در اولین قانون منطبق متوقف می‌شود و یک قانون allow قدیمی که در لیست بالاتر باشد، اولویت پیدا می‌کند. قانون SSH خود را حفظ کنید. راهنمای اصول اولیه فایروال ufw بقیه آن مجموعه قوانین را پوشش می‌دهد. اکثر ارائه‌دهندگان VPS یک فایروال شبکه مجزا در پنل کنترل خود دارند که ufw نیست، بنابراین پورت‌های 80 و 443 را در آنجا نیز ببندید.

اکنون از یک مکان دیگر بررسی کنید، زیرا اجرای curl http://127.0.0.1:8080 روی خود سرور، چیزی را درباره دنیای خارج ثابت نمی‌کند.

# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.com

نتیجه‌ای که به دنبال آن هستید، یک خطای refused یا timed-out در nc برای IP خام، به همراه یک 200 موفق از طریق نام دامنه است. بررسی باز بودن واقعی یک پورت روش‌های بیشتری برای تست این موضوع ارائه می‌دهد.

تونل یک ابزار انتقال است، نه احراز هویت. هر چیزی که از طریق آن منتشر می‌کنید به‌صورت عمومی در دسترس خواهد بود، مگر اینکه یک لایه ورود (login) در مقابل آن قرار دهید؛ یا Cloudflare Access در لبه شبکه، یا یک OAuth2 proxy که جلوی برنامه روی سرور قرار می‌گیرد. SSH نیز به پاسخ خاص خود نیاز دارد، زیرا تونل آن را پوشش نمی‌دهد: پورت 22 را باز نگه دارید اما دسترسی آن را فقط به آدرس‌های مبدأ خود محدود کنید.

مزایای استفاده از Cloudflare Tunnel و هزینه‌های آن

مزایایی که به دست می‌آورید واقعی هستند. IP مبدأ شما دیگر منتشر نمی‌شود، هیچ پورت ورودی باز نمی‌ماند، راه‌اندازی از ماشینی که اصلاً IP عمومی ندارد امکان‌پذیر است، گواهی عمومی بر عهده Cloudflare است بنابراین هیچ کلاینت ACME (محیط مدیریت خودکار گواهی) روی سیستم شما اجرا نمی‌شود و حملات حجمی به جای مصرف پهنای باند شما، در لبه شبکه جذب می‌شوند.

هزینه‌ها نیز به همان اندازه واقعی هستند. Cloudflare عملیات TLS termination را در لبه شبکه خود انجام می‌دهد: درخواست بازدیدکننده شما در آنجا رمزگشایی و برای ارسال در تونل مجدداً رمزگذاری می‌شود، بنابراین Cloudflare می‌تواند ترافیک را بخواند. این همان چیزی است که فایروال، کشینگ و قوانین Access آن‌ها را ممکن می‌سازد و هیچ تنظیمی وجود ندارد که در حین استفاده از پروکسی آن‌ها، این قابلیت را غیرفعال کند. اگر دسترسی شخص ثالث به داده‌های متنی شما غیرقابل‌قبول است، همین‌جا متوقف شوید و راهکار دیگری انتخاب کنید.

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

تنها پروتکل‌های HTTP، HTTPS و WebSocket از طریق یک مرورگر معمولی به نام میزبان عمومی دسترسی دارند. هر پروتکل TCP دیگر، SSH یا RDP (پروتکل دسکتاپ از راه دور) یا سرور بازی، به نرم‌افزار در سمت کلاینت نیز نیاز دارد: cloudflared access tcp برای فوروارد کردن یک پورت محلی، یا کلاینت WARP. هیچ مسیر بدون کلاینتی برای این موارد وجود ندارد.

بدنه درخواست‌ها در لبه شبکه محدود شده است و آپلود بیش از حد مجاز، قبل از رسیدن به برنامه شما با خطای HTTP 413 رد می‌شود. تا اوت 2026، این سقف در طرح‌های رایگان و Pro برابر با 100 MB و در سطوح پولی بالاتر است، بنابراین قبل از طراحی بر اساس یک عدد خاص، صفحه محدودیت‌های فعلی Cloudflare را بررسی کنید. شرایط استفاده از سرویس‌های Cloudflare همچنین استفاده از پروکسی را عمدتاً برای میزبانی ویدیو و سایر فایل‌های غیر HTML بزرگ محدود می‌کند، که خواندن آن قبل از متصل کردن یک کتابخانه رسانه‌ای به یک تونل رایگان، ارزشمند است.

Cloudflare Tunnel، تونل SSH معکوس یا Tailscale Funnel

هر سه روش فقط خروجی (outbound-only) هستند، بنابراین هر سه از سیستمی که پورت ورودی ندارد و IP عمومی ندارد، کار می‌کنند. تفاوت آن‌ها در این است که چه کسی متن ساده (plaintext) شما را در اختیار دارد و عموم چه نام دامنه‌ای را می‌بینند.

یک تونل SSH معکوس به ماشین دومی نیاز دارد که دارای IP عمومی باشد؛ آن ماشین به درگاه ورودی تبدیل می‌شود: گواهی، reverse proxy و فایروال روی آن، همگی تحت مدیریت شما هستند. هیچ‌کس دیگری چیزی را رمزگشایی نمی‌کند. این روش قطعات متحرک بیشتری دارد و برای پایداری در برابر قطعی‌های شبکه، به autossh یا یک unit در systemd با Restart=always نیاز دارد. راهنمای گام‌به‌گام تونل SSH معکوس برای CGNAT این پیاده‌سازی را بررسی می‌کند.

Tailscale Funnel نزدیک‌ترین مقایسه است. این روش نیز به همان شکل فقط خروجی است و TLS روی ماشین خودتان خاتمه می‌یابد، بنابراین relayهای Tailscale هرگز متن ساده را نمی‌بینند. هزینه آن در نام‌گذاری و پورت‌ها است: Funnel فقط نام‌های زیر دامنه ts.net در tailnet شما را سرویس‌دهی می‌کند و فقط روی پورت‌های 443، 8443 و 10000 کار می‌کند. تفاوت بین Tailscale Serve و Funnel هر دو جنبه را پوشش می‌دهد.

بنابراین بر اساس محدودیتی که واقعاً شما را درگیر کرده است، انتخاب کنید. زمانی که عموم باید به دامنه شخصی شما دسترسی داشته باشند و می‌پذیرید که Cloudflare ترافیک را می‌خواند، Cloudflare Tunnel را انتخاب کنید. زمانی که یک نام میزبان ts.net قابل‌قبول است و تحویل متن ساده به یک پروکسی مجاز نیست، Tailscale Funnel را انتخاب کنید. زمانی که از قبل یک سرور عمومی دارید و نمی‌خواهید هیچ شخص ثالثی در مسیر قرار بگیرد، تونل SSH معکوس را انتخاب کنید.

FAQ

آیا با استفاده از Cloudflare Tunnel همچنان نیاز دارم پورت 443 را باز بگذارم؟

خیر. cloudflared یک اتصال خروجی به Cloudflare روی پورت 7844 برقرار می‌کند و تمام درخواست‌ها از طریق همین اتصال بازگشت داده می‌شوند، بنابراین هیچ پورت ورودی استفاده نمی‌شود. البته نصب تونل به خودی خود چیزی را برای شما نمی‌بندد. قوانین allow برای پورت‌های 80 و 443 را در ufw حذف کنید، آن‌ها را در فایروال شبکهٔ ارائه‌دهندهٔ خود ببندید، برنامه را روی 127.0.0.1 bind کنید و هر رکورد A باقی‌مانده که IP سرور VPS شما را منتشر می‌کند، پاک کنید. وضعیت را با sudo ss -lntp روی همان سرور و nc -vz <your-ip> 443 از یک ماشین دیگر تأیید کنید.

چرا نام دامنهٔ من خطای 1033 Cloudflare را نشان می‌دهد؟

خطای 1033 به این معنی است که Cloudflare رکورد DNS را برای آن نام دامنه در اختیار دارد اما نمی‌تواند یک cloudflared سالم متصل برای دریافت درخواست پیدا کند. یا پروسه متوقف شده است، یا در حال اجراست اما نمی‌تواند به Cloudflare متصل شود. systemctl status cloudflared و journalctl -u cloudflared -n 50 را بررسی کنید، سپس مطمئن شوید که پورت خروجی 7844 برای هر دو پروتکل UDP و TCP باز است؛ چرا که فایروالی که UDP و QUIC را مسدود می‌کند بدون اینکه اجازهٔ fallback به TCP را بدهد، دقیقاً همین خطا را ایجاد می‌کند. cloudflared tunnel info homelab اتصالاتی را که Cloudflare در حال حاضر می‌بیند نشان می‌دهد و خالی بودن این لیست، نشان‌دهندهٔ وجود مشکل در سمت شماست.

چرا از طریق تونل خطای 502 Bad Gateway دریافت می‌کنم؟

خطای 502 به این معنی است که cloudflared در دسترس قرار گرفته اما نتوانسته به سرویس محلی شما متصل شود، بنابراین مشکل بین این دو نقطه است و نه در سمت Cloudflare. لاگ را بخوانید. dial tcp [::1]:8080: connect: connection refused به این معنی است که در آدرسی که مشخص کرده‌اید، سرویسی در حال گوش دادن نیست و [::1] در آن پیام معمولاً به این معناست که شما در URL مربوط به service: عبارت localhost را نوشته‌اید در حالی که برنامه فقط روی IPv4 گوش می‌دهد؛ پس به جای آن http://127.0.0.1:8080 را بنویسید. HTTP/1.x transport connection broken: malformed HTTP response برعکس این عدم تطابق است: شما https:// را نوشته‌اید در حالی که مبدأ (origin) فقط با HTTP ساده صحبت می‌کند.

آیا می‌توانم SSH، RDP یا یک سرور بازی را از طریق Cloudflare Tunnel اجرا کنم؟

نه با یک کلاینت معمولی. یک نام دامنهٔ عمومی از طریق تونل، ترافیک HTTP، HTTPS و WebSocket را منتقل می‌کند که زبان مرورگرهاست. هر پروتکل TCP دیگری نیاز به نرم‌افزار روی ماشین کلاینت دارد، یا از طریق cloudflared access tcp که یک پورت محلی را فوروارد می‌کند یا از طریق کلاینت WARP. اگر می‌خواهید از هر ماشینی و بدون نصب هیچ نرم‌افزاری به SSH متصل شوید، این تونل ابزار مناسبی نیست. پورت 22 را باز نگه دارید و دسترسی به آن را بر اساس آدرس مبدأ محدود کنید.

آیا Cloudflare ترافیک من را از طریق تونل می‌بیند؟

بله. Cloudflare گواهی TLS را در لبهٔ شبکه (edge) خود خاتمه می‌دهد، درخواست را در آنجا رمزگشایی می‌کند و دوباره آن را برای ارسال به سرور شما در تونل رمزگذاری می‌کند. همین رمزگشایی است که باعث می‌شود فایروال، کشینگ و سیاست‌های Access آن‌ها کار کند و این یعنی متن سادهٔ ترافیک شما روی ماشین‌های آن‌ها وجود دارد. هیچ پیکربندی‌ای وجود ندارد که هنگام استفاده از پروکسی آن‌ها، از این موضوع جلوگیری کند. اگر این مسئله برای شما غیرقابل‌قبول است، از Tailscale Funnel استفاده کنید یا یک reverse proxy شخصی روی یک سرور عمومی راه‌اندازی کنید.