Cloudflare Tunnel ব্যবহার করে VPS-এর পোর্ট বন্ধ করার নিয়ম

Cloudflare Tunnel কী করে এবং কোনো open port না থাকার প্রকৃত অর্থ কী

Cloudflare Tunnel আপনার VPS-এ cloudflared নামক একটি ছোট daemon স্থাপন করে। এই daemon-টি Cloudflare-এর দিকে একটি বহির্মুখী সংযোগ তৈরি করে এবং তা সচল রাখে। আপনার hostname-এর জন্য আসা অনুরোধগুলো Cloudflare-এর edge-এ পৌঁছায় এবং বিদ্যমান সেই সংযোগের মাধ্যমেই আপনার সার্ভারে ফিরে আসে, তাই আপনার সার্ভারে বাইরে থেকে সরাসরি কোনো সংযোগের প্রয়োজন হয় না।

অধিকাংশ নির্দেশিকায় যে ধাপটি এড়িয়ে যাওয়া হয় তা হলো: tunnel ইনস্টল করলেই কোনো কিছু বন্ধ হয়ে যায় না। যদি আপনার firewall-এ 80 এবং 443 port খোলা থাকে এবং আপনার অ্যাপ যদি এখনো 0.0.0.0-এ listen করতে থাকে, তবে আপনি প্রথম পথটি প্রতিস্থাপন না করে বরং প্রবেশের একটি দ্বিতীয় পথ তৈরি করেছেন। আপনার origin IP এখনো reachable এবং যে কেউ এটি খুঁজে পেলে Cloudflare-কে এড়িয়ে সরাসরি আপনার সার্ভারে প্রবেশ করতে পারবে। এই port-গুলো বন্ধ করা একটি ম্যানুয়াল ধাপ এবং এই ধাপটিই উপরের সব কাজের কার্যকারিতা নিশ্চিত করে।

cloudflared-এর region1.v2.argotunnel.com এবং region2.v2.argotunnel.com-এর 7844 port-এ বহির্মুখী সংযোগের প্রয়োজন হয়। এটি QUIC protocol-এর জন্য UDP ব্যবহার করে এবং HTTP/2-এর জন্য TCP-তে fallback করে। egress filtering আছে এমন নেটওয়ার্কে উভয়ই allow করুন, অথবা --protocol http2 ব্যবহার করে TCP path-কে বাধ্যতামূলক করুন।

শুরু করার আগে

• একটি ডোমেইন যা ইতিমধ্যে একটি Cloudflare অ্যাকাউন্টে আছে এবং Cloudflare-এর নেমসার্ভার দ্বারা পরিচালিত হচ্ছে। cloudflared tunnel route dns সেই জোনে রেকর্ড লেখে, তাই জোনটি আগে থেকেই থাকতে হবে।
• VPS থেকে পোর্ট 7844-এ আউটবাউন্ড অ্যাক্সেস, UDP এবং TCP উভয়ই।
• একটি অ্যাপ যা ইতিমধ্যে লোকালি লিসেন করছে, এমনকি প্রথম টেস্টের জন্য এটি যদি শুধুমাত্র python3 -m http.server 8080 হয় তবুও।
• বক্সে sudo ইনস্টল করা থাকতে হবে এবং ফায়ারওয়াল পরিবর্তন করার আগে একটি দ্বিতীয় SSH সেশন ওপেন রাখতে হবে।

Ubuntu বা Debian-এ cloudflared ইনস্টল করা

Cloudflare প্রতিটি .deb রিলিজের সাথে একটি cloudflared প্যাকেজ যুক্ত করে, তাই ইনস্টলেশন সম্পন্ন করতে একটি ডাউনলোড এবং একটি 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-এর ক্ষেত্রে ফাইলের নাম arm64-এ শেষ হয়, amd64-এ নয়; এছাড়া অন্য কোনো পরিবর্তন নেই। cloudflared --version কমান্ডটি ভার্সন স্ট্রিং দেখালে বুঝবেন পরবর্তী ধাপে যাওয়ার জন্য এটি প্রস্তুত।

