VPS-এ Tailscale subnet router চালানোর পদ্ধতি

Tailscale subnet router কী করে

Tailscale subnet router হলো এমন একটি মেশিন, যা private IP address-এর একটি সম্পূর্ণ range আপনার tailnet-এ advertise করে, ফলে tailnet-এর প্রতিটি device ওই range-এর address-এ পৌঁছাতে পারে, যদিও ওই network-এর কোনো device-এ Tailscale চালু নেই। আপনার tailnet হলো আপনার private Tailscale network: একই account বা organisation-এ signed in থাকা device-গুলোর সমষ্টি। অনেকে এটিকে exit node-এর সঙ্গে গুলিয়ে ফেলেন, কিন্তু exit node বিপরীত কাজ করে। এটি কোনো device-এর সব traffic VPS-এর মাধ্যমে বাইরে পাঠায়, ফলে public internet-এ যাওয়ার সময় VPS ওই device-এর route হয়ে যায়।

প্রতিটি বিষয় এক বাক্যে বলা যায়। Subnet router tailnet থেকে একটি private network-কে reachable করে। Exit node আপনার public traffic কোন স্থান থেকে বের হবে তা পরিবর্তন করে। দ্বিতীয়টিই যদি আপনার প্রয়োজন হয়, তাহলে এর পরিবর্তে VPS-এ Tailscale exit node কীভাবে চালাবেন পড়ুন। এগুলো আলাদা flag, এবং একটি VPS একই সময়ে দুটো কাজই করতে পারে, কিন্তু এগুলো ভিন্ন সমস্যা সমাধান করে এবং ভিন্নভাবে ব্যর্থ হয়।

VPS-এর ক্ষেত্রে subnet router প্রয়োজন হলে

সাধারণ ক্ষেত্রে provider আগে থেকেই আপনাকে একটি private network দিয়েছে। আপনার VPS-এর একটি public address এবং private segment-এ একটি দ্বিতীয় interface থাকে। ওই segment-এর অন্য server-গুলোর কোনো public address থাকে না। যেমন, একটি database থাকে 10.0.0.20-এ এবং একটি backup target থাকে 10.0.0.30-এ। একটি VPS-এ Tailscale ইনস্টল করুন এবং 10.0.0.0/24 advertise করুন। এরপর আপনার laptop ওই private address-গুলোতে সরাসরি পৌঁছাতে পারবে। Segment-এর অন্য কিছু পরিবর্তন করতে হবে না। Database-এর কোনো public address-ও থাকবে না। ওই segment থেকে যদি শুধু একটি port-এ চলা একটি web app প্রয়োজন হয়, তাহলে পুরো range advertise করা প্রয়োজনের তুলনায় বেশি। সে ক্ষেত্রে Tailscale serve ওই একক port-এ HTTPS চালু করে। একই যুক্তি এমন daemon-এর ক্ষেত্রেও প্রযোজ্য, যা ইচ্ছাকৃতভাবে শুধু localhost-এ bind করে। উদাহরণ হিসেবে systemd-এর অধীনে headless অবস্থায় চলা dsh উল্লেখ করা যায়। এ ক্ষেত্রে ওই VPS-এর tailnet address ব্যবহার করলে UI-তে পৌঁছানোর জন্য আলাদা SSH tunnel খোলা রাখতে হয় না।

অন্য ক্ষেত্রে VPS-এর অপর পাশে একটি network থাকে। এটি হতে পারে নিজস্ব router-এর পেছনে থাকা কোনো home বা office LAN (local area network)। অথবা এমন কোনো appliance-এর rack হতে পারে, যেগুলোতে Tailscale চালানো যায় না। যেমন, managed switch বা locked firmware-সহ পুরোনো NAS। ওই network-এর একটি Linux box সেখানে থাকা অন্য সব device-এর জন্য subnet router হিসেবে কাজ করবে। বাড়িতে এই box প্রায়ই আপনার আগে থেকেই চালানো hypervisor-এর একটি ছোট VM হয়। কোন প্রান্তে আপনার service-গুলো রাখা উচিত, তা নির্ধারণের আগে বাড়িতে Proxmox host চালানোর খরচ এবং ভাড়া করা VPS-এর খরচের তুলনা সমাধান করা উচিত।

