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 থাকে না: 10.0.0.20-এ একটি database এবং 10.0.0.30-এ একটি backup target। একটি VPS-এ Tailscale ইনস্টল করে 10.0.0.0/24 advertise করুন। তাহলে আপনার laptop ওই private address-গুলোতে সরাসরি পৌঁছাতে পারবে। Segment-এর অন্য কোনো কিছু পরিবর্তন করতে হবে না। Database-এর কোনো public address-ও থাকবে না। ওই segment থেকে আপনার যদি শুধু একটি port-এ চলা একটি web app দরকার হয়, তাহলে পুরো range advertise করা প্রয়োজনের তুলনায় বেশি ব্যবস্থা। সে ক্ষেত্রে Tailscale serve কীভাবে ওই single 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 সেখানে থাকা সবকিছুর জন্য subnet router হিসেবে কাজ করে। এর সামনে থাকা home router-এ এ কাজের জন্য কোনো forwarded port প্রয়োজন হয় না। router port না খুলে Tailscale কীভাবে NAT অতিক্রম করে বিষয়টি ব্যাখ্যা করে কেন এটি কাজ করে এবং কখন relay ব্যবহার করা হয়। বাড়িতে ওই box প্রায়ই আপনার আগে থেকেই চালানো hypervisor-এর একটি ছোট VM হয়। কোন প্রান্তে আপনার service-গুলো থাকবে তা ঠিক করার আগে বাড়িতে Proxmox host চালানোর খরচ এবং rented 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-এর পরেও এটি সক্রিয় রাখুন

Forwarding চালু না থাকলে Linux machine নিজের উদ্দেশে নয়—এমন সব packet বাতিল করে। অন্য 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 এখনও approved দেখায়, এবং client-গুলোর কাছেও route এখনও installed থাকে। Packet VPS-এ পৌঁছায়, কিন্তু kernel কোনো log না লিখেই তা বাতিল করে। /etc/sysctl.d/99-tailscale.conf-এ value লিখলেই reboot-এর পর সেগুলো আবার কার্যকর হয়।

Forwarding এখনও বন্ধ থাকা অবস্থায় route advertise করলে tailscale up সঙ্গে সঙ্গে সতর্কবার্তা দেখায়। Linux-এ বার্তাটি সাধারণত Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.-এর কাছাকাছি হয়। সেই command-এর output এড়িয়ে না গিয়ে পড়ুন।

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

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 করুন।

ব্যর্থতার ধরন: overlapping range বিজ্ঞাপন করা দুইটি router

দুইটি subnet router একই range বিজ্ঞাপন করতে পারে। High availability pair এভাবেই কাজ করে: প্রতিটি router ঠিক একই prefix বিজ্ঞাপন করে, এবং client-রা একটি router থেকে অন্যটিতে fail over করতে পারে। ভিন্ন prefix length-সহ overlapping 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 করে না, কারণ offline router তার advertisement প্রত্যাহার করতে পারে না এবং client-রা বেশি নির্দিষ্ট prefix-ই বেছে যেতে থাকে। 10.0.0.20-এর traffic বন্ধ হয়ে যায়। কিন্তু 10.0.1.20-এর traffic, যা শুধু B-এর /16 দ্বারা covered, B-এর মাধ্যমে চলতে থাকে। লক্ষণটি এমন দেখায় যেন private network-এর একটি অংশ down। কারণ হলো, একটি 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-এ আপনার দেখা হবে না। 192.168.0.0/24 এবং 192.168.1.0/24 অধিকাংশ home router-এর default। তাই ইচ্ছাকৃতভাবে বেছে নেওয়া 10.0.0.0/8-এর ভেতরের একটি range ব্যবহার করুন। একই collision নিজে হাতে configure করা সাধারণ WireGuard VPN-ও অকার্যকর করে, একই কারণে: বেশি নির্দিষ্ট local route জয়ী হয়, তাই traffic tunnel-এ প্রবেশই করে না।