এই পদ্ধতিতে ইনস্টল করা প্যাকেজটি apt-এর আপডেট পাথ-এর বাইরে থাকে, তাই apt-get upgrade কখনোই এটিকে আপডেট করবে না এবং এর আপডেট বজায় রাখার দায়িত্ব আপনার। sudo cloudflared update কমান্ডটি নতুন রিলিজ ডাউনলোড করে বর্তমান বাইনারিটিকে প্রতিস্থাপন করে; সার্ভিসটি তৈরি হয়ে গেলে, চলমান প্রসেসটি যেন নতুন বাইনারি ব্যবহার করে তা নিশ্চিত করতে sudo systemctl restart cloudflared চালান। আপনার অন্যান্য প্যাচিং শিডিউলের সাথেই এটি রাখুন, কারণ একটি টানেল ডেমোন ইন্টারনেট-মুখী সফটওয়্যার, যদিও এটি কোনো পোর্ট ওপেন করে না।

লগ ইন করুন এবং একটি named tunnel তৈরি করুন

cloudflared tunnel login

headless VPS-এ কোনো ব্রাউজার খোলে না, তাই প্রদর্শিত URL-টি কপি করে আপনার ল্যাপটপের ব্রাউজারে পেস্ট করুন এবং zone নির্বাচন করুন। প্রক্রিয়াটি শেষ হলে ~/.cloudflared/cert.pem তৈরি হবে।

cert.pem হলো আপনার account credential। এটি tunnel তৈরি করা, সেই zone-এ DNS রেকর্ড লেখা এবং tunnel মুছে ফেলার অনুমতি দেয়। চলমান tunnel এটি কখনোই ব্যবহার করে না। এটিকে পাসওয়ার্ডের মতো সুরক্ষিত রাখুন, কারণ এই ফাইলের একটি কপি থাকলেই যে কেউ আপনার ডোমেইনে নতুন 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 ফাইলটি হলো tunnel-এর পরিচয়, এবং চলমান সার্ভিসের জন্য এটিই একমাত্র প্রয়োজনীয় credential। যার কাছে এটি থাকবে, সে আপনার tunnel হিসেবে নিবন্ধিত হতে পারবে এবং আপনার ট্রাফিক গ্রহণ করতে পারবে। এটিকে আলাদাভাবে পরিবর্তন (rotate) করার কোনো উপায় নেই: এটি বাতিল করার অর্থ হলো cloudflared tunnel delete homelab এবং একটি নতুন tunnel তৈরি করা।

credentials ফাইলটি নিরাপদ কোনো স্থানে রাখুন

সার্ভিসটি root হিসেবে চলে, তাই ফাইলটিকে এমন কোনো ডিরেক্টরিতে রাখুন যার মালিক root। ফাইলটিকে কোনো home ডিরেক্টরিতে রাখবেন না, কারণ ব্যাকআপ জব বা শেয়ারড লগইন থেকে সেখানে অনাকাঙ্ক্ষিত অ্যাক্সেস হতে পারে।

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 কমান্ডটি JSON ফাইলে -rw------- root root প্রদর্শন করবে। cloudflared tunnel list কমান্ডটি cert.pem ফাইলটি পড়ে, তাই এটি কাজ চালিয়ে যায় এবং এটি টানেলের নাম, এর UUID এবং বর্তমানে কতগুলো সংযোগ সক্রিয় আছে তা প্রিন্ট করে।

সঠিক ingress রুলসহ config.yml তৈরি করুন

কনফিগারেশনটি আপনার হোম ডিরেক্টরিতে নয়, বরং /etc/cloudflared/config.yml-এ লিখুন। এর কারণ হলো, cloudflared service install সেখানে যে কনফিগারেশন পায় তা /etc/cloudflared/config.yml-এ কপি করে এবং তারপর --config /etc/cloudflared/config.yml-কে systemd unit-এর মধ্যে hard-code করে দেয়। আপনি যদি ~/.cloudflared/config.yml-এ ফাইলটি তৈরি করেন, তবে সেই কপিটি কেবল একবারের স্ন্যাপশট হিসেবে থেকে যায়। পরবর্তীতে হোম ডিরেক্টরির ফাইলে কোনো পরিবর্তন করলেও তা কার্যকর হয় না, সার্ভিসটি পুরনো রুল অনুযায়ীই চলতে থাকে এবং আপনি কোনো সতর্কবার্তাও পাবেন না। সরাসরি সঠিক স্থানে ফাইলটি তৈরি করলে এই সমস্যার সমাধান হয়ে যায়।

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