দুই ক্ষেত্রেই একটি শর্ত একই। Subnet router-কে নিজের routing table এবং firewall ব্যবহার করে advertise করা range-এ আগে থেকেই পৌঁছাতে সক্ষম হতে হবে। Tailscale এই connection তৈরি করে না। এটি traffic router পর্যন্ত পৌঁছে দেয় এবং forward করার জন্য kernel-এর কাছে হস্তান্তর করে।

Tailscale ইনস্টল করুন এবং প্রথমে স্থানীয় route পরীক্ষা করুন

curl -fsSL https://tailscale.com/install.sh | sh

স্ক্রিপ্টটি distribution শনাক্ত করে, Tailscale-এর package repository যোগ করে, tailscale command এবং tailscaled daemon ইনস্টল করে, তারপর service চালু করে। systemctl is-active tailscaled দিয়ে এটি নিশ্চিত করুন। এতে active দেখা উচিত।

অন্য কিছু করার আগে নিশ্চিত করুন যে VPS যে network আপনি advertise করার পরিকল্পনা করছেন, সেখানে পৌঁছাতে পারে।

ip route show
ping -c3 10.0.0.20

ip route show-এ একটি বাস্তব interface-এর private range তালিকাভুক্ত থাকতে হবে, যেমন 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5। এখানে, অর্থাৎ router-এ, ping ব্যর্থ হলে কোনো Tailscale flag তা ঠিক করতে পারবে না। সমস্যা VPS-এর network configuration অথবা target host-এর firewall-এ রয়েছে। আগে এটি ঠিক করুন, কারণ পরবর্তী প্রতিটি পরীক্ষা এর ওপর নির্ভর করে।

IP forwarding চালু করুন এবং reboot-এর পরও এটি চালু রাখুন

Linux machine নিজের জন্য নির্ধারিত নয় এমন কোনো packet forwarding চালু না থাকলে বাতিল করে। অন্য machine-এর packet forward করাই subnet router-এর সম্পূর্ণ কাজ। তাই এই ধাপটি ঐচ্ছিক নয়।

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

sysctl net.ipv4.ip_forward দিয়ে এটি পরীক্ষা করুন। এতে net.ipv4.ip_forward = 1 প্রিন্ট হওয়ার কথা।

অনেকে এই ধাপটি আংশিকভাবে সঠিকভাবে সম্পন্ন করেন। sudo sysctl -w net.ipv4.ip_forward=1 সঙ্গে সঙ্গে কাজ করে, কিন্তু পরবর্তী boot-এর সময় সেটি হারিয়ে যায়। ফলে subnet router কয়েক সপ্তাহ চলে, তারপর kernel upgrade-এর পরে reboot হওয়ার পরের সকালে বন্ধ হয়ে যায়। বিভ্রান্তিকর বিষয় হলো, কোনো কিছু নষ্ট মনে হয় না। tailscale status এখনও node-টিকে online দেখায়, admin console-এ route এখনও অনুমোদিত দেখায়, এবং client-গুলোর কাছেও route এখনও ইনস্টল করা থাকে। Packet VPS-এ পৌঁছায়, কিন্তু kernel কোনো log না লিখেই সেগুলো বাতিল করে। /etc/sysctl.d/99-tailscale.conf-এ মানগুলো লিখলেই reboot-এর পর সেগুলো আবার কার্যকর হয়।

Forwarding এখনও বন্ধ থাকা অবস্থায় route advertise করলে tailscale up তখনই সতর্ক করে। সতর্কবার্তাটিতে Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.-এর কাছাকাছি একটি line থাকে। সেই command-এর output পড়ুন। এটি এড়িয়ে scroll করে চলে যাবেন না।

রুট বিজ্ঞাপন করুন

sudo tailscale up --advertise-routes=10.0.0.0/24

ইতিমধ্যে আপনার tailnet-এ sign in করা VPS-এ পরিবর্তে সেটিংটি সরাসরি পরিবর্তন করুন:

sudo tailscale set --advertise-routes=10.0.0.0/24

