VPS-এ obfs4 Tor bridge চালানোর সম্পূর্ণ নির্দেশিকা

Tor bridge কী এবং কেন এটি ব্যবহৃত হয়

Tor bridge হলো Tor network-এ প্রবেশের একটি point, যার address public relay list-এ প্রকাশ করা হয় না। এই list-কে consensus বলা হয়। এটি একটি signed document, যা যে কেউ download করতে পারে এবং censor-ও তা download করে। এটি থেকে Tor block করতে বেশি সময় লাগে না: consensus সংগ্রহ করে border-এ থাকা প্রতিটি address drop করলেই হয়। Published list-ই দুর্বল স্থান, তাই bridge ব্যবহৃত হয়। Bridge address একবারে অল্প কয়েকটি করে দেওয়া হয়। ফলে কোনো single request-এ সম্পূর্ণ list পাওয়া যায় না।

তালিকাভুক্ত নয় এমন address সমাধানের কেবল অর্ধেক। Deep packet inspection (DPI) address-এর পরিবর্তে content বিশ্লেষণ করে traffic শ্রেণিবদ্ধ করে। এটি TLS (transport layer security) handshake-এর ধরন দেখে Tor connection শনাক্ত করতে পারে। কোনো censor-এর কাছে address list না থাকলেও সে বুঝতে পারে, “এটি Tor-এর মতো দেখাচ্ছে” এবং connection drop করতে পারে। Pluggable transport এই সংকেত সরিয়ে দেয়। এটি client side-এ Tor stream-কে অন্য কিছুর মধ্যে wrap করে, আর আপনার bridge সেটি unwrap করে।

obfs4 হলো অধিকাংশ bridge-এ চালানো transport। এটি stream-কে header-বিহীন এবং fixed handshake-বিহীন bytes-এ রূপান্তর করে। ফলে DPI মেলানোর মতো কোনো pattern পায় না। এটি client-কে authenticate-ও করে। Bridge line-এর মধ্যে থাকা cert= value হলো এমন একটি key, যার possession client-কে প্রমাণ করতে হয়; তারপরই bridge কোনো উত্তর দেয়। এতে active probing প্রতিহত হয়। কোনো censor আপনার address-এ connection করে এটি Tor কি না পরীক্ষা করলেও কোনো reply পায় না এবং কিছু জানতে পারে না।

কোন pluggable transport চালাবেন?

• obfs4 চালাতে 1টি VPS, 2টি TCP port এবং কোনো domain name প্রয়োজন হয় না। এটি চালানোর জন্য সবচেয়ে সহজ এবং কার্যকর বিকল্প, এবং এই guide-এ এটি নিয়েই আলোচনা করা হয়েছে।
• WebTunnel সংযোগকে একটি আসল website-এ পাঠানো সাধারণ HTTPS traffic-এর ভেতরে গোপন রাখে। Tor Project-এর তালিকাভুক্ত requirements হলো একটি static IPv4 address, আপনার নিয়ন্ত্রণাধীন একটি domain, NGINX বা Apache-এর মতো সচল web server, একটি বৈধ TLS certificate, এবং কমপক্ষে 1 GB RAM; 4 GB সুপারিশ করা হয়। যেসব network-এ এলোমেলো-দেখানো traffic নিজেই সন্দেহজনক, সেখানে এটি উপযোগী। কারণ web browsing ছাড়া খুব কম কিছু অনুমোদিত হলেও HTTPS সাধারণত অনুমোদিত থাকে।
• Snowflake ভিন্ন ধরনের contribution। Volunteers স্বল্পস্থায়ী WebRTC proxy চালান। ফলে entry point নিয়মিত পরিবর্তিত হয় এবং censor-এর block করার মতো কোনো স্থিতিশীল address থাকে না। এর জন্য আপনি bridge পরিচালনা করেন না। আপনি একটি proxy চালান, যার কোনো fixed address প্রয়োজন হয় না।

obfs4 দিয়ে শুরু করুন। পরে দ্বিতীয় address-এ একটি WebTunnel bridge যোগ করতে পারেন। একই IP-তে দুটিই চালালে একটি address block হলেই উভয় service বন্ধ হয়ে যাবে।

একটি bridge চালানোর খরচ কী?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