ব্যর্থতার ধরন: DNS এমন ঠিকানায় 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 খুঁজে পায় না। তাই packet-টি client-এর default gateway দিয়ে বেরিয়ে যায় এবং হারিয়ে যায়।

দুটি command ব্যবহার করে এই দুই অংশ আলাদা করে পরীক্ষা করা যায়:

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

Lookup একটি address ফেরত দিলেও ip route get, dev tailscale0 দিয়ে সাড়া না দিলে নামটি সঠিক এবং এই client-এ route অনুপস্থিত। Linux client-এ প্রথমে নিশ্চিত করুন --accept-routes চালু আছে। এটি চালু না থাকলে approved prefix ইতিমধ্যে address-টি অন্তর্ভুক্ত করলেও কোনো subnet route install হয় না। এটি চালু থাকলেও approved prefix address-টি অন্তর্ভুক্ত না করলে, 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-এর মধ্যে থাকতে হবে। তা না হলে private network-এ থাকা নয় এমন device-গুলো resolver-এ পৌঁছাতে পারবে না। কোনো resolver-এ নির্দেশ করার সময় local DNS server override করার option চালু করলে, কিন্তু resolver-এ পৌঁছানোর route না থাকলে, tailnet-এর প্রতিটি device একসঙ্গে name resolution হারাবে—এক সেকেন্ড আগেও যেগুলো কাজ করছিল সেগুলোও। প্রথমে 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-টি হারিয়ে যাবে।

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

এই মেশিনের key কখন expire হবে, তা আপনি কীভাবে এতে sign in করেছেন তার ওপর নির্ভর করে। উপরের autoApprovers উদাহরণের মতো tag ব্যবহার করে চালু করা node-এ প্রথমবার tag ও authenticate করার সময় থেকেই default হিসেবে key expiry disabled থাকে। তাই এই সেটআপে এখানে কোনো কাজের প্রয়োজন নেই। আপনি user হিসেবে sign in করলে nodeটি tailnet-এর key expiry period অনুসরণ করে। নতুন tailnet-এ এটি default হিসেবে 180 days এবং October 2026 অনুযায়ী 1 থেকে 180 days-এর মধ্যে সেট করা যায়। এ ধরনের subnet router-এর key expire হলে এর সঙ্গে এবং এর মাধ্যমে সব connection বন্ধ হয়ে যায়। Advertised range-টিও সম্পূর্ণ unreachable হয়ে যায়। কোথাও configuration পরিবর্তন না করেও এমনটি ঘটতে পারে। User হিসেবে sign in করা router-এর ক্ষেত্রে admin console-এর Machines page-এ তার row-এর শেষে থাকা menu থেকে key expiry disabled করুন। এরপর কাজটি করেছেন বলে নথিভুক্ত করুন।

Tailscale peers-এর মধ্যে direct connection-কে অগ্রাধিকার দেয়। Direct connection স্থাপন করা না গেলে এটি relay server ব্যবহার করে। Relay কাজ করে, তবে latency বাড়ায়। Public address-যুক্ত VPS-এর ক্ষেত্রে বিষয়টি সহজ: inbound UDP 41641 অনুমোদন করলে অধিকাংশ peer সরাসরি connect করতে পারে। Private range-এ traffic যদি VPS link-এর প্রত্যাশিত গতির তুলনায় ধীর হয়, তাহলে আপনার client subnet router-এ সরাসরি নাকি relay-এর মাধ্যমে পৌঁছাচ্ছে তা পরীক্ষা করা প্রথমে যাচাই করার বিষয়। Firewall পরিচালনার জন্য ufw ব্যবহার করলে একটি VPS-এর আসলে যে ufw rule প্রয়োজন সেখানে syntax দেওয়া আছে।

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

