VPS-এ Tailscale subnet router সেটআপ করার নিয়ম

Tailscale subnet router কী কাজ করে

একটি Tailscale subnet router হলো এমন একটি মেশিন যা আপনার tailnet-এর কাছে প্রাইভেট IP অ্যাড্রেসের একটি সম্পূর্ণ রেঞ্জ প্রচার করে, যাতে tailnet-এর প্রতিটি ডিভাইস সেই রেঞ্জের অ্যাড্রেসগুলোতে পৌঁছাতে পারে, যদিও সেখানে কোনো ডিভাইসে Tailscale ইনস্টল করা নেই। আপনার tailnet হলো আপনার ব্যক্তিগত Tailscale নেটওয়ার্ক: এটি এমন ডিভাইসের সেট যা একটি অ্যাকাউন্ট বা অর্গানাইজেশনে সাইন-ইন করা থাকে। মানুষ প্রায়ই এটিকে exit node ফিচারের সাথে গুলিয়ে ফেলে, কিন্তু এটি তার বিপরীত কাজ করে। একটি exit node ডিভাইসের সমস্ত ট্রাফিক VPS-এর মাধ্যমে পাঠিয়ে দেয়, ফলে VPS সেই ডিভাইসের জন্য পাবলিক ইন্টারনেটে যাওয়ার পথ হিসেবে কাজ করে।

প্রতিটি বাক্যের অর্থ নিচে দেওয়া হলো। একটি subnet router একটি প্রাইভেট নেটওয়ার্ককে tailnet থেকে অ্যাক্সেসযোগ্য করে তোলে। একটি exit node আপনার পাবলিক ট্রাফিক কোথা থেকে বের হবে তা পরিবর্তন করে। আপনি যদি দ্বিতীয়টি করতে চান, তবে VPS-এ কীভাবে Tailscale exit node চালাতে হয় পড়ুন। এগুলো আলাদা ফ্ল্যাগ এবং একটি VPS একই সাথে উভয় কাজই করতে পারে, তবে তারা ভিন্ন ভিন্ন সমস্যার সমাধান করে এবং তাদের ব্যর্থ হওয়ার কারণও ভিন্ন।

কখন একটি VPS-এর subnet router প্রয়োজন হয়

সবচেয়ে সাধারণ ক্ষেত্রটি হলো আপনার প্রোভাইডার কর্তৃক প্রদত্ত একটি প্রাইভেট নেটওয়ার্ক। আপনার VPS-এর একটি পাবলিক অ্যাড্রেস এবং একটি প্রাইভেট সেগমেন্টে দ্বিতীয় একটি ইন্টারফেস থাকে, যেখানে থাকা অন্যান্য সার্ভারগুলোর কোনো পাবলিক অ্যাড্রেস থাকে না: যেমন 10.0.0.20-এ একটি ডাটাবেস, 10.0.0.30-এ একটি ব্যাকআপ টার্গেট। একটি VPS-এ Tailscale ইনস্টল করুন, 10.0.0.0/24 অ্যাডভার্টাইজ করুন, এবং আপনার ল্যাপটপ সরাসরি সেই প্রাইভেট অ্যাড্রেসগুলোতে পৌঁছাতে পারবে। ওই সেগমেন্টের অন্য কোনো কিছু পরিবর্তন করার প্রয়োজন নেই এবং ডাটাবেসটির কোনো পাবলিক অ্যাড্রেসও থাকবে না।

অন্য ক্ষেত্রটি হলো VPS-এর অপর প্রান্তে থাকা একটি নেটওয়ার্ক। এটি হতে পারে কোনো হোম বা অফিস LAN (local area network) যা নিজস্ব রাউটারের পেছনে আছে, অথবা এমন কিছু অ্যাপ্লায়েন্সের র‍্যাক যেখানে Tailscale চালানো সম্ভব নয়, যেমন একটি managed switch বা পুরনো NAS যার ফার্মওয়্যার লক করা। সেই নেটওয়ার্কের একটি Linux মেশিন তখন বাকি সবকিছুর জন্য subnet router হিসেবে কাজ করে।