রুলগুলো উপর থেকে নিচে পড়া হয় এবং প্রথম যেটির সাথে মিলে যায় সেটিই কার্যকর হয়। কোনো hostname ছাড়া একটি রুল সব 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 রেসপন্স দেয় এবং অন্য কোনো কাজ করে না। এটি থাকা জরুরি: এটি ছাড়া, এমন কোনো hostname-এর অনুরোধ যা আপনি প্রকাশ করতে চাননি, তা শেষ রুলটিতে গিয়ে পড়ে।

service: URL-এ localhost-এর পরিবর্তে 127.0.0.1 ব্যবহার করুন। Ubuntu-তে localhost প্রথমে ::1-এ resolve হয় এবং শুধুমাত্র IPv4 loopback-এ bind করা কোনো অ্যাপ সেই সংযোগ প্রত্যাখ্যান করে। তখন লগ লাইনে dial tcp [::1]:8080: connect: connection refused দেখা যায় এবং ভিজিটর 502 এরর পায়।

এখানে সাধারণ http:// ব্যবহার করাই সঠিক, কারণ এই সংযোগটি মেশিন থেকে বাইরে যায় না। https:// কেবল তখনই ব্যবহার করুন যখন লোকাল অ্যাপটি TLS (transport layer security) দাবি করে, এবং যদি এর সার্টিফিকেট আপনার দেওয়া নামের সাথে না মেলে তবে x509: certificate is valid for example.com, not localhost এরর আশা করুন। originRequest-এর অধীনে originServerName ব্যবহার করে এটি ঠিক করুন, অথবা 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 নিয়ে সেটির সাথে মিলে যাওয়া প্রথম রুলটি প্রিন্ট করে, যা কোনো path regex আপনার প্রত্যাশা অনুযায়ী কাজ করছে কি না তা দ্রুত যাচাই করার সবচেয়ে সহজ উপায়।

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

প্রতিটি কল একটি proxied CNAME রেকর্ড তৈরি করে যা 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com-এর দিকে নির্দেশ করে। এই target শুধুমাত্র Cloudflare-এর নেটওয়ার্কের ভেতরেই resolve হয়, তাই আপনার hostname-এর জন্য পাবলিক DNS উত্তরটি একটি Cloudflare অ্যাড্রেস হয় এবং আপনার VPS IP কখনোই সেখানে দেখা যায় না। config.yml-এ থাকা একটি wildcard hostname-এর জন্য প্রতিটি নামের বিপরীতে একটি করে 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 রেকর্ড, যা আপনার VPS-এর পাবলিক IP-কে নির্দেশ করে; আর ঠিক এই রেকর্ডটিই আপনি মুছে ফেলতে চান। Cloudflare ড্যাশবোর্ডে গিয়ে এটি মুছে ফেলুন, তারপর কমান্ডটি পুনরায় চালান। এটি রেখে দিলে DNS আপনার origin IP প্রকাশ করতে থাকবে, ফলে টানেলটি কোনো কিছুই গোপন করতে পারবে না।

রিবুট-এর পরেও সচল রাখতে এটিকে একটি সার্ভিস হিসেবে ইনস্টল করুন

প্রথমে এটিকে একবার ফোরগ্রাউন্ডে (foreground) চালান, কারণ জার্নাল ফাইলের চেয়ে নিজের টার্মিনালে ভুলগুলো পড়া অনেক সহজ।

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

একটি সফল শুরুর পর বেশ কয়েকটি Registered tunnel connection লাইন লগ হিসেবে দেখা যাবে, যেখানে প্রতিটি এজ লোকেশনের জন্য আলাদা connIndex থাকবে। ব্রাউজারে আপনার হোস্টনেমগুলোর একটি লোড করুন এবং নিশ্চিত করুন যে ইনগ্রেস রুলগুলো আপনাকে প্রত্যাশিত গন্তব্যে পাঠাচ্ছে, এরপর 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 অংশটি গুরুত্বপূর্ণ, কারণ রিবুট-এর পর এটিই টানেলটিকে পুনরায় চালু করে। ইউনিটটির ExecStart হলো 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 মানে হলো একটি পুরনো ইউনিট এখনো রয়ে গেছে, তাই প্রথমে sudo cloudflared service uninstall রান করুন।