August 2026 অনুযায়ী, Tor Project একটি bridge-এর জন্য অন্তত 1 Mbit/s upstream এবং downstream bandwidth চায়। একটি guard বা middle relay-এর জন্য 10 Mbit/s চাওয়া হয় এবং 16 Mbit/s সুপারিশ করা হয়। এগুলো প্রকাশিত requirement, পরিমাপ করা মান নয়। নতুন bridge সাধারণত কয়েক সপ্তাহ নিজের minimum-এর অনেক নিচে থাকে। একই requirements page একটি relay-এর জন্য প্রতি মাসে অন্তত 100 GByte outbound traffic চায়। সবচেয়ে ছোট plan-গুলোতেই এই পরিমাণ সাধারণত পূরণ হয়। তাই বড় আকারের plan নেওয়ার আগে ছোট VPS-এর প্রকৃত মাসিক খরচ কত দেখুন।

abuse-এর ঝুঁকির ক্ষেত্র সীমিত। এই বিষয়টিই অনেকে ভুল বোঝেন। একটি bridge হলো প্রথম hop। আপনার server থেকে বের হওয়া traffic অন্য একটি Tor relay-এ যায়, ব্যবহারকারী যে website বেছে নিয়েছেন সেখানে সরাসরি যায় না। কোনো অনুরোধের source হিসেবে আপনার IP address অপরিচিত কারও web log-এ দেখা যায় না। তাই exit relay operator-রা যে complaint mail সামলান, তা আপনার server-এ আসে না। তবু provider-এর acceptable use policy পরীক্ষা করুন, কারণ কিছু host যেকোনো Tor service-কে বিশেষ case হিসেবে বিবেচনা করে।

একটি কাজ করবেন না: একই address-এ থাকা একটি বিদ্যমান public relay-কে bridge-এ রূপান্তর করবেন না। এই ক্ষেত্রে Tor Project-এর পরামর্শ হলো "IP address, name and fingerprint" পরিবর্তন করা। কারণ পুরোনো address ইতিমধ্যে সেই consensus-এ আছে, যেখান থেকে censor bridge-এর তথ্য download করে। গত সপ্তাহে public relay থাকা একটি bridge ইতিমধ্যে blocklist-এ থাকতে পারে।

Speed-এর চেয়ে uptime বেশি গুরুত্বপূর্ণ। relay requirements-এ বলা হয়েছে, "if your relay is not running for more than 2 hours a day its usefulness is limited"। এই ক্ষেত্রে bridge relay-এর চেয়ে বেশি অসুবিধায় থাকে, কারণ প্রতিটি client-এর একটি মাত্র address থাকে এবং কোনো fallback থাকে না। restart হলে bridge-এ থাকা প্রতিটি user-এর সংযোগ বিচ্ছিন্ন হয়। obfs4 port-এর জন্য Uptime Kuma-তে একটি TCP port check সেট আপ করুন, যাতে এটি যেদিন আর response না দেয় সেদিনই জানতে পারেন।

Tor Project repository থেকে Tor ইনস্টল করুন

Distribution-এর package প্রায়ই পুরোনো থাকে, কিন্তু bridge একটি security software এবং এটি বর্তমান সংস্করণে থাকা উচিত। প্রথমে project-এর নিজস্ব repository যোগ করুন।

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

এখন source file লিখুন। Suites: লাইনে আপনার release codename থাকতে হবে। তাই এটি মনে থেকে টাইপ না করে system থেকে পড়ুন।

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

যদি apt update জানায় যে আপনার codename-এর জন্য repository-তে কোনো Release file নেই, তাহলে /etc/apt/sources.list.d/tor.sources মুছে দিন, আবার sudo apt update চালান এবং আপনার distribution-এর সরবরাহ করা tor package ইনস্টল করুন। নিচের সবকিছু একই থাকবে।

obfs4proxy package Debian এবং Ubuntu নিজেরাই সরবরাহ করে (August 2026 অনুযায়ী Debian 13-এ version 0.0.14)। binary কোথায় ইনস্টল হয়েছে তা নিশ্চিত করুন, কারণ এর path config-এ দিতে হবে:

command -v obfs4proxy || command -v lyrebird

Upstream project-এর নাম lyrebird করেছে, তাই নতুন package-এর ক্ষেত্রে এর পরিবর্তে /usr/bin/lyrebird ইনস্টল হতে পারে। ওই command যে path দেখায়, সেটিই ব্যবহার করুন।