উভয় ক্ষেত্রেই একটি সাধারণ প্রয়োজনীয়তা রয়েছে। subnet router-কে অবশ্যই তার নিজস্ব রাউটিং টেবিল এবং ফায়ারওয়াল ব্যবহার করে সেই রেঞ্জটিতে পৌঁছাতে সক্ষম হতে হবে যা সে অ্যাডভার্টাইজ করছে। Tailscale সেই সংযোগটি তৈরি করে না। এটি কেবল রাউটার পর্যন্ত ট্রাফিক বহন করে এবং তা ফরওয়ার্ড করার জন্য কার্নেলের কাছে হস্তান্তর করে।

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

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

স্ক্রিপ্টটি আপনার ডিস্ট্রিবিউশন শনাক্ত করে, Tailscale-এর প্যাকেজ রিপোজিটরি যোগ করে, tailscale কমান্ড এবং tailscaled ডেমন ইনস্টল করে এবং সবশেষে সার্ভিসটি চালু করে। systemctl is-active tailscaled কমান্ড দিয়ে এটি নিশ্চিত করুন, যা আউটপুট হিসেবে active প্রদর্শন করবে।

অন্য কিছু করার আগে, নিশ্চিত হয়ে নিন যে আপনার VPS সেই নেটওয়ার্কে পৌঁছাতে পারছে যা আপনি অ্যাডভার্টাইজ করতে চান।

ip route show
ping -c3 10.0.0.20

ip route show কমান্ডের আউটপুটে একটি রিয়েল ইন্টারফেসে প্রাইভেট রেঞ্জটি দেখা যাওয়া উচিত, যা অনেকটা 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5 এর মতো হবে। যদি রাউটারে পিং (ping) ব্যর্থ হয়, তবে Tailscale-এর কোনো ফ্ল্যাগই তা ঠিক করতে পারবে না। সমস্যাটি মূলত VPS-এর নেটওয়ার্ক কনফিগারেশন অথবা টার্গেট হোস্টের ফায়ারওয়ালে। এটি আগে সমাধান করুন, কারণ পরবর্তী সব পরীক্ষা এর ওপর নির্ভরশীল।

IP forwarding চালু করা এবং রিবুটের পরেও তা বজায় রাখা

একটি Linux মেশিন নিজের উদ্দেশ্যে আসা প্যাকেট ছাড়া অন্য কোনো প্যাকেট গ্রহণ করে না, যদি না forwarding চালু থাকে। অন্য মেশিনের প্যাকেট ফরওয়ার্ড করাই একটি 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 তাৎক্ষণিকভাবে কাজ করে কিন্তু পরবর্তী রিবুটের পর আর থাকে না। ফলে subnet router কয়েক সপ্তাহ চলার পর কার্নেল আপগ্রেড বা রিবুটের পরের দিনই কাজ করা বন্ধ করে দেয়। বিভ্রান্তিকর বিষয় হলো, বাইরে থেকে সবকিছু ঠিক মনে হয়। tailscale status নোডটিকে অনলাইনে দেখায়, অ্যাডমিন কনসোলে রুট অনুমোদিত থাকে এবং ক্লায়েন্টদের ডিভাইসেও রুট ইনস্টল করা থাকে। প্যাকেটগুলো VPS-এ পৌঁছায় কিন্তু কার্নেল কোনো লগ ছাড়াই সেগুলো ড্রপ করে দেয়। /etc/sysctl.d/99-tailscale.conf-এ মানগুলো লিখে রাখলে রিবুটের পরেও সেটি কার্যকর থাকে।

যদি forwarding বন্ধ থাকা অবস্থায় আপনি রুট advertise করেন, তবে tailscale up সেই সময় আপনাকে সতর্ক করবে, যা Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.-এর কাছাকাছি একটি লাইন দেখাবে। কমান্ডের আউটপুট এড়িয়ে না গিয়ে সেটি মনোযোগ দিয়ে পড়ুন।

রুটগুলো অ্যাডভার্টাইজ করুন

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

আপনার tailnet-এ আগে থেকেই সাইন-ইন করা একটি VPS-এ, সেটিংসটি সরাসরি পরিবর্তন করুন:

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