এখানে কোনো রিলোড অপশন নেই। /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

is-enabled এর মাধ্যমে enabled প্রিন্ট হওয়া এবং is-active এর মাধ্যমে active প্রিন্ট হওয়াই এই সেকশনের মূল উদ্দেশ্য। একবার রুটগুলো তৈরি হয়ে গেলে এবং সার্ভিসটি চলতে থাকলে, সার্ভারে cert.pem এর আর কোনো কাজ থাকে না: rm ~/.cloudflared/cert.pem। পরবর্তীতে নতুন কোনো হোস্টনেম যোগ করার অর্থ হলো শুধু পুনরায় cloudflared tunnel login রান করা।

80 এবং 443 পোর্ট বন্ধ করুন, অন্যথায় টানেলটি কেবল একটি অতিরিক্ত পথ হিসেবে থাকবে

দুটি পরিবর্তন প্রয়োজন এবং আপনার দুটিই করা জরুরি। একটি করলে অন্যটি বাদ পড়ে যাবে, ফলে অরিজিন সার্ভারটি বাইরে থেকে অ্যাক্সেসযোগ্য থেকে যাবে।

প্রথমত, অ্যাপটিকে লুপব্যাক অ্যাড্রেসে বাইন্ড করুন। Nginx-এর ক্ষেত্রে এর অর্থ হলো listen 80;-এর পরিবর্তে listen 127.0.0.1:8080; ব্যবহার করা, যা এই Nginx রিভার্স প্রক্সি কনফিগারেশন ব্যাখ্যায় বিস্তারিত দেখানো হয়েছে। Docker Compose-এর ক্ষেত্রে এর অর্থ হলো ports: - "127.0.0.1:8080:80"। সাধারণ "8080:80" ফরম্যাটটি প্রতিটি ইন্টারফেসে পোর্ট পাবলিশ করে এবং Docker নিজস্ব NAT (নেটওয়ার্ক অ্যাড্রেস ট্রান্সলেশন) রুল তৈরি করে যা ufw-এর আগেই প্যাকেট গ্রহণ করে, তাই 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

80 এবং 443 পোর্টের জন্য ডিনাই রুল যোগ না করে বরং আগের অ্যালাউ রুলগুলো মুছে ফেলুন, কারণ ufw প্রথম মিলে যাওয়া রুলটিতেই থেমে যায় এবং তালিকার উপরে থাকা পুরনো অ্যালাউ রুলটি কার্যকর হয়ে যায়। আপনার 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

র (raw) IP-এর বিপরীতে একটি রিফিউজড বা টাইম-আউট nc এবং হোস্টনেমের মাধ্যমে একটি 200 রেসপন্স পাওয়া হলো আপনার কাঙ্ক্ষিত ফলাফল। একটি পোর্ট সত্যিই খোলা আছে কি না তা যাচাই করা-তে এটি পরীক্ষা করার আরও উপায় রয়েছে।

টানেল হলো পরিবহনের মাধ্যম, প্রমাণীকরণের (authentication) নয়। আপনি এর মাধ্যমে যা কিছু পাবলিশ করবেন তা সবার জন্য উন্মুক্ত থাকবে, যদি না আপনি সামনে কোনো লগইন ব্যবস্থা রাখেন, যেমন এজ-এ Cloudflare Access অথবা সার্ভারে অ্যাপের সামনে একটি OAuth2 প্রক্সি। SSH-এর জন্যও আলাদা ব্যবস্থা প্রয়োজন, কারণ টানেল এটি কভার করে না: 22 নম্বর পোর্ট খোলা রাখুন তবে তা কেবল আপনার নিজস্ব সোর্স অ্যাড্রেসের জন্য সীমাবদ্ধ রাখুন।

Cloudflare Tunnel ব্যবহারের সুবিধা এবং এর সীমাবদ্ধতা

আপনি যা পাচ্ছেন তা বাস্তব। আপনার অরিজিন IP আর প্রকাশিত থাকে না, কোনো inbound port খোলা রাখতে হয় না, এবং কোনো public IP নেই এমন মেশিন থেকেও এই সেটআপ কাজ করে। পাবলিক সার্টিফিকেট ব্যবস্থাপনার দায়িত্ব Cloudflare-এর, তাই আপনার বক্সে কোনো ACME (automatic certificate management environment) ক্লায়েন্ট চালানোর প্রয়োজন নেই। এছাড়া, ভলিউমেট্রিক আক্রমণগুলো আপনার ব্যান্ডউইথ ব্যবহারের ওপর প্রভাব ফেলার আগেই Cloudflare-এর এজ (edge) নেটওয়ার্কে আটকে যায়।