/etc/tor/torrc-এ bridge কনফিগার করুন

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

এই প্রতিটি লাইনের সঙ্গে একটি নির্দিষ্ট ব্যর্থতার কারণ জড়িত। তাই একবারে একটি করে পরীক্ষা করুন।

BridgeRelay 1 tor-কে public consensus-এর বদলে bridge authority-তে নিজের descriptor পাঠাতে বলে। এই একটিমাত্র লাইন relay-টিকে তালিকাভুক্ত না রাখে।

ORPort হলো প্রকৃত Tor port। এটি Internet থেকে পৌঁছানো সম্ভব হতে হবে, কারণ tor port-টি পরীক্ষা করে। সেই পরীক্ষা সফল না হওয়া পর্যন্ত tor descriptor প্রকাশ করতে অস্বীকার করে।

ServerTransportPlugin tor-কে কোন command চালাতে হবে তা জানায়। tor একটি child process হিসেবে obfs4proxy চালায় এবং একটি pipe-এর মাধ্যমে এর সঙ্গে যোগাযোগ করে। তাই obfs4proxy-এর নিজস্ব কোনো service unit থাকে না এবং এটি systemctl status-এ কখনো দেখা যায় না।

ServerTransportListenAddr obfs4proxy যে port-এ listening করবে, সেটি নির্দিষ্ট করে। এই লাইনটি বাদ দিলে obfs4proxy startup-এর সময় একটি free port বেছে নেয়। অধিকাংশ restart-এর পরে port বদলে যায়। ফলে আগে বিতরণ করা প্রতিটি bridge line এমন একটি port নির্দেশ করে, যেখানে কোনো process listening করছে না। ওই client-গুলো connection refused পায় এবং চেষ্টা করা বন্ধ করে।

ExtORPort auto extended ORPort চালু করে। এটি একটি loopback channel, যার মাধ্যমে obfs4proxy সম্পন্ন connection-গুলো client-এর address-সহ tor-এর কাছে ফেরত পাঠায়। Tor Project-এর setup guide প্রতিটি bridge-এ এই নির্দেশনা অন্তর্ভুক্ত করে। এটি না থাকলে transport client-এর address tor-কে জানাতে পারে না।

ContactInfo এবং Nickname উভয়ই public। এমন একটি address ব্যবহার করুন, যেটি আপনি নিয়মিত পড়বেন। কোনো bridge-এ সমস্যা হলে Tor Project এই address-এর মাধ্যমে আপনার সঙ্গে যোগাযোগ করবে। আপনি যদি পরিচয় গোপন রাখতে চান, তাহলে এমন একটি nickname বেছে নিন, যা আপনাকে শনাক্ত করে না।

BridgeDistribution নির্ধারণ করে কোন distributor users-দের কাছে আপনার address পৌঁছে দেবে। গ্রহণযোগ্য মানগুলো হলো https, email, telegram, settings, none এবং any। প্রথম bridge-এর জন্য any ব্যবহার করুন এবং system-কে সিদ্ধান্ত নিতে দিন। নিজে বিতরণ করা private bridge-এর জন্য none ব্যবহার করুন। এতে address-টি সম্পূর্ণভাবে public distribution-এর বাইরে থাকে।

পোর্ট বেছে নেওয়া গুরুত্বপূর্ণ কেন

দুটি পোর্টের জন্যই 9001 ব্যবহার করবেন না। Tor Project সরাসরি এ বিষয়ে সতর্ক করেছে, কারণ 9001 প্রচলিত ORPort এবং সেন্সররা এই পোর্টের জন্য Internet স্ক্যান করে। দুটি পোর্ট একে অপরের থেকেও আলাদা হতে হবে, কারণ tor এবং obfs4proxy প্রত্যেকে নিজস্ব listener-এ bind করে।

obfs4-এর জন্য সবচেয়ে শক্তিশালী পোর্ট হলো 443। প্রায় সব restricted network-এ outbound 443 খোলা থাকে, এবং এই পোর্টে দীর্ঘস্থায়ী connection সাধারণ web session-এর মতো দেখায়। 1024-এর নিচের পোর্টে bind করতে একটি অতিরিক্ত ধাপ প্রয়োজন, কারণ obfs4proxy root হিসেবে চলে না:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