পরবর্তী যেকোনো পরিবর্তনের জন্য tailscale set ব্যবহার করুন। শুধুমাত্র একটি ফ্ল্যাগ দিয়ে পুনরায় tailscale up চালালে আগের সেট করা ফ্ল্যাগগুলো রিসেট হয়ে যায় এবং CLI একটি এরর মেসেজ দেখাবে, কারণ এই পদ্ধতিতে সেটিংস পরিবর্তনের জন্য ডিফল্ট নয় এমন সব ফ্ল্যাগ উল্লেখ করা বাধ্যতামূলক। tailscale set শুধুমাত্র একটি সেটিং পরিবর্তন করে এবং বাকিগুলো অপরিবর্তিত রাখে।

একাধিক রেঞ্জ কমা দিয়ে আলাদা করে একটি তালিকায় লিখুন, কোনো স্পেস দেবেন না: --advertise-routes=10.0.0.0/24,192.168.50.0/24। প্রতিটি এন্ট্রি অবশ্যই CIDR নোটেশনে (classless inter-domain routing, অর্থাৎ 10.0.0.0/24 ফরম্যাট) একটি নেটওয়ার্ক অ্যাড্রেস হতে হবে। ভুলবশত নিজের হোস্ট অ্যাড্রেস লিখলে, যেমন 10.0.0.5/24, সেটি রিজেক্ট করা হবে কারণ প্রিফিক্সের পরের বিটগুলো শূন্য নয়; এরর মেসেজে সম্ভাব্য সঠিক প্রিফিক্সটি উল্লেখ করা থাকবে। অ্যাডভার্টাইজ করা বন্ধ করতে, sudo tailscale set --advertise-routes= ব্যবহার করে একটি খালি তালিকা সেট করুন।

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

একটি রুট অ্যাডভার্টাইজ করা মানে একটি অনুরোধ পাঠানো, কোনো পরিবর্তন কার্যকর করা নয়। একজন অ্যাডমিন এটি অনুমোদন না করা পর্যন্ত কোনো ক্লায়েন্ট রুটটি পায় না এবং ওই রেঞ্জের কোনো কিছুতে পৌঁছানো সম্ভব হয় না। এটি ইচ্ছাকৃতভাবে করা হয়েছে, কারণ কোনো মেশিন যদি নিজেকে সবার রাউটিং টেবিলে যুক্ত করতে পারে, তবে সে যেকোনো রেঞ্জের ট্রাফিক ক্যাপচার করতে সক্ষম হবে।

অ্যাডমিন কনসোলের Machines পেজ থেকে এটি অনুমোদন করুন। VPS-টি একটি subnet ব্যাজসহ তালিকাভুক্ত থাকবে। এর সারিটি খুলুন, subnets সেকশনটি খুঁজে বের করুন, রুট সেটিংস এডিট করুন, রুটটিতে টিক দিন এবং সেভ করুন।

অনুমোদন প্রতি প্রিফিক্সের জন্য আলাদাভাবে দিতে হয়। আপনি যদি আজ 10.0.0.0/24 অ্যাডভার্টাইজ করেন এবং পরের মাসে 192.168.50.0/24 করেন, তবে নতুন প্রিফিক্সটি অনুমোদনহীন অবস্থায় আসবে কিন্তু পুরনোটি কাজ করতে থাকবে। VPS থেকে একটি অনুমোদিত রুট এবং একটি উপেক্ষা করা রুট দেখতে একই রকম মনে হয়, তাই অন্য কিছু ডিবাগ করার আগে কনসোল চেক করুন।

আপনি tailnet পলিসি ফাইলে একটি autoApprovers ব্লক ব্যবহার করে এই ম্যানুয়াল ধাপটি এড়াতে পারেন:

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

এরপর sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router ট্যাগ ব্যবহার করে নোডটি চালু করুন, তাহলে রুটটি অ্যাডভার্টাইজ হওয়ার সাথে সাথেই অনুমোদিত হয়ে যাবে। ট্যাগটিকে অবশ্যই একই পলিসি ফাইলের tagOwners সেকশনে আগে থেকে থাকতে হবে। আপনি যদি স্ক্রিপ্টের মাধ্যমে VPS পুনরায় তৈরি (rebuild) করেন, তবে এটি সেটআপ করে রাখা সুবিধাজনক, কারণ একটি নতুন তৈরি করা নোড একটি নতুন নোড হিসেবে গণ্য হয় এবং এর রুটগুলো পুনরায় অনুমোদনহীন অবস্থায় থাকে।

কেন Linux ক্লায়েন্টরা --accept-routes ছাড়া রুট উপেক্ষা করে