এর সীমাবদ্ধতাগুলোও সমানভাবে বাস্তব। Cloudflare তাদের এজে TLS টার্মিনেট করে: আপনার ভিজিটরের অনুরোধ সেখানে ডিক্রিপ্ট হয় এবং টানেলের ভেতর দিয়ে পুনরায় এনক্রিপ্ট হয়ে আপনার কাছে আসে, অর্থাৎ Cloudflare আপনার ট্রাফিক পড়তে পারে। এই প্রক্রিয়ার মাধ্যমেই তাদের ফায়ারওয়াল, ক্যাশিং এবং Access রুলগুলো কাজ করে, এবং তাদের প্রক্সি ব্যবহার করলে এই সুবিধা বন্ধ করার কোনো উপায় নেই। যদি কোনো তৃতীয় পক্ষের কাছে আপনার ডেটা প্লেইনটেক্সট আকারে থাকা গ্রহণযোগ্য না হয়, তবে এখানেই থামুন এবং অন্য কোনো বিকল্প বেছে নিন।

এছাড়া, আপনার সার্ভারের রিচেবিলিটির জন্য Cloudflare একটি কঠোর নির্ভরতায় পরিণত হয়। যখন cloudflared সংযুক্ত থাকে না, তখন ভিজিটররা আপনার অ্যাপের পরিবর্তে Cloudflare-এর Error 1033 পেজ দেখতে পায়, এবং আপনি সরাসরি যোগাযোগের সেই পথটি আগেই বন্ধ করে দিয়েছেন যা ব্যাকআপ হিসেবে কাজ করতে পারত।

সাধারণ ব্রাউজার থেকে শুধুমাত্র HTTP, HTTPS এবং WebSocket প্রোটোকল ব্যবহার করে পাবলিক হোস্টনামে পৌঁছানো যায়। অন্য যেকোনো TCP প্রোটোকল, যেমন SSH, RDP (remote desktop protocol) বা গেম সার্ভারের জন্য ক্লায়েন্ট সাইডেও সফটওয়্যার প্রয়োজন: cloudflared access tcp ব্যবহার করে লোকাল পোর্ট ফরওয়ার্ডিং অথবা WARP ক্লায়েন্ট ব্যবহার করতে হবে। এগুলোর জন্য ক্লায়েন্ট-মুক্ত কোনো পথ নেই।

এজ লেভেলে রিকোয়েস্ট বডির আকার সীমাবদ্ধ থাকে এবং সীমার চেয়ে বড় কোনো আপলোড আপনার অ্যাপে পৌঁছানোর আগেই HTTP 413 এরর দিয়ে প্রত্যাখ্যান করা হয়। আগস্ট 2026 অনুযায়ী, ফ্রি এবং Pro প্ল্যানে এই সীমা 100 MB এবং পেইড টায়ারগুলোতে এর চেয়ে বেশি। তাই কোনো নির্দিষ্ট সংখ্যার ওপর ভিত্তি করে ডিজাইন করার আগে Cloudflare-এর বর্তমান লিমিট পেজটি দেখে নিন। Cloudflare-এর সেলফ-সার্ভ টার্মস অনুযায়ী, প্রক্সি ব্যবহার করে মূলত ভিডিও বা বড় আকারের নন-HTML ফাইল সার্ভ করা সীমাবদ্ধ। তাই কোনো মিডিয়া লাইব্রেরিকে ফ্রি টানেলের সাথে যুক্ত করার আগে তাদের শর্তাবলী পড়ে নেওয়া জরুরি।

Cloudflare Tunnel, reverse SSH tunnel, অথবা Tailscale Funnel

এই তিনটি পদ্ধতিই শুধুমাত্র outbound-only, তাই কোনো inbound port বা public IP নেই এমন সার্ভারেও এগুলো কাজ করে। এদের মধ্যে পার্থক্য হলো আপনার plaintext ডেটা কার কাছে থাকে এবং পাবলিক ইউজাররা কোন hostname দেখতে পায় তার ওপর।