প্রতিটি editor-এ এই দুটি line যোগ করুন:

[Service]
NoNewPrivileges=no

শুধু capability যোগ করলেই যথেষ্ট নয়। systemd-এর NoNewPrivileges কোনো process-কে তার parent-এর আগে থেকে থাকা privilege-এর চেয়ে বেশি privilege অর্জন করতে বাধা দেয়। File capability ঠিক এই ধরনের privilege। তাই এই setting চালু থাকলে obfs4proxy 443-এ bind করতে ব্যর্থ হয়।

আপনি যদি এই ধাপটি এড়াতে চান, তাহলে সাধারণ একটি high port বেছে নিয়ে তা লিখে রাখুন। যেটিই বেছে নিন, পরে obfs4-এর port পরিবর্তন করবেন না। একটি bridge line address, port, fingerprint এবং certificate একসঙ্গে নির্দিষ্ট করে। তাই কোনো ব্যবহারকারীর browser-এ আগে থেকেই থাকা প্রতিটি copy port পরিবর্তনের সঙ্গে সঙ্গে অকার্যকর হয়ে যাবে।

উভয় firewall-এ port খুলুন

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

উভয় port খোলা থাকতে হবে। অধিকাংশ provider control panel-এ একটি দ্বিতীয় firewall চালায়, যেটি ufw সম্পর্কে কিছুই জানে না। সার্ভারে থাকা কিন্তু panel-এ না থাকা rule এমন একটি bridge তৈরি করে, যেটিতে কখনো পৌঁছানো যায় না এবং যেটি কখনো descriptor publish করে না। এর কোনো অংশ নতুন হলে নতুন VPS-এর জন্য প্রয়োজনীয় ufw rules এবং Linux-এ listening port আসলে কী বিষয়ক নির্দেশনা দেখুন। একই সময়ে key এবং শক্তিশালী sshd config ব্যবহার করে SSH সুরক্ষিত করুন। password SSH-যুক্ত সার্ভারে তালিকাভুক্ত নয় এমন bridge থাকলেও সেটি password SSH-যুক্ত সার্ভারই থাকে।

এটি চালু করুন, তারপর লগ পড়ুন

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian এবং Ubuntu দুটি unit সরবরাহ করে। tor.service একটি ছোট wrapper, আর tor@default.service কাজটি সম্পাদনকারী process। তাই journalctl -u tor প্রায় খালি দেখায়, কিন্তু আপনার প্রয়োজনীয় লগ tor@default-এর অধীনে থাকে।

দুটি লাইন দেখায় যে এটি সফল হয়েছে:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

প্রথমটির অর্থ, reachability test সফল হয়েছে এবং descriptor bridge authority-এর কাছে পাঠানো হয়েছে। এটি কখনও দেখা না গেলে Internet এবং আপনার server-এর মাঝের কোনো উপাদান ORPort-এ network traffic আটকে দিচ্ছে। দ্বিতীয় লাইনে আপনার configure করা port দেখাতে হবে। সেখানে ভিন্ন port দেখা গেলে tor ServerTransportListenAddr প্রয়োগ করেনি। এর সাধারণ কারণ হলো transport name না মেলা: উভয় directive-এই এটি obfs4 হতে হবে।

দুটি listener চালু আছে কি না নিশ্চিত করুন:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

আমার bridge line কোথায়?

obfs4proxy, tor-এর data directory-তে একটি template লেখে:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

এই directory-টির মালিক tor user এবং এর mode 700। তাই sudo ছাড়া Permission denied দেখা যায়। ফাইলটিতে এই গঠনের একটি line থাকে:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

<IP ADDRESS>-এর জায়গায় আপনার server-এর public address, <PORT>-এর জায়গায় ORPort নয়, obfs4 port, এবং <FINGERPRINT>-এর জায়গায় tor তার data directory-তে লেখা identity fingerprint বসান:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

প্রথম ফাইলটিতে আপনার nickname এবং bridge line-এ ব্যবহারের জন্য প্রয়োজনীয় identity fingerprint থাকে। দ্বিতীয় ফাইলটিতে hashed fingerprint থাকে। আপনার bridge চালু আছে কি না এবং আনুমানিক কতজন client এতে পৌঁছাচ্ছে তা দেখতে এই মানটি Relay Search-এ paste করুন। দুটি মান পরস্পরের বিকল্প নয়। hashed value-সহ একটি bridge line আপনার bridge যে identity key উপস্থাপন করে, তার সঙ্গে মেলে না। ফলে client সদ্য খোলা connection প্রত্যাখ্যান করে।