রুটটি এখন বিজ্ঞাপন করা হয়েছে এবং অনুমোদিত। আপনার ফোন এবং Mac 10.0.0.20-এ পৌঁছাতে পারে। আপনার Linux ল্যাপটপ তা পারছে না এবং অ্যাডমিন কনসোলে কোনো সমস্যার ইঙ্গিত নেই।

একটি সাবনেট রুট গ্রহণ করার অর্থ হলো ক্লায়েন্টের রাউটিং টেবিলে এন্ট্রি লেখা। Android, iOS, macOS, tvOS এবং Windows-এ, Tailscale ক্লায়েন্ট আপনার জন্য এটি করে দেয়। Linux-এ এটি স্বয়ংক্রিয়ভাবে হয় না, কারণ একটি Linux মেশিন প্রায়শই একটি সার্ভার বা রাউটার হিসেবে কাজ করে যার রাউটিং টেবিল কেউ উদ্দেশ্যমূলকভাবে কনফিগার করে রেখেছেন। নেটওয়ার্ক থেকে শেখা একটি /24 নীরবে সেখানে যুক্ত করলে মেশিনের বর্তমান ট্রাফিক ব্যবস্থা ভেঙে যেতে পারে। তাই Linux-এ আপনাকে প্রতিটি ক্লায়েন্টে আলাদাভাবে এটি বেছে নিতে (opt-in) হবে:

sudo tailscale set --accept-routes

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

ip route show table 52
ip route get 10.0.0.20

Linux-এ Tailscale গৃহীত রুটগুলোকে মূল রাউটিং টেবিলে রাখে না। এটি সেগুলোকে রাউটিং টেবিল 52-এ রাখে এবং পলিসি রুল ইনস্টল করে, যা ip rule show দিয়ে 5210 থেকে 5270 প্রায়োরিটি রেঞ্জে দেখা যায়। এই রুলগুলো অমিল থাকা প্যাকেটগুলোকে সেই টেবিলে পাঠিয়ে দেয়। তাই শুধুমাত্র ip route show চালালে কখনোই 10.0.0.0/24 তালিকাভুক্ত হবে না এবং যে পাঠক শুধুমাত্র সেই কমান্ডটি পরীক্ষা করেন, তিনি মনে করবেন --accept-routes কোনো কাজ করেনি। ip route show table 52 হলো সেই কমান্ড যা প্রকৃত অবস্থা দেখায় এবং এতে tailscale0-এ বিজ্ঞাপনকৃত রেঞ্জটি তালিকাভুক্ত থাকা উচিত।

একটি ব্যতিক্রম জেনে রাখা ভালো। যদি এই Linux নোডটি নিজেই তার স্থানীয় নেটওয়ার্কের জন্য একটি দ্বিতীয় সাবনেট রাউটার হয়, তবে --accept-routes এটিকে তার নিজস্ব সরাসরি সংযুক্ত সাবনেটের ট্রাফিক তার নিজস্ব ইন্টারফেসের পরিবর্তে অন্য রাউটারের মাধ্যমে পাঠাতে বাধ্য করে। হাই-অ্যাভেইল্যাবিলিটি জোড়ার স্ট্যান্ডবাই রাউটারে --accept-routes বন্ধ রাখুন এবং শুধুমাত্র বিজ্ঞাপন (advertise) করুন।

ব্যর্থতার ধরন: দুটি রাউটার যখন একই রেঞ্জ বিজ্ঞাপন (advertise) করে

দুটি সাবনেট রাউটার কখনোই অভিন্ন রেঞ্জ বিজ্ঞাপন করতে পারবে না। ভিন্ন ভিন্ন প্রিফিক্স দৈর্ঘ্যের ওভারল্যাপিং রেঞ্জ অনুমোদিত, এবং Tailscale এক্ষেত্রে সবচেয়ে সুনির্দিষ্ট (most specific) ম্যাচটি বেছে নেয়। যদি রাউটার A 10.0.0.0/24 এবং রাউটার B 10.0.0.0/16 বিজ্ঞাপন করে, তবে 10.0.0.20-এর ট্রাফিক রাউটার A-এর দিকে যাবে।