একটি reverse SSH tunnel-এর জন্য এমন একটি দ্বিতীয় মেশিনের প্রয়োজন হয় যার public IP আছে, এবং সেই মেশিনটিই তখন মূল প্রবেশদ্বার হিসেবে কাজ করে: এর certificate, reverse proxy এবং firewall সম্পূর্ণ আপনার নিয়ন্ত্রণে থাকে। অন্য কেউ কোনো কিছু decrypt করে না। এতে অনেকগুলো অংশ জড়িত থাকে এবং নেটওয়ার্ক বিচ্ছিন্ন হলে তা সচল রাখতে autossh অথবা Restart=always সহ একটি systemd unit প্রয়োজন হয়। CGNAT-এর জন্য reverse SSH tunnel-এর নির্দেশিকা এই সেটআপটি বিস্তারিত আলোচনা করে।

Tailscale Funnel হলো এর সবচেয়ে কাছাকাছি বিকল্প। এটিও একইভাবে শুধুমাত্র outbound-only এবং TLS আপনার নিজের মেশিনে terminate হয়, তাই Tailscale-এর relay-গুলো কখনোই plaintext দেখতে পায় না। এর সীমাবদ্ধতা হলো naming এবং port: Funnel শুধুমাত্র আপনার tailnet-এর ts.net ডোমেইনের অধীনে এবং শুধুমাত্র 443, 8443 ও 10000 পোর্টে কাজ করে। Tailscale Serve এবং Funnel-এর পার্থক্য এই বিষয়টি বিস্তারিত ব্যাখ্যা করে।

তাই আপনার জন্য যে সীমাবদ্ধতাটি সবচেয়ে গুরুত্বপূর্ণ, সেটি বিবেচনা করে পদ্ধতি নির্বাচন করুন। যখন পাবলিক ইউজারদের আপনার নিজস্ব ডোমেইনে পৌঁছাতে হবে এবং আপনি মেনে নেবেন যে Cloudflare ট্রাফিক পড়তে পারে, তখন Cloudflare Tunnel বেছে নিন। যখন একটি ts.net hostname গ্রহণযোগ্য এবং কোনো proxy-র কাছে plaintext দেওয়া আপনার জন্য নিরাপদ নয়, তখন Tailscale Funnel বেছে নিন। আর যখন আপনার নিজের একটি public সার্ভার আছে এবং আপনি চান না যে ট্রাফিক পথে কোনো তৃতীয় পক্ষ থাকুক, তখন reverse SSH tunnel বেছে নিন।

FAQ

Cloudflare Tunnel ব্যবহার করলে কি আমার 443 (443) পোর্ট খোলা রাখা প্রয়োজন?

না। cloudflared পোর্ট 7844 (7844) ব্যবহার করে বাইরের দিকে Cloudflare-এর সাথে সংযোগ স্থাপন করে এবং প্রতিটি অনুরোধ সেই সংযোগের মাধ্যমেই ফিরে আসে, তাই কোনো ইনবাউন্ড পোর্ট ব্যবহারের প্রয়োজন হয় না। তবে, টানেল ইনস্টল করলেই আপনার আগের পোর্টগুলো স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায় না। তাই ufw-তে 80 (80) এবং 443 (443) পোর্টের জন্য থাকা allow রুলগুলো মুছে ফেলুন, আপনার প্রোভাইডারের নেটওয়ার্ক ফায়ারওয়ালে সেগুলো বন্ধ করুন, অ্যাপটিকে 127.0.0.1-এ বাইন্ড করুন এবং আপনার VPS IP প্রকাশ করে এমন কোনো অবশিষ্ট A রেকর্ড থাকলে তা মুছে ফেলুন। সার্ভারে sudo ss -lntp এবং অন্য কোনো মেশিন থেকে nc -vz <your-ip> 443 চালিয়ে বিষয়টি নিশ্চিত করুন।

আমার হোস্টনামে কেন Cloudflare Error 1033 দেখাচ্ছে?