ব্রিজ ব্যবহারকারীদের কাছে কীভাবে পৌঁছায়?

আপনি আপনার bridge line কাউকে সরাসরি দেন না। descriptor bridge authority-তে পৌঁছানোর পরে distribution system (rdsys, যা BridgeDB-এর উত্তরসূরি) আপনার bridge-কে একজন distributor-এর কাছে বরাদ্দ করে। ব্যবহারকারীরা সেই distributor-এর কাছে bridge চায়। August 2026 অনুযায়ী ব্যবহৃত পথগুলো হলো:

• bridges.torproject.org/options-এর web form, যা captcha যাচাইয়ের পরে bridge line দেয়।
• Gmail বা Riseup address থেকে bridges@torproject.org-এ email পাঠানো। এর জবাবে bridge line পাঠানো হয়। এই provider restriction রাখা হয়েছে, কারণ সীমাহীন free account থাকলে একজন censor প্রতিটি bridge-এর তালিকা তৈরি করতে পারত।
• Telegram bot @GetBridgesBot। /start পাঠানোর পরে /obfs4 অথবা /webtunnel পাঠান।
• Tor Browser-এর Settings, তারপর Connection বিভাগ। সেখানে "Request bridges" নির্বাচন করলে moat channel-এর মাধ্যমে bridge আনা হয়।

সেটআপের প্রায় তিন ঘণ্টা পরে নতুন bridge Relay Search-এ দেখা যায়। ব্যবহারকারী পেতে আরও বেশি সময় লাগে। Tor Project-এর ভাষায়, "ব্যবহারকারীদের একটি স্থিতিশীল সেট দেখতে কয়েক দিন বা কয়েক সপ্তাহ সময় লাগতে পারে।" প্রথম দুই সপ্তাহে ব্যবহারকারী না থাকাটা স্বাভাবিক। এটি কোনো ত্রুটি নয়।

BridgeDistribution none সেট করলে এই সব বিতরণ ব্যবস্থা থেকে opt out করা হয়। এরপর bridge line যাদের প্রয়োজন, তাদের কাছে আপনি নিজেই পাঠাতে পারবেন—এমন একটি channel ব্যবহার করে, যা censor monitor করছে না।

কোনো কিছু কাজ না করলে

লগে self-testing line নেই। ORPort-এ পৌঁছানো যাচ্ছে না। অন্য একটি মেশিন থেকে nc -vz your.ip 8443 দিয়ে পরীক্ষা করুন। সংযোগ স্থির হয়ে থাকলে বুঝবেন packet drop হচ্ছে; তাই ufw এবং provider-এর panel পরীক্ষা করুন। সংযোগ প্রত্যাখ্যাত হলে বুঝবেন tor listen করছে না; তাই ss -lntp পরীক্ষা করুন এবং configuration error-এর জন্য log দেখুন।

registered transport-এ এমন একটি port দেখা যাচ্ছে, যা আপনি নির্ধারণ করেননি। tor ServerTransportListenAddr উপেক্ষা করেছে। Transport name-টি ServerTransportPlugin-এ থাকা নামের সঙ্গে হুবহু মিলতে হবে এবং দুটিই obfs4 হতে হবে।

obfs4proxy port 443-এ bind করতে পারছে না। getcap /usr/bin/obfs4proxy দিয়ে capability নিশ্চিত করুন। এরপর systemctl show tor@default -p NoNewPrivileges দিয়ে override-টি unit-এ পৌঁছেছে কি না নিশ্চিত করুন। সেখানে NoNewPrivileges=yes দেখা গেলে বুঝবেন আপনার drop-in এমন একটি unit-এ গেছে, যা চলছে না।

/var/lib/tor/pt_state/-এর ভিতরে কিছু নেই। tor transport শুরু করেনি। এর অর্থ ServerTransportPlugin-এ দেওয়া path ভুল। command -v obfs4proxy-এর output-এর সঙ্গে এটি তুলনা করুন।