পরবর্তী প্রতিটি পরিবর্তনের জন্য tailscale set ব্যবহার করুন। একটি মাত্র flag দিয়ে tailscale up আবার চালালে পুনরায় উল্লেখ না করা flag-গুলোর মান reset হয়ে যায়। CLI একটি error দেখিয়ে কমান্ডটি থামিয়ে দেয় এবং জানায় যে এভাবে settings পরিবর্তন করতে হলে সব non-default flag উল্লেখ করতে হবে। tailscale set একটি setting পরিবর্তন করে এবং বাকি settings অপরিবর্তিত রাখে।

একটি comma-separated list-এ কোনো space ছাড়া একাধিক range দেওয়া যায়: --advertise-routes=10.0.0.0/24,192.168.50.0/24। প্রতিটি entry-কে CIDR notation-এ (classless inter-domain routing, অর্থাৎ 10.0.0.0/24 form) একটি network address হতে হবে। ভুল করে নিজের host address, 10.0.0.5/24, লিখলে সেটি প্রত্যাখ্যাত হয়, কারণ prefix-এর পরের bit-গুলো zero নয়। error message-এ আপনি সম্ভবত যে prefix বোঝাতে চেয়েছেন, সেটি উল্লেখ করা হয়। advertising বন্ধ করতে sudo tailscale set --advertise-routes= দিয়ে একটি empty list সেট করুন।

অ্যাডমিন কনসোলে route অনুমোদন করুন

কোনো route advertise করা একটি অনুরোধ, পরিবর্তন নয়। কোনো অ্যাডমিন এটি অনুমোদন না করা পর্যন্ত কোনো client route-টি পায় না এবং range-এর কোনো কিছুই reachable হয় না। এটি ইচ্ছাকৃত, কারণ সবার routing table-এ নিজেকে যুক্ত করতে পারে এমন কোনো machine ইচ্ছামতো যেকোনো range-এর traffic capture করতে পারে।

অ্যাডমিন কনসোলের Machines page থেকে এটি অনুমোদন করুন। VPS-টি subnet badge-সহ তালিকাভুক্ত থাকবে। এর row খুলুন, subnets section খুঁজে route settings সম্পাদনা করুন, route-এ tick দিন এবং save করুন।

অনুমোদন প্রতিটি prefix-এর জন্য আলাদা। আজ 10.0.0.0/24 এবং পরের মাসে 192.168.50.0/24 advertise করলে নতুন prefix-টি unapproved অবস্থায় যোগ হবে, আর পুরোনোটি কাজ করতে থাকবে। VPS-এর দিক থেকে approved route এবং ignored route দেখতে একই, তাই অন্য কিছু debug করার আগে console পরীক্ষা করুন।

tailnet policy file-এ autoApprovers block ব্যবহার করে manual ধাপটি এড়িয়ে যেতে পারেন:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

এরপর ওই tag, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, ব্যবহার করে node-টি up করুন। তাহলে route advertise হওয়ার সঙ্গে সঙ্গেই অনুমোদিত হবে। একই policy file-এর tagOwners section-এ tag-টি আগে থেকেই থাকতে হবে। কোনো script দিয়ে VPS rebuild করলে এটি আগে থেকে সেট করা উপযোগী, কারণ rebuild করা node একটি নতুন node এবং তার route আবার unapproved অবস্থায় শুরু হয়।

--accept-routes ছাড়া Linux client কেন route উপেক্ষা করে

এখন route advertise এবং approve করা হয়েছে। আপনার ফোন এবং Mac 10.0.0.20-এ পৌঁছাতে পারে। আপনার Linux laptop পারে না, অথচ admin console-এ কোনো সমস্যার ইঙ্গিত নেই।

Subnet route গ্রহণ করার অর্থ হলো client-এর routing table-এ entry লেখা। Android, iOS, macOS, tvOS এবং Windows-এ Tailscale client নিজেই এটি করে। Linux-এ তা করে না, কারণ Linux machine প্রায়ই server বা router হিসেবে ব্যবহৃত হয় এবং এর routing table কেউ ইচ্ছাকৃতভাবে configure করে থাকে। Network থেকে শেখা একটি /24 নীরবে যোগ হলে machine-টি আগে থেকেই পরিচালনা করা traffic ব্যাহত হতে পারে। তাই Linux-এ প্রতিটি client-এ আপনাকে নিজে opt in করতে হবে:

sudo tailscale set --accept-routes

এরপর route-টি কোথায় যোগ হয়েছে তা পরীক্ষা করুন:

ip route show table 52
ip route get 10.0.0.20

Linux-এ Tailscale accepted route-গুলো main routing table-এ রাখে না। এগুলো routing table 52-এ রাখে এবং policy rule install করে। ip rule show-এর মাধ্যমে priority range 5210 থেকে 5270-এ এই rule-গুলো দেখা যায়। এগুলো এমন packet, যেগুলোর জন্য অন্য কোনো match নেই, সেই packet-গুলোকে ওই table-এ পাঠায়। তাই শুধু ip route show চালালে কখনো 10.0.0.0/24 তালিকাভুক্ত হবে না। যে পাঠক কেবল ওই command পরীক্ষা করেন, তিনি ধরে নেন যে --accept-routes কোনো কাজ করেনি। ip route show table 52 হলো প্রকৃত অবস্থা দেখার command। এতে tailscale0-এ advertise করা range দেখা যাওয়ার কথা।

একটি ব্যতিক্রম জানা দরকার। এই Linux node যদি নিজের local network-এর জন্য দ্বিতীয় subnet router হয়, তাহলে --accept-routes চালু করলে এটি নিজের সরাসরি সংযুক্ত subnet-এর traffic নিজের interface দিয়ে না পাঠিয়ে অন্য router-এর মাধ্যমে পাঠাবে। High availability pair-এর standby router-এ --accept-routes বন্ধ রাখুন এবং শুধু advertise করুন।

ব্যর্থতার ধরন: দুটি router-এর বিজ্ঞাপিত range পরস্পরের সঙ্গে overlap করে

দুটি subnet router একই range বিজ্ঞাপন করবে না। Prefix length আলাদা হলে overlap করা range অনুমোদিত, এবং Tailscale সবচেয়ে নির্দিষ্ট match বেছে নেয়। router A যদি 10.0.0.0/24 এবং router B যদি 10.0.0.0/16 বিজ্ঞাপন করে, তাহলে 10.0.0.20-এ যাওয়া traffic A-এর মাধ্যমে যায়।

A offline হলে আচরণটি অনেককে বিস্মিত করে। Tailscale কম নির্দিষ্ট route-এ fallback করে না। 10.0.0.20-এ যাওয়া traffic বন্ধ হয়ে যায়, কিন্তু 10.1.0.20-এর traffic B-এর মাধ্যমে চলতে থাকে। এতে মনে হয় private network-এর অর্ধেক বন্ধ, কিন্তু প্রকৃত কারণ হলো একটি offline node-এর কাছে আরও নির্দিষ্ট prefix থাকা। Failover চাইলে wider router-টিকেও narrower prefix-গুলো বিজ্ঞাপন করান, যাতে উভয় router একই address cover করে।

অন্য ধরনের overlap client-এর কাছাকাছি ঘটে। 192.168.1.0/24-এর একটি hotel network-এ থাকা অবস্থায় আপনার subnet router যদি 192.168.1.0/24 বিজ্ঞাপন করে, তাহলে একই destination-এর জন্য দুটি route প্রতিদ্বন্দ্বিতা করে। কোনটি জিতবে, তা platform-এর ওপর নির্ভর করে। Linux-এ Tailscale-এর নিজস্ব rule-এর আগে একটি rule যোগ করুন, যাতে local address-গুলো main table ব্যবহার করে:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

এই rule persistent নয় এবং পরবর্তী boot-এ হারিয়ে যাবে। প্রকৃত সমাধান হলো এমন একটি private range বেছে নেওয়া, যার মুখোমুখি আপনি সাধারণ network-এ হবেন না। অধিকাংশ home router-এ 192.168.0.0/24 এবং 192.168.1.0/24 default হিসেবে ব্যবহৃত হয়। তাই 10.0.0.0/8-এর মধ্যে আপনার উদ্দেশ্য অনুযায়ী বেছে নেওয়া একটি range ব্যবহার করুন। একই collision নিজে হাতে configure করা সাধারণ WireGuard VPN-ও অকার্যকর করে, একই কারণে: আরও নির্দিষ্ট local route জয়ী হয়, তাই traffic tunnel-এ প্রবেশ করে না।