ব্যবহারকারীরা সাধারণত অবাক হন যখন রাউটার A অফলাইন হয়ে যায়। Tailscale স্বয়ংক্রিয়ভাবে কম সুনির্দিষ্ট রুটে ফিরে যায় না। 10.0.0.20-এর ট্রাফিক বন্ধ হয়ে যায়, কিন্তু 10.1.0.20-এর ট্রাফিক রাউটার B-এর মাধ্যমে সচল থাকে। এই সমস্যার লক্ষণ দেখে মনে হয় যেন প্রাইভেট নেটওয়ার্কের অর্ধেক অংশ অকেজো হয়ে গেছে, যার মূল কারণ হলো একটি অফলাইন নোড সুনির্দিষ্ট প্রিফিক্সটি ধরে রেখেছে। আপনি যদি ফেইলওভার (failover) চান, তবে প্রশস্ত রাউটারটিকেও সরু প্রিফিক্সগুলো বিজ্ঞাপন করতে দিন, যাতে উভয়ই একই ঠিকানার কভারেজ নিশ্চিত করে।

অন্য ধরনের ওভারল্যাপটি ক্লায়েন্টের কাছাকাছি ঘটে। আপনি যখন 192.168.1.0/24-এর কোনো হোটেল নেটওয়ার্কে থাকেন এবং আপনার সাবনেট রাউটার 192.168.1.0/24 বিজ্ঞাপন করে, তখন উভয়ই একই গন্তব্যের জন্য প্রতিযোগিতা করে। কোনটি জিতবে তা নির্ভর করে প্ল্যাটফর্মের ওপর। Linux-এ, Tailscale-এর নিজস্ব রুলের আগে একটি রুল ইনস্টল করুন যাতে লোকাল অ্যাড্রেসগুলো মেইন টেবিল ব্যবহার করে:

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

এই রুলটি স্থায়ী নয় এবং পরবর্তী বুটের সময় মুছে যায়। এর প্রকৃত সমাধান হলো এমন একটি প্রাইভেট রেঞ্জ বেছে নেওয়া যা আপনি সাধারণত বাইরে কোথাও পাবেন না। 192.168.0.0/24 এবং 192.168.1.0/24 বেশিরভাগ হোম রাউটারে ডিফল্ট হিসেবে থাকে, তাই 10.0.0.0/8-এর ভেতর থেকে ইচ্ছাকৃতভাবে কোনো একটি রেঞ্জ বেছে নিন। একই ধরনের সংঘর্ষের কারণে ম্যানুয়ালি কনফিগার করা সাধারণ WireGuard VPN-ও অকেজো হয়ে পড়ে, কারণ সুনির্দিষ্ট লোকাল রুটটি জিতে যায় এবং ট্রাফিক কখনোই টানেলের ভেতর প্রবেশ করে না।

ব্যর্থতার ধরন: DNS এমন ঠিকানায় রেজলভ হয় যার কোনো রুট নেই

এটি ডিবাগ করা কঠিন, কারণ কোনো কিছুই ত্রুটির রিপোর্ট করে না। নাম রেজলভ হয়, কিন্তু সংযোগ টাইম-আউট হয়ে যায়।

ধরা যাক, db.internal.example.com আপনার প্রাইভেট নেমসার্ভারের মাধ্যমে 10.0.5.20-তে রেজলভ হয় এবং আপনি 10.0.0.0/24 অ্যাডভার্টাইজ করেছেন। লুকআপ সফল হয়, কারণ DNS (domain name system) রেজল্যুশন এবং IP রাউটিং আলাদা ধাপ এবং একটি অন্যটিকে যাচাই করে না। এরপর 10.0.5.20-এর উদ্দেশ্যে পাঠানো প্যাকেটটি টেলনেটে (tailnet) কোনো ম্যাচিং রুট খুঁজে পায় না, তাই এটি ক্লায়েন্টের ডিফল্ট গেটওয়ে দিয়ে বেরিয়ে যায় এবং হারিয়ে যায়।

দুটি কমান্ড এই দুই অংশকে আলাদা করে:

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

যদি লুকআপ একটি ঠিকানা প্রদান করে কিন্তু ip route get যদি dev tailscale0 দিয়ে উত্তর না দেয়, তবে বুঝতে হবে নাম ঠিক আছে কিন্তু রুটটি অনুপস্থিত। এমন একটি রেঞ্জ অ্যাডভার্টাইজ করুন যা ঠিকানাটিকে কভার করে, হয় 10.0.0.0/16 অথবা দ্বিতীয় কোনো স্পষ্ট প্রিফিক্স, এরপর কনসোলে নতুন প্রিফিক্সটি অনুমোদন করুন।