পরিবর্তনের পরে client-গুলো সংযোগ করা বন্ধ করেছে। address বা obfs4 port-এ যেকোনো পরিবর্তন আগে বিতরণ করা সব bridge line অকার্যকর করে দেয়। server-এর public IP-ও পরিবর্তিত হয়েছে কি না পরীক্ষা করুন। কিছু provider-এর ক্ষেত্রে rebuild করলে এমনটি ঘটে।

tor একেবারেই start হচ্ছে না। sudo -u debian-tor tor --verify-config -f /etc/tor/torrc চালান। এটি file parse করে, যে line-এ সমস্যা পেয়েছে তা দেখায় এবং চলমান service অপরিবর্তিত রাখে।

FAQ

আমার VPS provider কি Tor bridge চালানোর জন্য আপত্তি জানাবে?

Bridge একটি entry point। তাই আপনার সার্ভার থেকে বের হওয়া traffic অন্য Tor relay-এ যায়, ব্যবহারকারী নির্বাচিত কোনো site-এ সরাসরি যায় না। কোনো request-এর source হিসেবে আপনার IP address কারও web log-এ দেখা যায় না। Exit relay operator-দের বিরুদ্ধে যে অভিযোগ তৈরি হয়, তার কারণ সেটিই। Hosting rules provider ভেদে আলাদা হতে পারে। কিছু provider যেকোনো Tor service-কে বিশেষ ক্ষেত্রে বিবেচনা করে। তাই শুরু করার আগে acceptable use policy পড়ুন এবং পড়া address-টি ContactInfo-এ দিন।

Tor bridge কত bandwidth ব্যবহার করে?

প্রকাশিত minimum হলো upstream ও downstream উভয় দিকেই 1 Mbit/s। Guard বা middle relay-এর ক্ষেত্রে এই মান 10 Mbit/s। বাস্তবে ব্যবহার প্রায় শূন্য থেকে শুরু হয়। কারণ কোনো distributor যে user-দের আপনার bridge-এ পাঠায়, আপনার bridge শুধু তাদের traffic বহন করে। নির্দিষ্ট সর্বোচ্চ সীমা চাইলে torrc-এ RelayBandwidthRate এবং RelayBandwidthBurst সেট করুন।

আমার নতুন bridge-এ কেউ connect করেনি কেন?

Relay Search-এ একটি bridge দেখা যেতে প্রায় তিন ঘণ্টা লাগে। Tor Project-এর নির্দেশনা অনুযায়ী, নিয়মিত user পাওয়া শুরু হতে কয়েক দিন বা কয়েক সপ্তাহ লাগতে পারে। descriptor প্রকাশিত হয়েছে কি না পরীক্ষা করুন। journalctl -u tor@default-এ থাকা self-testing line-টি দেখুন। Relay Search-এ আপনার hashed fingerprint খুঁজুন। এছাড়া নিশ্চিত করুন যে BridgeDistribution, none হিসেবে সেট করা নেই।

আমার কি obfs4 নাকি WebTunnel চালানো উচিত?

এটি আপনার প্রথম bridge হলে obfs4 চালান। এর জন্য একটি VPS, দুটি port, কোনো domain নয় এবং কোনো certificate নয়। যেখানে random-looking traffic-ও block করা হয়, সেখানে WebTunnel চালান। এর জন্য আপনার নিয়ন্ত্রণে থাকা একটি domain, একটি আসল web server, একটি valid TLS certificate এবং অন্তত 1 GB RAM প্রয়োজন। দুটিই চালালে আলাদা address ব্যবহার করুন। তা না হলে একটি IP block হলে একই সঙ্গে দুটি bridge বন্ধ হয়ে যাবে।

পরে obfs4 port পরিবর্তন করলে কী হবে?

ইতিমধ্যে বিতরণ করা প্রতিটি bridge line কাজ করা বন্ধ করবে। একটি bridge line address, port, fingerprint এবং certificate একসঙ্গে নির্দিষ্ট করে। তাই পুরোনো line থাকা client এমন একটি port-এ connection খোলার চেষ্টা করবে যেখানে কোনো service listening করছে না, এবং connection ব্যর্থ হবে। Server-এর public IP পরিবর্তন হলেও একই ঘটনা ঘটবে। Setup-এর সময় port নির্বাচন করুন এবং পরে পরিবর্তন করবেন না।