ব্যর্থতার ধরন: DNS এমন একটি address-এ resolve হয়, যেটিকে কোনো route কভার করে না

এই সমস্যাটি debug করা কঠিন, কারণ কোনো কিছুই error জানায় না। নামটি resolve হয়। Connection timeout হয়।

ধরা যাক, আপনার private nameserver-এর মাধ্যমে db.internal.example.com, 10.0.5.20-এ resolve হয় এবং আপনি 10.0.0.0/24 advertise করেছেন। Lookup সফল হয়, কারণ DNS (domain name system) resolution এবং IP routing আলাদা ধাপ; কোনো ধাপই অন্য ধাপটি যাচাই করে না। এরপর 10.0.5.20-এ পাঠানো packet tailnet-এ কোনো matching route খুঁজে পায় না। তাই এটি client-এর default gateway দিয়ে বেরিয়ে যায় এবং হারিয়ে যায়।

দুটি command এই দুই অংশ আলাদা করে দেখায়:

nslookup db.internal.example.com
ip route get 10.0.5.20

Lookup একটি address ফেরত দিলেও ip route get, dev tailscale0 দিয়ে উত্তর না দিলে বুঝবেন নামটি সঠিক, কিন্তু route অনুপস্থিত। Address-টি কভার করে এমন একটি range advertise করুন। এটি হতে পারে 10.0.0.0/16 অথবা একটি দ্বিতীয় explicit prefix। এরপর console-এ নতুন prefix approve করুন।

Nameserver-এও একই ধরনের সমস্যা হতে পারে। Admin console-এ 10.0.0.53-এর মতো private address-এ global nameserver সেট করলে ওই address-টি একটি approved route-এর মধ্যে থাকতে হবে। তা না হলে আপনার device-গুলো resolver-এ পৌঁছাতে পারবে না। এমন একটি resolver-এ নির্দেশ দেওয়ার সময় local DNS server override করার option চালু করলে, যেটিতে কোনো device পৌঁছাতে পারে না, tailnet-এর প্রতিটি device একসঙ্গে name resolution হারায়। এর মধ্যে এক মুহূর্ত আগেও কাজ করা device-গুলোও অন্তর্ভুক্ত। প্রথমে resolver-এ যাওয়ার route advertise এবং approve করুন। এরপর DNS setting পরিবর্তন করুন। Tunnel-এর ভেতরের DNS নিয়ে বারবার সমস্যা হলে, WireGuard tunnel-এর মাধ্যমে DNS কীভাবে ভেঙে যায় একই mechanism ব্যাখ্যা করে, তবে ওপরের coordination layer ছাড়া।

Source NAT এবং site-to-site link

ডিফল্টভাবে subnet router প্রতিটি forwarded packet-এর source address নিজের private address দিয়ে পরিবর্তন করে। এটিই SNAT (source network address translation)। Private network-এ কোনো পরিবর্তন না করেও যাতে reply কাজ করে, সে জন্য এটি ব্যবহৃত হয়: 10.0.0.20-এর database VPS-কে উত্তর দেয়, কারণ VPS-এ কীভাবে পৌঁছাতে হয় তা database আগে থেকেই জানে। এর অসুবিধা হলো, database-এর কাছে tailnet-এর প্রতিটি connection VPS থেকে আসা বলে মনে হয়। তাই source অনুযায়ী firewall rule এবং access log কোনো কার্যকর তথ্য দেয় না।

Client-এর প্রকৃত tailnet address অপরিবর্তিত রাখতে Linux-এ এটি বন্ধ করুন:

sudo tailscale set --snat-subnet-routes=false

এরপর private network-এর host-গুলোর 100.64.0.0/10-এর জন্য একটি return route প্রয়োজন। Tailscale device-গুলোর জন্য এই range বরাদ্দ করা হয়। Route-টি subnet router-এর দিকে নির্দেশ করতে হবে। এই return route না থাকলে reply default gateway-তে চলে যায় এবং গন্তব্যে পৌঁছায় না। ফলে প্রথম packet-এর পর connection আটকে থাকে। Private network-এর gateway-তে static route যোগ করুন, অথবা SNAT চালু রাখুন।