নেমসার্ভারটিতেই একটি ফাঁদ রয়েছে। আপনি যদি অ্যাডমিন কনসোলে 10.0.0.53-এর মতো কোনো প্রাইভেট ঠিকানায় গ্লোবাল নেমসার্ভার সেট করেন, তবে সেই ঠিকানাটিকে অবশ্যই একটি অনুমোদিত রুটের ভেতরে থাকতে হবে, অন্যথায় আপনার ডিভাইসগুলো কোনোভাবেই রিজলভারের কাছে পৌঁছাতে পারবে না। এমন রিজলভারের দিকে নির্দেশ করে লোকাল DNS সার্ভার ওভাররাইড করার অপশনটি চালু করবেন না যেখানে কেউ পৌঁছাতে পারে না, অন্যথায় টেলনেটের প্রতিটি ডিভাইস তাৎক্ষণিকভাবে নাম রেজল্যুশন ক্ষমতা হারিয়ে ফেলবে, এমনকি যেগুলোর কাজ করছিল সেগুলোও। প্রথমে রিজলভারের রুটটি অ্যাডভার্টাইজ এবং অনুমোদন করুন, তারপর DNS সেটিং পরিবর্তন করুন। যদি টানেলের ভেতরে DNS নিয়ে আপনি ক্রমাগত সমস্যায় পড়েন, তবে WireGuard টানেলের ওপর DNS যেভাবে কাজ করে না বিষয়টি একই মেকানিজম নিয়ে আলোচনা করে, যেখানে ওপরের কোঅর্ডিনেশন লেয়ারটি থাকে না।

Source NAT এবং site-to-site লিঙ্ক

ডিফল্টভাবে, সাবনেট রাউটার প্রতিটি ফরওয়ার্ড করা প্যাকেটের সোর্স অ্যাড্রেস পরিবর্তন করে নিজের প্রাইভেট অ্যাড্রেসে রূপান্তর করে। একে বলা হয় SNAT (source network address translation)। এটি ব্যবহারের কারণ হলো, প্রাইভেট নেটওয়ার্কে কোনো পরিবর্তন না করেই যাতে রিপ্লাইগুলো সঠিকভাবে পৌঁছাতে পারে: 10.0.0.20-এ থাকা ডেটাবেসটি VPS-এর কাছে উত্তর পাঠায়, কারণ সে জানে কীভাবে VPS-এর কাছে পৌঁছাতে হয়। এর অসুবিধা হলো, ডেটাবেস প্রতিটি tailnet কানেকশনকে VPS থেকে আসা বলে মনে করে, ফলে সোর্স-ভিত্তিক ফায়ারওয়াল রুল এবং অ্যাক্সেস লগ থেকে কোনো কার্যকর তথ্য পাওয়া যায় না।

ক্লায়েন্টের আসল tailnet অ্যাড্রেস বজায় রাখতে চাইলে Linux-এ এটি বন্ধ করুন:

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

এরপর প্রাইভেট নেটওয়ার্কের হোস্টগুলোর জন্য 100.64.0.0/10-এর দিকে একটি রিটার্ন রুট প্রয়োজন, যা Tailscale ডিভাইসগুলোকে বরাদ্দ করা রেঞ্জ। এই রিটার্ন রুট না থাকলে রিপ্লাইগুলো ডিফল্ট গেটওয়েতে চলে যায় এবং কখনোই গন্তব্যে পৌঁছায় না, ফলে প্রথম প্যাকেটের পরেই কানেকশন হ্যাং হয়ে যায়। প্রাইভেট নেটওয়ার্কের গেটওয়েতে স্ট্যাটিক রুট যোগ করুন, অথবা SNAT চালু রাখুন।

একটি site-to-site লিঙ্ক হলো যখন দুটি সাবনেট রাউটার একই সাথে এই কাজটি করে, যেখানে প্রত্যেকে নিজের নেটওয়ার্ক অ্যাডভার্টাইজ করে এবং অন্যটির নেটওয়ার্ক গ্রহণ করে:

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