Error 1033 মানে হলো Cloudflare ওই হোস্টনামের জন্য DNS রেকর্ডটি ধরে রেখেছে, কিন্তু অনুরোধ গ্রহণ করার মতো কোনো সচল cloudflared খুঁজে পাচ্ছে না। হয় প্রসেসটি বন্ধ আছে, অথবা এটি চলছে কিন্তু Cloudflare-এর সাথে যোগাযোগ করতে পারছে না। systemctl status cloudflared এবং journalctl -u cloudflared -n 50 চেক করুন, তারপর নিশ্চিত করুন যে আউটবাউন্ড পোর্ট 7844 (7844)-এ UDP এবং TCP উভয়ই অনুমোদিত। কারণ যে ফায়ারওয়াল UDP এবং QUIC ব্লক করে কিন্তু TCP ফলব্যাক অনুমোদন করে না, সেটিই এই ত্রুটি তৈরি করে। cloudflared tunnel info homelab বর্তমানে Cloudflare যে সংযোগগুলো দেখতে পাচ্ছে তা প্রদর্শন করে; যদি তালিকাটি খালি থাকে, তবে সমস্যাটি আপনার দিকেই।

টানেলের মাধ্যমে আমি কেন 502 Bad Gateway পাচ্ছি?

502 মানে হলো cloudflared পর্যন্ত পৌঁছানো গেছে কিন্তু সেটি আপনার লোকাল সার্ভিসের সাথে যোগাযোগ করতে পারছে না, তাই সমস্যাটি Cloudflare-এ নয়, বরং এই দুটির মাঝখানে রয়েছে। লগ ফাইল পড়ুন। dial tcp [::1]:8080: connect: connection refused মানে হলো আপনি যেখানে সার্ভিসটি থাকার কথা বলেছেন সেখানে কেউ লিসেন করছে না। ওই মেসেজে থাকা [::1] সাধারণত নির্দেশ করে যে আপনি service: URL-এ localhost লিখেছেন, অথচ অ্যাপটি শুধুমাত্র IPv4-এ বাইন্ড করা; তাই এর পরিবর্তে http://127.0.0.1:8080 লিখুন। HTTP/1.x transport connection broken: malformed HTTP response হলো বিপরীত অমিল: আপনি এমন একটি অরিজিনে https:// লিখেছেন যা সাধারণ HTTP-তে কথা বলে।

আমি কি Cloudflare Tunnel দিয়ে SSH, RDP বা গেম সার্ভার চালাতে পারি?

সাধারণ ক্লায়েন্ট থেকে এটি সম্ভব নয়। টানেলের মাধ্যমে একটি পাবলিক হোস্টনাম HTTP, HTTPS এবং WebSocket বহন করে, যা ব্রাউজার বুঝতে পারে। অন্য যেকোনো TCP প্রোটোকলের জন্য ক্লায়েন্ট মেশিনেও সফটওয়্যার প্রয়োজন, হয় cloudflared access tcp ব্যবহার করে লোকাল পোর্ট ফরওয়ার্ড করতে হবে অথবা WARP ক্লায়েন্ট ব্যবহার করতে হবে। যদি আপনি কোনো কিছু ইনস্টল না করেই যেকোনো মেশিন থেকে SSH করতে চান, তবে টানেল এর জন্য সঠিক টুল নয়। পোর্ট 22 (22) খোলা রাখুন এবং সোর্স অ্যাড্রেস দিয়ে তা সীমাবদ্ধ করে দিন।

টানেলের মাধ্যমে আমার ট্রাফিক কি Cloudflare দেখতে পায়?

হ্যাঁ। Cloudflare তাদের এজে (edge) TLS টার্মিনেট করে, সেখানে অনুরোধটি ডিক্রিপ্ট করে এবং আপনার সার্ভারের দিকে টানেলের ভেতর দিয়ে পুনরায় এনক্রিপ্ট করে পাঠায়। এই ডিক্রিপশন প্রক্রিয়ার কারণেই তাদের ফায়ারওয়াল, ক্যাশিং এবং অ্যাক্সেস পলিসিগুলো কাজ করে। এর মানে হলো আপনার প্লেইনটেক্সট ডেটা তাদের মেশিনে থাকে। আপনি তাদের প্রক্সি ব্যবহার করলে কোনো কনফিগারেশন দিয়েই এটি এড়ানো সম্ভব নয়। যদি এটি আপনার জন্য গ্রহণযোগ্য না হয়, তবে Tailscale Funnel ব্যবহার করুন অথবা পাবলিক বক্সে নিজের রিভার্স প্রক্সি চালান।