Site-to-site link-এ দুটি subnet router একই কাজ করে। প্রতিটি router নিজের network advertise করে এবং অন্য router-এর network গ্রহণ করে:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

অন্য router-এ তার নিজস্ব range ব্যবহার করে একই ধরনের command চালান। দুটি range অবশ্যই আলাদা হতে হবে। ssh এবং ping ঠিক থাকলেও বড় transfer আটকে গেলে কারণটি MSS (maximum segment size)। একটি TCP packet সর্বোচ্চ যত বড় data বহন করতে পারে, MSS সেই সীমা নির্ধারণ করে। Tunnel-এর overhead-এর কারণে forwarded packet মাঝের কোনো link-এর জন্য অতিরিক্ত বড় হয়ে যায়। MSS clamping এটি ঠিক করে:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iptables-persistent ব্যবহার করে rule-টি সংরক্ষণ করুন। তা না হলে পরবর্তী boot-এ rule-টি হারিয়ে যাবে।

এটি সচল রাখতে নিয়মিত রক্ষণাবেক্ষণ

August 2026 অনুযায়ী, ডিফল্টভাবে Node key 180 দিন পরে মেয়াদোত্তীর্ণ হয়। কোনো subnet router-এর key-এর মেয়াদ শেষ হলে node sign out করে এবং বিজ্ঞাপিত সম্পূর্ণ range-টি unreachable হয়ে যায়। এটি বোঝানোর মতো কোনো configuration change কোথাও থাকে না। Admin console-এর Machines page থেকে এই মেশিনের জন্য key expiry disable করুন। এরপর কাজটি করেছেন বলে নথিভুক্ত করুন।

Tailscale peer-গুলোর মধ্যে সরাসরি connection স্থাপনের চেষ্টা করে। এটি সম্ভব না হলে relay server ব্যবহার করে। Relay-গুলো কাজ করে, তবে latency বাড়ায়। Public address থাকা VPS-এর ক্ষেত্রে বিষয়টি সহজ: inbound UDP 41641 অনুমোদন করুন, তাহলে অধিকাংশ peer সরাসরি connection স্থাপন করবে। Firewall পরিচালনার জন্য ufw ব্যবহার করলে, VPS-এর আসলে প্রয়োজনীয় ufw rule-গুলো-তে syntax দেওয়া আছে।

Access rule হলো এর অন্য অর্ধেক। ডিফল্ট tailnet-এ আপনার প্রতিটি device অন্য প্রতিটি device-এ পৌঁছাতে পারে। তাই অনুমোদিত route সরাসরি কাজ করে। আপনি ACL policy লিখলে rule-এর destination পাশে private range উল্লেখ করতে হবে। কারণ 10.0.0.20 tailnet address নয় এবং tailnet IP বা tag-এর বিরুদ্ধে লেখা rule এটি কভার করে না।

সবশেষে, আপনি এমন কোনো coordination server ব্যবহার করতে চান কি না ঠিক করুন, যেটি আপনি নিজে পরিচালনা করেন না। Tailscale-এর control plane একটি hosted service। আপনার key-গুলো আপনার মেশিনেই থাকে, কিন্তু account এবং policy file সেখানে থাকে। Compromised control plane বা চুরি হওয়া identity login ব্যবহার করে কেউ বাস্তবে কী করতে পারে, সেটিই private network-এ route দেওয়ার আগে নির্ধারণ করা গুরুত্বপূর্ণ। Tailscale-এর trust model এই boundary কোথায় রয়েছে তা ব্যাখ্যা করে। খরচের কারণে খুব কম মানুষ এটি বাদ দেয়, কারণ free plan-এ সর্বোচ্চ ছয়জন user-এর জন্য তাদের নিজস্ব unlimited device ব্যবহার করা যায়। তবে tag-এর অধীনে চালু করা subnet router এবং আপনার account দিয়ে sign in করা subnet router একইভাবে গণনা হয় না। এর পরে বিল machine নয়, user-এর সংখ্যা অনুসরণ করে। তাই free plan শেষ হলে কোনো household বা পাঁচজনের team বাস্তবে কত খরচ দেয় তা হিসাব করে নিন, account যোগ করে সীমা অতিক্রম করার আগে। Headscale, self-hosted Tailscale control server চালালে coordination server আপনার নিজের VPS-এ থাকে। তবে এটি আপনাকেই maintain করতে হবে। একই উদ্বেগের অন্য সমাধান হলো Tailscale-এর client-ও ব্যবহার না করা। NetBird VPN server self-host করা হলে coordination layer এবং এর নিজস্ব mesh client আপনার নিয়ন্ত্রণাধীন একটি মেশিনে থাকে। আপনি যদি এখনও এই model এবং হাতে লেখা config-এর মধ্যে সিদ্ধান্ত না নিয়ে থাকেন, WireGuard এবং Tailscale-এর তুলনা coordination layer কী সুবিধা দেয় এবং এর খরচ কী, তা ব্যাখ্যা করে।