সবশেষে, আপনি নিজে পরিচালনা করেন না এমন একটি coordination server ব্যবহার করতে চান কি না তা নির্ধারণ করুন। Tailscale-এর control plane একটি hosted service। আপনার key আপনার machine-এই থাকে। তবে account এবং policy file সেখানে থাকে। Control plane compromised হলে বা identity login চুরি হলে বাস্তবে কী করা সম্ভব, route-টি আপনার private network-এ দেওয়ার আগে এই ঝুঁকিটিই বিবেচনা করা উচিত। Tailscale-এর trust model এই সীমারেখাটি ব্যাখ্যা করে। সাধারণত cost-এর কারণে মানুষ Tailscale ছাড়ে না। কারণ free plan-এ সর্বোচ্চ six users-এর জন্য প্রত্যেকের unlimited device ব্যবহার করা যায়। তবে tag ব্যবহার করে চালু করা subnet router এবং user হিসেবে sign in করা subnet router-কে একইভাবে গণনা করা হয় না। Free plan-এর সীমা অতিক্রম করলে বিল machine-এর পরিবর্তে people-এর সংখ্যা অনুসরণ করে। তাই account যোগ করার আগে free plan শেষ হয়ে গেলে একটি household বা five person team বাস্তবে কত খরচ দেয় তা হিসাব করা উচিত। Headscale, self hosted Tailscale control server চালালে এটি আপনার নিজের VPS-এ রাখা যায়। তবে সেটি আপনাকেই maintain করতে হবে। একই উদ্বেগের আরেকটি সমাধান হলো Tailscale-এর client-ও বাদ দেওয়া। NetBird VPN server self-host করা coordination layer এবং তার নিজস্ব mesh client আপনার নিয়ন্ত্রণাধীন একটি machine-এ রাখে। উভয়ই নিচে WireGuard ব্যবহার করে। তাই switch করলে এই setup-এর যে অংশগুলো বদলাবে, NetBird এবং Tailscale-এর তুলনা সেগুলো বিবেচনা করে: control plane কে পরিচালনা করে, private range-কে অন্তর্ভুক্ত করে এমন access rule কীভাবে লিখবেন, এবং peer সরাসরি connect করতে না পারলে traffic কীভাবে relay হবে। এই model এবং নিজে লেখা config-এর মধ্যে এখনও সিদ্ধান্ত না নিলে, WireGuard এবং Tailscale-এর তুলনা coordination layer কী সুবিধা দেয় এবং এর খরচ কী, তা ব্যাখ্যা করে।

FAQ

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

একটি subnet router private address-এর একটি range advertise করে। তাই tailnet-এর ডিভাইসগুলো এমন মেশিনে পৌঁছাতে পারে যেগুলোতে Tailscale চলছে না। একটি exit node নিজেকে পুরো Internet-এ যাওয়ার route হিসেবে advertise করে। তাই কোনো ডিভাইস তার সব 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-টি দেখুন। User হিসেবে sign in করা router-এর key-এর মেয়াদ defaultভাবে 180 days পরে শেষ হয়। Expired subnet router-কে account সমস্যা না দেখে network fault মনে হতে পারে। Tag-এর অধীনে চালু করা router-এ defaultভাবে key expiry disabled থাকে। তাই সেই ক্ষেত্রে অন্য কারণ খুঁজুন।

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

হ্যাঁ। High availability pair-এর ক্ষেত্রে একই range ব্যবহার করা হয়। উভয় router-কে ঠিক একই prefix advertise করতে হয়। ভিন্ন prefix length-সহ overlapping range-ও ব্যবহার করা যায়। এ ক্ষেত্রে সবচেয়ে specific route কার্যকর হয়। তবে failover-এর জন্য সতর্কতা দরকার। বেশি specific prefix ধারণকারী router offline হলে Tailscale wider 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> চালান। Linux client-এ result-এর মধ্যে dev tailscale0 না থাকলে প্রথমে পরীক্ষা করুন --accept-routes চালু আছে কি না। এটি চালু থাকলে ওই address-কে অন্তর্ভুক্ত করে এমন একটি range advertise করুন এবং admin console-এ নতুন prefix approve করুন।