অন্য রাউটারে তার নিজস্ব রেঞ্জ ব্যবহার করে একই কমান্ড চালান। দুটি রেঞ্জ অবশ্যই ভিন্ন হতে হবে। যদি ssh এবং ping ঠিক থাকার পরেও বড় ফাইল ট্রান্সফার আটকে যায়, তবে এর কারণ হলো MSS (maximum segment size), যা একটি TCP প্যাকেট বহন করতে পারে এমন ডেটার বৃহত্তম অংশ। টানেলের ওভারহেডের কারণে ফরওয়ার্ড করা প্যাকেটগুলো মাঝখানের কোনো লিঙ্কের জন্য অনেক বড় হয়ে যায়, এবং 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 দিয়ে সেভ করুন, অন্যথায় পরবর্তী বুটের সময় এটি মুছে যাবে।

সিস্টেম সচল রাখার রক্ষণাবেক্ষণ

আগস্ট 2026 থেকে, ডিফল্টভাবে নোড কি (node keys) 180 দিন পর মেয়াদোত্তীর্ণ হয়ে যায়। যখন কোনো সাবনেট রাউটারে এই কি-এর মেয়াদ শেষ হয়ে যায়, তখন নোডটি সাইন আউট হয়ে যায় এবং পুরো অ্যাডভার্টাইজড রেঞ্জটি দুর্গম হয়ে পড়ে, অথচ কনফিগারেশনে কোনো পরিবর্তন না থাকায় এর কারণ বোঝা কঠিন হয়। অ্যাডমিন কনসোলের Machines পেজ থেকে এই মেশিনের জন্য key expiry নিষ্ক্রিয় করুন এবং এটি যে করেছেন তা কোথাও লিখে রাখুন।

Tailscale পিয়ারদের মধ্যে সরাসরি সংযোগ পছন্দ করে এবং সরাসরি সংযোগ সম্ভব না হলে এটি রিলে সার্ভারের (relay servers) ওপর নির্ভর করে। রিলেগুলো কাজ করে ঠিকই, কিন্তু এতে ল্যাটেন্সি বেড়ে যায়। পাবলিক অ্যাড্রেসসহ একটি VPS-এর ক্ষেত্রে বিষয়টি সহজ: ইনবাউন্ড UDP 41641 পোর্টটি উন্মুক্ত রাখুন, তাহলে অধিকাংশ পিয়ার সরাসরি সংযোগ স্থাপন করতে পারবে। যদি ufw দিয়ে ফায়ারওয়াল ম্যানেজ করা হয়, তবে একটি VPS-এর জন্য প্রয়োজনীয় ufw রুলস অংশে এর সিনট্যাক্স দেওয়া আছে।

অ্যাক্সেস রুলস হলো এই প্রক্রিয়ার অন্য অর্ধেক। ডিফল্ট টেইলনেটে আপনার প্রতিটি ডিভাইস অন্য যেকোনো ডিভাইসের সাথে যোগাযোগ করতে পারে, তাই একটি অনুমোদিত রুট এমনিতেই কাজ করে। একবার আপনি একটি ACL পলিসি লিখলে, রুলের গন্তব্য অংশে প্রাইভেট রেঞ্জটি উল্লেখ করতে হবে, কারণ 10.0.0.20 কোনো টেইলনেট অ্যাড্রেস নয় এবং টেইলনেট IP বা ট্যাগ ব্যবহার করে লেখা রুলগুলো একে কভার করে না।

পরিশেষে, আপনি এমন কোনো কোঅর্ডিনেশন সার্ভার ব্যবহার করতে চান কি না যা আপনি নিজে চালান না, তা সিদ্ধান্ত নিন। Tailscale-এর কন্ট্রোল প্লেন একটি হোস্ট করা সার্ভিস। আপনার কি (keys) আপনার মেশিনে থাকে, কিন্তু অ্যাকাউন্ট এবং পলিসি ফাইল সেখানে থাকে। Headscale, যা একটি সেলফ-হোস্টেড Tailscale কন্ট্রোল সার্ভার ব্যবহার করলে তা আপনার নিজের VPS-এ থাকবে, তবে এর রক্ষণাবেক্ষণের দায়িত্ব আপনার। আপনি যদি এই মডেল এবং হাতে লেখা কনফিগারেশনের মধ্যে সিদ্ধান্ত নিতে না পারেন, তবে WireGuard এবং Tailscale-এর তুলনা বিষয়টি আপনাকে কোঅর্ডিনেশন লেয়ারের সুবিধা ও সীমাবদ্ধতা বুঝতে সাহায্য করবে।