FAQ

subnet router এবং exit node-এর মধ্যে পার্থক্য কী?

একটি subnet router private address-এর একটি range advertise করে। তাই tailnet-এর device-গুলো এমন machine-এ পৌঁছাতে পারে যেগুলোতে Tailscale চলে না। একটি exit node নিজেকে পুরো Internet-এর route হিসেবে advertise করে। তাই কোনো device তার সব network traffic ওই node-এর public address দিয়ে পাঠায়। একটি VPS একই সঙ্গে দুটিই হতে পারে। এগুলো আলাদা flag, --advertise-routes এবং --advertise-exit-node। প্রতিটির জন্য admin console-এ আলাদা approval প্রয়োজন।

আমার Linux client advertised subnet route ব্যবহার করছে না কেন?

Linux client-গুলো স্বয়ংক্রিয়ভাবে subnet route গ্রহণ করে না। client-এ sudo tailscale set --accept-routes চালান। এরপর ip route show নয়, ip route show table 52 দিয়ে পরীক্ষা করুন। Tailscale গৃহীত route-গুলো routing table 52-এ স্থাপন করে এবং policy rule-এর মাধ্যমে সেগুলোতে পৌঁছায়। তাই main table-এ এগুলো কখনো তালিকাভুক্ত হয় না, ফলে কার্যকর route-ও অনুপস্থিত মনে হতে পারে।

reboot-এর পরে আমার subnet কাজ করা বন্ধ করেছে। কী নষ্ট হয়েছে?

সম্ভবত IP forwarding। sysctl -w দিয়ে সেট করা value reboot-এর পরে টিকে থাকে না। তাই এটি /etc/sysctl.d/99-tailscale.conf-এ লিখুন এবং sysctl net.ipv4.ip_forward দিয়ে নিশ্চিত করুন। forwarding চালু থাকলেও range-এ পৌঁছানো না গেলে admin console-এ node-টি পরীক্ষা করুন। Defaultভাবে node key 180 days পরে expire হয়। Expired subnet router account সমস্যা নয়, বরং network fault-এর মতো দেখা যায়।

দুটি subnet router কি একই range advertise করতে পারে?

অভিন্ন range নয়। ভিন্ন prefix length-সহ overlapping range ব্যবহার করা যায়, এবং সবচেয়ে specific route কার্যকর হয়। Failover-এর ক্ষেত্রে সতর্কতা প্রয়োজন। বেশি specific prefix ধারণকারী router offline হলে Tailscale বিস্তৃত route-এ fallback করে না। ফলে ওই traffic বন্ধ হয়ে যায়। প্রকৃত standby pair-এর জন্য দুটি router-ই একই specific prefix advertise করান।

hostname resolve হয়, কিন্তু connection timeout হয়। কেন?

DNS resolution এবং routing আলাদা ধাপ। কোনো name এমন address-এ resolve হতে পারে, যেটি কোনো approved route-এর আওতায় নেই। সে ক্ষেত্রে packet client-এর default gateway দিয়ে বেরিয়ে যায়। client-এ ip route get <address> চালান। ফলাফলে dev tailscale0 না থাকলে ওই address-কে অন্তর্ভুক্ত করে এমন একটি range advertise করুন এবং admin console-এ নতুন prefix approve করুন।