VPS-এ obfs4 দিয়ে Tor bridge চালানোর নিয়ম

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

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

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

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

কোন pluggable transport চালানো উচিত?

• obfs4-এর জন্য একটি VPS, 2টি TCP port এবং কোনো domain name লাগে না। এটি চালানোর জন্য সবচেয়ে সহজ এবং কার্যকর বিকল্প। এই গাইডে এটিই দেখানো হয়েছে।
• WebTunnel সংযোগটি একটি বাস্তব website-এ পাঠানো সাধারণ HTTPS traffic-এর মধ্যে আড়াল করে। Tor Project-এর তালিকাভুক্ত প্রয়োজনীয়তার মধ্যে রয়েছে একটি static IPv4 address, আপনার নিয়ন্ত্রণাধীন একটি domain, NGINX বা Apache-এর মতো সচল web server, একটি বৈধ TLS certificate এবং কমপক্ষে 1 GB RAM; 4 GB সুপারিশ করা হয়। যেসব network-এ এলোমেলো ধরনের traffic নিজেই সন্দেহজনক, সেখানে এটি উপযোগী। কারণ কোনো দেশ web browsing ছাড়া অন্য কিছু সীমিত করলেও HTTPS সাধারণত অনুমোদিত থাকে।
• Snowflake ভিন্ন ধরনের অবদান। স্বেচ্ছাসেবকেরা স্বল্পস্থায়ী 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-এর জন্য upstream এবং downstream—উভয় দিকেই অন্তত 1 Mbit/s bandwidth চায়। একটি guard বা middle relay-এর জন্য 10 Mbit/s চাওয়া হয়, এবং 16 Mbit/s সুপারিশ করা হয়। এগুলো প্রকাশিত requirement, পরিমাপ করা বাস্তব ব্যবহার নয়। নতুন bridge সাধারণত কয়েক সপ্তাহ নিজের ন্যূনতম সীমার অনেক নিচে থাকে। একই requirements page একটি relay-এর জন্য মাসে অন্তত 100 GByte outbound traffic চায়। সবচেয়ে ছোট plan-গুলোতেই সাধারণত এই পরিমাণ মেটানো যায়। তাই বড় আকারের কিছু নেওয়ার আগে একটি ছোট VPS-এর মাসিক প্রকৃত খরচ কত দেখুন।

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

একটি কাজ করবেন না: একই address-এ চলমান কোনো existing public relay-কে bridge-এ রূপান্তর করবেন না। এই পরিস্থিতিতে Tor Project-এর পরামর্শ হলো "IP address, name and fingerprint" পরিবর্তন করা। কারণ পুরোনো address ইতিমধ্যে সেই consensus-এ রয়েছে, যেটি censor-রা 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 সেট up করুন, যাতে এটি যেদিন 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 নেই, তাহলে Tor Project সেই release সমর্থন করে না। /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টি কোথায় ইনস্টল হয়েছে তা নিশ্চিত করুন, কারণ config-এ সেই path ব্যবহার করতে হবে:

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 থেকে reachable হতে হবে, কারণ tor port-টি পরীক্ষা করে। পরীক্ষা সফল না হওয়া পর্যন্ত tor descriptor publish করতে অস্বীকার করে।

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 নির্দেশ করে, যেখানে কিছুই listening করছে না। ওই client-গুলো connection refused পায় এবং পুনরায় চেষ্টা করা বন্ধ করে।

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

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

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

কেন port নির্বাচন গুরুত্বপূর্ণ

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

obfs4-এর জন্য সবচেয়ে ভালো port হলো 443। প্রায় সব restricted network-এ outbound 443 খোলা থাকে, এবং সেখানে দীর্ঘস্থায়ী connection সাধারণ web session-এর মতো দেখায়। 1024-এর নিচের port-এ 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 অর্জন করতে দেয় না। File capability ঠিক এমন privilege-ই দেয়। তাই এই setting চালু থাকলে obfs4proxy 443-এ bind করতে ব্যর্থ হয়।

এই ধাপ এড়াতে চাইলে সাধারণ একটি high port বেছে নিয়ে তা লিখে রাখুন। যে 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 প্রকাশ করে না। এর কোনো অংশ আপনার জন্য নতুন হলে, একটি নতুন VPS-এর প্রয়োজনীয় ufw rule এবং Linux-এ listening port আসলে কী বিষয়ক নির্দেশনা দেখুন। একই সময়ে key এবং hardened 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-এর অধীনে থাকে।

দুটি line দেখায় যে কাজটি সফল হয়েছে:

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 আটকে দিচ্ছে। দ্বিতীয় line-এ আপনার configured 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 প্রকৃতপক্ষে কীভাবে ব্যবহারকারীদের কাছে পৌঁছায়?

আপনি আপনার 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 পাঠালে reply-তে bridge line পাওয়া যায়। এই provider restriction-এর কারণ হলো, সীমাহীন free account থাকলে একজন censor প্রতিটি bridge-এর তালিকা তৈরি করতে পারত।
• Telegram bot @GetBridgesBot। /start পাঠান, তারপর /obfs4 অথবা /webtunnel পাঠান।
• Tor Browser-এর Settings, তারপর Connection বিভাগে "Request bridges" নির্বাচন করলে moat channel-এর মাধ্যমে bridge সংগ্রহ করা হয়।

Setup-এর প্রায় তিন ঘণ্টা পরে Relay Search-এ নতুন bridge দেখা যায়। ব্যবহারকারী পেতে আরও বেশি সময় লাগে। Tor Project-এর ভাষায়, "It can take several days or weeks until you see a consistent set of users." প্রথম দুই সপ্তাহে bridge-এ তেমন ব্যবহারকারী না থাকাটা স্বাভাবিক; এটি ত্রুটি নয়।

BridgeDistribution none সেট করলে এই সব distribution ব্যবস্থা থেকে 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-এর name-এর সঙ্গে হুবহু মিলতে হবে। দুটিকেই 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 policy 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 publish হয়েছে কি না পরীক্ষা করুন। journalctl -u tor@default-এর self-testing line-টি দেখুন। Relay Search-এ আপনার hashed fingerprint খুঁজুন। এছাড়া BridgeDistribution যেন none-এ সেট না থাকে, তা নিশ্চিত করুন।

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

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

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

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