FAQ

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

একটি subnet router প্রাইভেট অ্যাড্রেসের একটি রেঞ্জ বিজ্ঞাপন (advertise) করে, যাতে tailnet-এর ডিভাইসগুলো এমন সব মেশিনে পৌঁছাতে পারে যেগুলোতে Tailscale চলছে না। একটি exit node নিজেকে পুরো ইন্টারনেটের রুট হিসেবে বিজ্ঞাপন করে, ফলে একটি ডিভাইস তার সমস্ত ট্রাফিক সেই নোডের পাবলিক অ্যাড্রেসের মাধ্যমে পাঠায়। একটি VPS একই সাথে উভয়ই হতে পারে। এগুলো আলাদা ফ্ল্যাগ, --advertise-routes এবং --advertise-exit-node, এবং প্রতিটির জন্য অ্যাডমিন কনসোলে আলাদা অনুমোদনের প্রয়োজন হয়।

আমার Linux ক্লায়েন্ট কেন বিজ্ঞাপিত subnet route উপেক্ষা করছে?

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

রিবুট করার পর আমার subnet কাজ করা বন্ধ করে দিয়েছে। কী সমস্যা হয়েছে?

সম্ভবত IP forwarding। sysctl -w দিয়ে সেট করা মান রিবুটের পর আর থাকে না, তাই এটি /etc/sysctl.d/99-tailscale.conf ফাইলে লিখুন এবং sysctl net.ipv4.ip_forward দিয়ে নিশ্চিত করুন। যদি forwarding চালু থাকে এবং রেঞ্জটি এখনও দুর্গম হয়, তবে অ্যাডমিন কনসোলে নোডটি দেখুন। নোড কি (node keys) ডিফল্টভাবে 180 দিন পর মেয়াদোত্তীর্ণ হয়ে যায়, এবং একটি মেয়াদোত্তীর্ণ subnet router-কে অ্যাকাউন্টের সমস্যার পরিবর্তে নেটওয়ার্ক ত্রুটি বলে মনে হতে পারে।

দুটি subnet router কি একই রেঞ্জ বিজ্ঞাপন করতে পারে?

অভিন্ন রেঞ্জ বিজ্ঞাপন করা যাবে না। ভিন্ন প্রিফিক্স দৈর্ঘ্যের ওভারল্যাপিং রেঞ্জ ঠিক আছে, এবং সবচেয়ে সুনির্দিষ্ট (specific) রুটটি কার্যকর হয়। ফেইলওভারের ক্ষেত্রে সতর্ক থাকতে হবে: যখন সুনির্দিষ্ট প্রিফিক্স ধারণকারী রাউটারটি অফলাইনে চলে যায়, Tailscale স্বয়ংক্রিয়ভাবে বৃহত্তর রুটে ফিরে যায় না, ফলে ট্রাফিক বন্ধ হয়ে যায়। প্রকৃত স্ট্যান্ডবাই জোড়ার জন্য, উভয় রাউটারকে একই সুনির্দিষ্ট প্রিফিক্স বিজ্ঞাপন করতে দিন।

হোস্টনাম রিজলভ হচ্ছে কিন্তু কানেকশন টাইম আউট হচ্ছে। কেন?

DNS রেজোলিউশন এবং রাউটিং আলাদা ধাপ। একটি নাম এমন একটি অ্যাড্রেসে রিজলভ হতে পারে যা কোনো অনুমোদিত রুটের আওতায় নেই, এবং তখন প্যাকেটটি ক্লায়েন্টের ডিফল্ট গেটওয়ের মাধ্যমে বেরিয়ে যায়। ক্লায়েন্টে ip route get <address> চালান। যদি উত্তরে dev tailscale0 অন্তর্ভুক্ত না থাকে, তবে এমন একটি রেঞ্জ বিজ্ঞাপন করুন যা সেই অ্যাড্রেসকে কভার করে এবং অ্যাডমিন কনসোলে নতুন প্রিফিক্সটি অনুমোদন করুন।