Tailscale কি নিরাপদ? এর সিকিউরিটি মডেল ও ট্রাস্ট ইস্যু

Tailscale কি নিরাপদ? সংক্ষিপ্ত উত্তর

Tailscale কি নিরাপদ? অধিকাংশ মানুষ যে বিষয়টি নিয়ে চিন্তিত, তার উত্তর হলো হ্যাঁ: আপনার tailnet পরিচালনা করা coordination server-এ আপনার ট্রাফিক এনক্রিপ্ট করার মতো private key থাকে না, তাই আপনার ডিভাইসগুলো একে অপরকে কী পাঠাচ্ছে তা এটি পড়তে পারে না। Tailscale-এর security page-এ সরাসরি বলা হয়েছে: "Private keys কখনোই ডিভাইস থেকে বের হয় না। সমস্ত ট্রাফিক সবসময় end-to-end এনক্রিপ্ট করা থাকে।" তবে কার্যকর প্রশ্নটি ভিন্ন। যদি কোনো coordination server হ্যাক হয় বা আইনি আদেশের কারণে বাধ্য হয়, তবে সেটির আপনার প্যাকেট পড়ার প্রয়োজন নেই। এটি নির্ধারণ করে যে আপনার ডিভাইসগুলো কোন public key-কে বিশ্বাস করবে, তাই এটি এমন কোনো ডিভাইস যুক্ত করতে পারে যা আপনি অনুমোদন করেননি।

এক বাক্যে এটিই হলো trust model: এনক্রিপশন ডেটাকে সুরক্ষা দেয় এবং control plane সদস্যপদ নির্ধারণ করে। নিচের প্রতিটি বিভাগে এমন একটি পক্ষের নাম দেওয়া হয়েছে যাদের ওপর আপনাকে আস্থা রাখতে হবে, তারা বাস্তবে কী করতে পারে তা বলা হয়েছে এবং তাদের সীমাবদ্ধ করার উপায়গুলো উল্লেখ করা হয়েছে। যদি পণ্যটি আপনার কাছে নতুন হয়, তবে Tailscale কী এবং এর mesh কীভাবে কাজ করে থেকে শুরু করুন।

কন্ট্রোল প্লেন এবং ডেটা প্লেন আলাদা

Tailscale হলো WireGuard-এর ওপর ভিত্তি করে তৈরি একটি মেশ VPN (ভার্চুয়াল প্রাইভেট নেটওয়ার্ক), যা আপনি একটি self-hosted WireGuard VPS-এ ম্যানুয়ালি কনফিগার করতে পারেন। প্রতিটি ডিভাইস স্থানীয়ভাবে তার নিজস্ব WireGuard কি-পেয়ার তৈরি করে। Tailscale-এর কিভাবে এটি কাজ করে পোস্টটিতে কোঅর্ডিনেশন সার্ভারকে "পাবলিক কি-এর জন্য একটি শেয়ারড ড্রপ বক্স" হিসেবে অভিহিত করা হয়েছে এবং বলা হয়েছে, "প্রাইভেট কি কখনোই তার নোড থেকে বাইরে যায় না।"

ডেটা প্লেন হলো আপনার ডিভাইসগুলোর মধ্যে এনক্রিপ্ট করা ট্রাফিক। নেটওয়ার্ক অনুমতি দিলে এটি সরাসরি ডিভাইস থেকে ডিভাইসে আদান-প্রদান হয়। কন্ট্রোল প্লেন হলো বাকি সবকিছু: কোন ডিভাইসগুলো tailnet-এর অন্তর্ভুক্ত, কোন পাবলিক কি কোন ডিভাইসের, অ্যাক্সেস পলিসি, DNS সেটিংস এবং রিলে লিস্ট। Tailscale কন্ট্রোল প্লেনটিকে একটি হোস্ট করা সার্ভিস হিসেবে পরিচালনা করে। আপনি আপনার নিজস্ব মেশিনে ডেটা প্লেন চালান।

এই দুটিকে আলাদা রাখলে এখানে নিরাপত্তা সংক্রান্ত প্রতিটি প্রশ্নের উত্তর পাওয়া সম্ভব। এনক্রিপশন হলো ডেটা প্লেনের একটি বৈশিষ্ট্য। সদস্যপদ হলো কন্ট্রোল প্লেনের একটি সিদ্ধান্ত। এনক্রিপশন দিয়ে কখনোই বোঝা সম্ভব নয় যে কাকে পিয়ার হিসেবে যুক্ত হওয়ার অনুমতি দেওয়া হয়েছে।

একটি compromised coordination server কী করতে পারে?

এটি আপনার traffic decrypt করতে পারে না। যে key-গুলো encryption-এর কাজ করে সেগুলো আপনার ডিভাইসেই তৈরি হয় এবং কখনোই upload করা হয় না। তাই এমন কোনো তথ্য নেই যা হস্তগত বা ফাঁস হলে tunnel খুলে যাবে। relayed traffic-এর ক্ষেত্রেও এটি প্রযোজ্য, যা নিচে বিস্তারিত আলোচনা করা হয়েছে।

এটি একটি node enrol করতে পারে। যখন Tailscale tailnet lock ঘোষণা করে, তখন কোম্পানিটি এই ঝুঁকি সম্পর্কে বলেছিল: একটি ক্ষতিকারক server "আপনার বিদ্যমান node-গুলোর সাথে traffic আদান-প্রদান করার জন্য গোপনে একটি node যোগ করতে পারে"। সেক্ষেত্রে "traffic encrypted কি না তা আর গুরুত্বপূর্ণ থাকে না, কারণ peer নিজেই ক্ষতিকারক"। আপনার ডিভাইস একটি peer-কে বিশ্বাস করে কারণ control plane তাকে জানিয়েছে যে ওই key-টি এই tailnet-এর অন্তর্ভুক্ত।

এটি আপনার ডিভাইসগুলো কী কী access করতে পারবে তা পরিবর্তন করতে পারে। access policy-টি control plane-এ থাকে এবং node-গুলোর মধ্যে বিতরণ করা হয়। Tailscale-এর tailnet lock white paper অনুযায়ী, tailnet lock "একটি compromised control plane-কে আপনার নেটওয়ার্কের সংযোগ বিচ্ছিন্ন করা থেকে আটকাতে পারে না, যেমন নতুন node key বিতরণ করতে ব্যর্থ হওয়া অথবা এমন একটি access control policy বিতরণ করা যা সব node-এর access বন্ধ করে দেয়।"

এটি যেকোনোভাবেই connection metadata দেখতে পায়। Tailscale-এর network flow log-এ প্রতিটি machine-to-machine connection-এর open এবং close হওয়ার ঘটনা রেকর্ড থাকে। documentation অনুযায়ী, এই log-গুলোতে "client-এর কার্যক্রম বা network traffic-এর বিষয়বস্তু সম্পর্কে কোনো তথ্য থাকে না"। তাই control plane জানতে পারে আপনার কোন ডিভাইস কখন কার সাথে কথা বলেছে। কিন্তু তারা কী বলেছে, তা তারা জানে না।

এই তালিকার মাত্র একটি বিষয় encryption সম্পর্কিত। বাকিগুলো সদস্যপদ এবং policy সংক্রান্ত। তাই যে নিয়ন্ত্রণ ব্যবস্থাগুলো আপনার মনোযোগের দাবি রাখে, সেগুলো হলো enrolment নিয়ন্ত্রণকারী ব্যবস্থা।

আপনার identity provider হলো tailnet-এর আস্থার মূল ভিত্তি

Tailscale-এর নিজস্ব কোনো password database নেই। এর documentation-এ স্পষ্টভাবে বলা হয়েছে যে Tailscale-এর কোনো password নেই এবং sign-in প্রক্রিয়াটি একটি identity provider (IdP)-এর ওপর ন্যস্ত: Apple, Google, GitHub, Microsoft, Okta, OneLogin অথবা কোনো custom OpenID Connect provider।

এটিকে একটি security statement হিসেবে বিবেচনা করুন, কারণ এটি তাই। যে কেউ আপনার Google বা Microsoft account-এ sign-in করতে পারলে সে আপনার tailnet-এও sign-in করতে পারবে। আপনার multi-factor authentication (MFA) হলো সেটিই যা আপনার IdP কার্যকর করে। কোনো ব্যক্তি প্রতিষ্ঠান ছেড়ে দিলে আপনার offboarding প্রক্রিয়াটি IdP-এর ওপরই নির্ভর করে। একটি phished IdP account মানেই একটি tailnet account, এবং আক্রমণকারীকে WireGuard আক্রমণ করার প্রয়োজন হয় না: তারা কেবল একটি device যোগ করে এবং আপনার policy সেই user-কে যা যা অনুমতি দেয়, তা তারা পেয়ে যায়।

একটি চুরি হওয়া identity account এবং আপনার tailnet-এর ভেতর একটি সচল device-এর মাঝে দুটি নিয়ন্ত্রণ ব্যবস্থা কাজ করে: device approval এবং key expiry। Tailnet lock হলো তৃতীয় একটি ব্যবস্থা, যা account-এর পরিবর্তে control plane-কে লক্ষ্য করে কাজ করে।

ডিভাইস অনুমোদন: কেউ সম্মতি না দেওয়া পর্যন্ত কোনো ডিভাইস যুক্ত হবে না

Tailscale-এর ডকুমেন্টেশনে ডিভাইস অনুমোদনকে এমন একটি ফিচার হিসেবে বর্ণনা করা হয়েছে যা "Tailscale নেটওয়ার্ক অ্যাডমিনিস্ট্রেটরদের নতুন ডিভাইসগুলো আপনার Tailscale নেটওয়ার্কে যুক্ত হওয়ার আগে সেগুলো পর্যালোচনা ও অনুমোদন করার সুযোগ দেয়"। একজন Owner, Admin বা IT admin এই অনুমোদন দিতে পারেন। কোনো নতুন ডিভাইস যুক্ত হলে Machines পেজে সেটির পাশে "Needs approval" ব্যাজ দেখা যায়, যতক্ষণ না কেউ সেটিতে ব্যবস্থা গ্রহণ করেন।

এটি চালু করলে কোনো অ্যাকাউন্ট হ্যাক হওয়ার পরিস্থিতি বদলে যায়। আক্রমণকারী সাইন-ইন করলেও ডিভাইসটি কেবল নিবন্ধিত হয়, কিন্তু কোনো কিছুতে অ্যাক্সেস পায় না। আপনার অ্যাডমিন কনসোলে একটি ব্যাজ দেখায় যে, একটি অপরিচিত মেশিন নেটওয়ার্কে যুক্ত হওয়ার অনুমতি চাইছে। অটোমেশন বা স্বয়ংক্রিয় প্রক্রিয়াগুলো ঠিকঠাক কাজ করে, কারণ একটি auth key তৈরি করার সময় সেটিকে আগে থেকেই অনুমোদিত (pre-approved) হিসেবে চিহ্নিত করা যায় এবং API-এর মাধ্যমেও ডিভাইস অনুমোদন করা সম্ভব।

Auth key হলো নেটওয়ার্কে প্রবেশের আরেকটি পথ, তাই এগুলোকে গোপন শংসাপত্র (credentials) হিসেবে বিবেচনা করুন। Tailscale-এর ডকুমেন্টেশন ঝুঁকিপূর্ণ কী (key) সম্পর্কে সরাসরি সতর্ক করে: "পুনরায় ব্যবহারযোগ্য কী (reusable keys) ব্যবহারের ক্ষেত্রে অত্যন্ত সতর্ক থাকুন! এগুলো চুরি হলে অত্যন্ত বিপজ্জনক হতে পারে। এগুলো এই কাজের জন্য বিশেষভাবে তৈরি key vault প্রোডাক্টে রাখা সবচেয়ে ভালো।" আগস্ট 2026 অনুযায়ী, ডকুমেন্টেশনে কী-এর মেয়াদ 1 থেকে 90 দিন পর্যন্ত নির্ধারণ করা যায় এবং কোনো মেয়াদ উল্লেখ না থাকলে তা সর্বোচ্চ 90 দিন হিসেবে গণ্য হয়। সবসময় one-off কী ব্যবহারের চেষ্টা করুন, যেসব মেশিন নিয়মিত আসা-যাওয়া করে সেগুলোর জন্য ephemeral কী ব্যবহার করুন এবং যেকোনো reusable কী Ansible Vault দিয়ে এনক্রিপ্ট করে অথবা কোনো secrets manager-এ রাখুন, শেল স্ক্রিপ্টের ভেতরে রাখবেন না।

কী এক্সপায়ারি: অন্য সব ভুল সীমাবদ্ধ করার টাইমার

Node কী-এর একটি নির্দিষ্ট মেয়াদ থাকে, যা কোনো চুরি হওয়া বা ভুলে যাওয়া ডিভাইসকে একটি সাময়িক সমস্যায় পরিণত করে। Tailscale-এর ডকুমেন্টেশন অনুযায়ী, "ডিফল্টভাবে, নতুন ডোমেইনগুলোর মেয়াদ 180 দিন সেট করা থাকে" এবং "যদি পুনরায় অথেন্টিকেশন (reauthentication) না করা হয়, তবে কী-এর মেয়াদ শেষ হয়ে যায় এবং উক্ত এন্ডপয়েন্টের সাথে সংযোগ বিচ্ছিন্ন হয়ে যায়।" আপনি নিজেই একটি ডিভাইস পুনরায় অথেন্টিকেট করতে পারেন:

tailscale up --force-reauth

ডকুমেন্টেশনে সতর্ক করা হয়েছে যে, এটি "tailnet সংযোগ বিচ্ছিন্ন করে দিতে পারে, তাই সংযোগ হারিয়ে গেলে বিকল্প কোনো উপায়ে লগ ইন করার ব্যবস্থা না থাকলে SSH বা RDP-এর মাধ্যমে দূর থেকে এটি করা উচিত নয়।" কনসোল অ্যাক্সেস খোলা রেখে অথবা মেশিনে প্রবেশের অন্য কোনো পথ ব্যবহার করে এটি চালান, কারণ আপনি যে নেটওয়ার্কটি ব্যবহার করছেন তা সাময়িকভাবে বন্ধ হয়ে যেতে পারে।

সার্ভারের ক্ষেত্রে এই নিয়ন্ত্রণ ব্যবস্থা ভিন্নভাবে কাজ করে। যে মেশিনকে প্রতি 180 দিন অন্তর পুনরায় অথেন্টিকেট করতে হয়, সেটি রাত 3টার দিকে tailnet থেকে বিচ্ছিন্ন হয়ে যেতে পারে যখন কেউ তা পর্যবেক্ষণ করছে না, তাই অ্যাডমিনিস্ট্রেটররা সার্ভারের ক্ষেত্রে কী এক্সপায়ারি বন্ধ করে দেন। এটি সেই টাইমারটিকে সরিয়ে ফেলে যা শেষ পর্যন্ত একটি চুরি হওয়া কী-কে অকার্যকর করে দিত। সার্ভারের জন্য ট্যাগযুক্ত (tagged) ডিভাইস ব্যবহার করা উত্তম, কারণ একটি ট্যাগ কোনো ব্যক্তির পরিবর্তে মেশিনটির মালিকানা বহন করে, ফলে ওই ব্যক্তি কোম্পানি ছেড়ে দিলেও মেশিনটি সচল থাকে। আপনি যে সিদ্ধান্তই নিন না কেন, কোন কোন মেশিনে এক্সপায়ারি বন্ধ করা আছে তার একটি তালিকা রাখুন: কারণ সেই কী-গুলো আপনার ডিভাইসটি মুছে না ফেলা পর্যন্ত কার্যকর থাকে।

Tailnet lock: coordination server-কে trust chain থেকে সরিয়ে ফেলা

Tailnet lock সরাসরি enrolment বা তালিকাভুক্তির সমস্যা সমাধান করে। Tailscale-এর tailnet lock documentation-এ এর কার্যপদ্ধতি ব্যাখ্যা করা হয়েছে: "যখন একটি নতুন node tailnet-এ যুক্ত হয়, তখন তার public node key-এর জন্য একটি Tailnet Lock key থেকে স্বাক্ষরের প্রয়োজন হয়। coordination server সেই স্বাক্ষরিত public node key-টি অন্যান্য peer node-এর কাছে বিতরণ করে।" আপনার বিদ্যমান ডিভাইসগুলো কোনো peer-কে গ্রহণ করার আগে সেই স্বাক্ষর যাচাই করে, তাই control plane যদি নিজে থেকে কোনো node key তৈরি করে, তবে তা প্রত্যাখ্যাত হয়।

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init এই ফিচারটি সক্রিয় করে এবং সেই সময়েই আপনাকে আপনার signing node-গুলো মনোনীত করতে হয়। Tailscale প্রাথমিক সেটআপের সময় অন্তত দুটি signing node থাকা বাধ্যতামূলক করে এবং একটি tailnet-এ সর্বোচ্চ 20টি node-এর অনুমতি দেয়। এরপর থেকে, প্রতিটি নতুন ডিভাইসের জন্য এই node-গুলোর যেকোনো একটি থেকে স্বাক্ষরের প্রয়োজন হয়, যা একটি বাস্তব অপারেশনাল খরচ: একটি ফোন যুক্ত করার অর্থ হলো ল্যাপটপে একটি কমান্ড চালানো।

এর সীমাবদ্ধতাগুলো নথিবদ্ধ করা আছে এবং ফিচারের বর্ণনার চেয়ে এগুলো বেশি গুরুত্বপূর্ণ:

• Disablement secret হারিয়ে ফেললে তা পুনরুদ্ধারের কোনো উপায় নেই। নথিপত্রে বলা হয়েছে, "যদি আপনি আপনার disablement secret হারিয়ে ফেলেন এবং Tailscale support-কে তা না দিয়ে থাকেন, তবে tailnet পুনরুদ্ধার করা সম্ভব নয়।"
• signing key আপনার মালিকানাধীন ডিভাইসে থাকে, তাই এটি সেই ডিভাইসের নিরাপত্তা ব্যবস্থার ওপর নির্ভর করে। নথিপত্রে স্পষ্টভাবে বলা হয়েছে: "যদি ডিভাইসটি compromised হয়, তবে key-টি চুরি হতে পারে।"
• আপনি দুটি নিয়ন্ত্রণ ব্যবস্থা একসাথে চালাতে পারবেন না। Tailscale জানিয়েছে যে tailnet lock এবং device approval একে অপরের পরিপূরক নয়, তাই একটি সক্রিয় করলে অন্যটি বাদ দিতে হবে।
• এটি trust on first use (TOFU) নীতিতে কাজ করে। প্রাথমিক সেটআপ এখনও control plane-এর মাধ্যমেই সম্পন্ন হয় এবং সেই প্রথম ধাপের পরেই বিশ্বাসের ভিত্তি আপনার নিজস্ব নেটওয়ার্কে স্থানান্তরিত হয়।

Tailnet lock সদস্যপদ রক্ষা করে। এটি availability বা প্রাপ্যতা রক্ষা করে না, এবং white paper-এ তা স্পষ্টভাবে উল্লেখ করা হয়েছে।

একটি রিলেড (relayed) সংযোগ কি আমার ট্রাফিককে উন্মুক্ত করে দেয়?

না। যখন দুটি ডিভাইস সরাসরি একে অপরের সাথে যোগাযোগ করতে পারে না, তখন ট্রাফিক একটি DERP (Designated Encrypted Relay for Packets) সার্ভারের মাধ্যমে আদান-প্রদান হয়। Tailscale-এর ডকুমেন্টেশনে বিষয়টি স্পষ্টভাবে উল্লেখ করা হয়েছে: "যেহেতু Tailscale-এর প্রাইভেট কি (private keys) কখনোই সেই ডিভাইস থেকে বাইরে যায় না যেখানে সেগুলো তৈরি হয়েছে, তাই DERP সার্ভারের পক্ষে আপনার ট্রাফিক ডিক্রিপ্ট করা অসম্ভব। একটি DERP সার্ভার শুধুমাত্র আগে থেকেই এনক্রিপ্ট করা ট্রাফিক এক ডিভাইস থেকে অন্য ডিভাইসে পৌঁছে দেয়।"

একটি রিলে সংযোগ ব্যবহারের ফলে গতির কিছুটা তারতম্য হতে পারে এবং এটি মেটাডেটা পর্যবেক্ষণ করতে পারে: দুটি এনক্রিপ্ট করা এন্ডপয়েন্ট, এবং তাদের মধ্যে আদান-প্রদান হওয়া তথ্যের সময় ও পরিমাণ। আপনার সংযোগটি বর্তমানে কোন ধরনের, তা জানতে নিচের কমান্ডটি ব্যবহার করুন:

tailscale status
tailscale netcheck

tailscale status প্রতিটি পিয়ারকে (peer) সরাসরি সংযোগ হিসেবে direct 203.0.113.10:41641 অথবা রিলেড সংযোগ হিসেবে relay হিসেবে চিহ্নিত করে, যার সাথে রিলে সার্ভারের নাম এবং বাইট কাউন্টার দেখানো থাকে। যদি কোনো পিয়ার সবসময় রিলে মোডে থাকে, তার মানে হলো উভয় প্রান্তের মধ্যে সরাসরি সংযোগ তৈরি করা সম্ভব হচ্ছে না। সাধারণত কোথাও UDP ব্লক করা থাকলে অথবা উভয় প্রান্ত কঠোর NAT (network address translation)-এর পেছনে থাকলে এমনটি ঘটে। tailscale netcheck কমান্ডটি রিপোর্ট করে যে, সেই মেশিন থেকে UDP কাজ করছে কি না, আপনার NAT কীভাবে পোর্ট ম্যাপ করছে এবং নিকটতম রিলে সার্ভারগুলোর ল্যাটেন্সি কত। এই তথ্যগুলো বিশ্লেষণ করলে আপনি বুঝতে পারবেন সমস্যাটি ঠিক কোথায়।

একটি exit node আপনার egress পরিবর্তন করে, কিন্তু তা মুছে ফেলে না

একটি exit node একটি ডিভাইসের সমস্ত পাবলিক ইন্টারনেট ট্রাফিককে tailnet-এর অন্য একটি ডিভাইসের মাধ্যমে রুট করে, যেখানে ডিফল্ট রুট 0.0.0.0/0 এবং ::/0 ব্যবহৃত হয়। Linux-এ, যে মেশিনটি এই পরিষেবা প্রদান করে তা এটি advertise করে এবং প্রতিটি ক্লায়েন্ট তা ব্যবহারের সিদ্ধান্ত নেয়:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

একটি exit node-কে অবশ্যই admin console-এ একজন Owner, Admin বা Network admin দ্বারা অনুমোদিত হতে হবে এবং ক্লায়েন্ট এটি ব্যবহার করার আগে আপনার পলিসিতে অবশ্যই autogroup:internet প্রদান করতে হবে। এই দুটি পদক্ষেপই ইচ্ছাকৃত: একটি অননুমোদিত মেশিন চাইলেই আপনার সম্পূর্ণ tailnet-এর ট্রাফিক বের হওয়ার পথ হয়ে উঠতে পারে না।

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

ডিফল্ট পলিসি হলো একটি ফ্ল্যাট নেটওয়ার্ক

একটি নতুন tailnet ডিফল্টভাবে সবকিছুকে অনুমতি দেয়। Tailscale-এর অ্যাক্সেস কন্ট্রোল ডকুমেন্টেশন অনুযায়ী, ডিফল্ট পলিসি ফাইলটি "tailnet-এর ভেতরের সকল ডিভাইসের মধ্যে যোগাযোগের অনুমতি দেয়"। প্রতিটি ডিভাইস যেকোনো পোর্টে অন্য যেকোনো ডিভাইসের সাথে যোগাযোগ করতে পারে। এটি একটি ফ্ল্যাট নেটওয়ার্ক। আপনি এটিকে টানেলের ভেতরে নিয়ে এসেছেন, যা বাইরের আক্রমণকারীদের বিরুদ্ধে কার্যকর হলেও কোনো ল্যাপটপ সংক্রামিত হলে তার বিরুদ্ধে কোনো সুরক্ষা দেয় না।

Tailnet পলিসি ফাইলে এটিকে কঠোর করুন। এটি Access Control Lists (ACLs) অথবা নতুন grants গ্রহণ করে, যার উভয়ই এমন একটি JSON ডায়ালেক্টে লেখা হয় যা কমেন্ট সমর্থন করে:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

এই পলিসিটি একটি নির্দিষ্ট গ্রুপকে production সার্ভারে SSH করার অনুমতি দেয়, সদস্যদের exit node ব্যবহারের সুযোগ দেয় এবং বাকি সবকিছু ডিফল্টভাবে অস্বীকার করে। Tailscale-এর কোন প্ল্যানে কোন রুল টার্গেট পাওয়া যায় তার তালিকা রয়েছে, তাই tags বা autogroups নিয়ে কাজ করার আগে তা যাচাই করে নিন এবং ফ্রি প্ল্যানে আসলে কী কী অন্তর্ভুক্ত আছে তা দেখে নিন। যে ডিভাইসগুলোতে কখনোই ইনকামিং কানেকশন গ্রহণ করা উচিত নয়, যেমন ব্যক্তিগত ফোন, সেগুলোর ক্ষেত্রে tailscale set --shields-up ক্লায়েন্ট পর্যায়েই সংযোগ ব্লক করে দেয়।

Headscale দিয়ে কন্ট্রোল প্লেন সেলফ-হোস্ট করলে যা পরিবর্তিত হয়

Headscale হলো "Tailscale কন্ট্রোল সার্ভারের একটি ওপেন সোর্স, সেলফ-হোস্টেড ইমপ্লিমেন্টেশন।" এর README-তে এর পরিধি স্পষ্টভাবে উল্লেখ করা হয়েছে: "এটি একটি সীমিত পরিধি নিয়ে কাজ করে, যা মূলত একটি একক Tailscale নেটওয়ার্ক (tailnet)-এর জন্য উপযুক্ত, ব্যক্তিগত ব্যবহার বা ছোট কোনো ওপেন সোর্স প্রতিষ্ঠানের জন্য এটি কার্যকর।" এর ফিচার তালিকার মধ্যে রয়েছে ACL এবং গ্র্যান্টস, সাবনেট রাউটার, এক্সিট নোড, একটি এমবেডেড DERP সার্ভার, Tailscale SSH এবং Taildrop। যদি এই সীমিত পরিধি আপনার জন্য বাধা হয়ে দাঁড়ায়, তবে NetBird হলো অন্য একটি মেশ নেটওয়ার্ক যা সেলফ-হোস্টযোগ্য কন্ট্রোল প্লেন প্রদান করে, এবং আপনার নিজস্ব VPS-এ NetBird সার্ভার চালানো একই এনরোলমেন্টের সিদ্ধান্তকে আপনার মালিকানাধীন হার্ডওয়্যারে স্থানান্তর করে।

যা পরিবর্তিত হয় তা হলো সেই পক্ষের পরিচয়, যারা কোনো ক্ষতিকারক নোড এনরোল করতে পারে। Headscale-এর ক্ষেত্রে, কি ডিরেক্টরি এবং পলিসি আপনার সার্ভারে থাকে। কোনো তৃতীয় পক্ষ কখনোই আপনার ডিভাইসের পাবলিক কি-এর তালিকা রাখে না এবং কোনো তৃতীয় পক্ষকে এগুলো হস্তান্তর করতে বা স্বাক্ষর করতে বাধ্য করা যায় না।

যা পরিবর্তিত হয় না তা হলো ডেটা প্লেন। এটি একই WireGuard, একই এন্ড-টু-এন্ড এনক্রিপশন এবং সরাসরি সংযোগ সম্ভব না হলে একই রিলে ফলব্যাক ব্যবহার করে। আপনি Tailscale-এর করা কাজগুলোও উত্তরাধিকারসূত্রে পান: আপটাইম, প্যাচিং, ব্যাকআপ এবং সার্ভারের ভৌত নিরাপত্তা। একটি compromised Headscale হোস্ট একজন আক্রমণকারীকে ঠিক সেই ক্ষমতাই দেয় যা একটি compromised কোঅর্ডিনেশন সার্ভার দিতো, অর্থাৎ একটি নোড এনরোল করার এবং পলিসি বিতরণ করার ক্ষমতা। Tailnet lock Headscale-এর ফিচার তালিকায় নেই, তাই সেই নির্দিষ্ট ঝুঁকির জন্য কোনো বিকল্প নিয়ন্ত্রণ ব্যবস্থা সেখানে উপলব্ধ নেই। যদি মালিকানার প্রশ্নটিই আপনার সিদ্ধান্তের মূল কারণ হয়, তবে Headscale দিয়ে কন্ট্রোল প্লেন সেলফ-হোস্ট করা গাইডটি আপনাকে সেটআপের ধাপগুলো সম্পন্ন করতে সাহায্য করবে।

Tailscale যা থেকে সুরক্ষা দেয়

• পাবলিক লিসেনিং পোর্ট। একটি tailnet ঠিকানায় বাইন্ড করা কোনো সার্ভিস ইন্টারনেট থেকে অ্যাক্সেস করা যায় না, তাই যে স্ক্যানারগুলো প্রতিটি VPS-এর পোর্ট 22-এ আঘাত করে, তারা এটি দেখতে পায় না। এর ব্যতিক্রম হলো আপনি নিজে যা চালু করেন, কারণ Funnel ইচ্ছাকৃতভাবে একটি tailnet সার্ভিসকে উন্মুক্ত ইন্টারনেটে প্রকাশ করে। এই কারণেই কোনো কমান্ড চালানোর আগে serve এবং funnel-এর পার্থক্য কোথায় তা জেনে রাখা জরুরি। তবুও হোস্ট ফায়ারওয়াল চালু রাখুন, কারণ একটি পাবলিশ করা Docker পোর্ট নিজস্ব রুল তৈরি করে এবং পাবলিক ইন্টারফেসে ufw-কে বাইপাস করে।
• উন্মুক্ত লগইনের বিরুদ্ধে পাসওয়ার্ড গেসিং। পোর্টটি যদি শুধুমাত্র টানেলের ভেতরেই সাড়া দেয়, তবে সেখানে ব্রুট ফোর্স করার মতো কিছু থাকে না। এটি একটি উন্মুক্ত পোর্টে রেট লিমিটিং করার চেয়েও শক্তিশালী অবস্থান, যদিও পাবলিকলি রাখা যেকোনো সার্ভারে Ubuntu 24.04-এ fail2ban চালানো এখনো কার্যকর।
• পাথের মধ্যে থাকা অবিশ্বস্ত নেটওয়ার্ক। আপনার মেশিনগুলোর মধ্যকার ট্রাফিক ক্যাফে নেটওয়ার্ক বা শেয়ারড প্রোভাইডার LAN-এর ওপর দিয়ে এন্ড-টু-এন্ড এনক্রিপ্টেড থাকে এবং রিলে করার সময়ও তা এনক্রিপ্টেডই থাকে।
• হাতে কলমে কি (key) ডিস্ট্রিবিউশন। WireGuard কনফিগারেশনে হাতে প্রতিটি পিয়ার যোগ করার সময় ভুল ঠিকানায় কি ব্যবহার বা ভুল কি পেস্ট করার সম্ভাবনা থাকে। এই মেশ নেটওয়ার্ক আপনার জন্য সেই হিসাব-নিকাশ রাখে, যা WireGuard বনাম Tailscale-এর মধ্যে ব্যবহারিক পার্থক্যের মূল কারণ।

Tailscale যা থেকে সুরক্ষা দেয় না

• একটি compromised endpoint। tailnet ডিভাইসগুলোকে বিশ্বাস করে। অনুমোদিত ল্যাপটপে থাকা ম্যালওয়্যার টানেল, tailnet অ্যাড্রেস এবং আপনার পলিসি অনুযায়ী ব্যবহারকারী যে সুবিধাগুলো পান, তার সবকিছুর অ্যাক্সেস পেয়ে যায়। এটি সবচেয়ে বড় ঘাটতি এবং কোনো VPN-ই এটি সমাধান করতে পারে না।
• একজন ক্ষতিকারক বা অসতর্ক অ্যাডমিনিস্ট্রেটর। যে কেউ পলিসি ফাইল এডিট করতে পারলে নিজের জন্য যেকোনো কিছুর অ্যাক্সেস নিতে পারে এবং যে কেউ কোনো Owner-এর আইডেন্টিটি অ্যাকাউন্ট দখল করতে পারলে একই কাজ করতে পারে। আপনি যেভাবে কোড রিভিউ করেন, সেভাবেই পলিসি পরিবর্তনগুলো রিভিউ করুন।
• Traffic analysis। আপনার ISP (internet service provider) এনক্রিপ্ট করা UDP ট্রাফিক একটি এন্ডপয়েন্টের দিকে যেতে দেখে, সেই সাথে এর সময় এবং পরিমাণও দেখতে পায়। Tailscale-এর flow log-এ দেখা যায় কোন পিয়ারগুলো কখন যোগাযোগ করেছে। কেউই বিষয়বস্তু দেখতে পায় না, কিন্তু সংযোগের বিষয়টি গোপন থাকে না। তাই সেই কাজের জন্য টুল বেছে নেওয়ার আগে Tor এবং VPN-এর পার্থক্য পড়ে নিন।
• আপনার হারিয়ে যাওয়া কোনো ডিভাইস। Key expiry একটি ধীরগতির সুরক্ষা ব্যবস্থা, যার ডিফল্ট সময় 180 দিন। অ্যাডমিন কনসোল থেকে ডিভাইসটি রিমুভ করা হলো দ্রুততম উপায়, তাই প্রয়োজন হওয়ার আগেই জেনে রাখুন সেই বাটনটি কোথায়।

আপনার নিজস্ব tailnet পরীক্ষা করুন

1. একটি ডিভাইসে tailscale status চালান এবং peer-এর তালিকাটি দেখুন। যে মেশিনটির নাম আপনি জানেন না, সেটিই সেই পরিস্থিতি যা প্রতিরোধের জন্য device approval ব্যবস্থাটি রয়েছে।
2. tailnet lock সক্রিয় আছে কি না তা দেখতে tailscale lock status চালান, তারপর সিদ্ধান্ত নিন যে আপনার tailnet-এর জন্য প্রতিটি নতুন ডিভাইসে স্বাক্ষর করার বাড়তি পরিশ্রমটি করা যুক্তিযুক্ত কি না।
3. অ্যাডমিন কনসোল খুলুন এবং যে মেশিনগুলোতে key expiry নিষ্ক্রিয় করা আছে, সেই সাথে যে reusable auth key-গুলো এখনো বিদ্যমান, সেগুলোর তালিকা করুন। উভয়ই এমন credential যার কোনো সময়সীমা নেই।
4. আপনার policy file পড়ুন। যদি এটি এখনো ডিফল্ট অবস্থায় থাকে, তবে প্রতিটি ডিভাইস অন্য যেকোনো ডিভাইসের সাথে যেকোনো port-এ যোগাযোগ করতে পারবে এবং একটি আক্রান্ত ল্যাপটপ সবগুলোর কাছেই পৌঁছে যেতে পারবে।

Tailscale তার data plane-এর জন্য খ্যাতি অর্জন করেছে, যেখানে নকশা অনুযায়ী অপারেটরের আপনার traffic পড়ার কোনো উপায় নেই। বিক্রেতার নথিপত্র অনুযায়ী সেই দাবিটি গ্রহণ করুন, তারপর আপনার নিয়ন্ত্রণে থাকা অংশগুলো অডিট করুন: identity account, approval setting, expiry list এবং policy file। Tailscale-এর security page-এ SOC 2 Type II সার্টিফিকেশন এবং Latacora-এর সাথে চলমান নিরাপত্তা কাজের কথা উল্লেখ আছে, যা তাদের প্রক্রিয়ার প্রমাণ, আপনার কনফিগারেশনের কোনো নিশ্চয়তা নয়।

FAQ

Tailscale কি আমার ট্রাফিক পড়তে পারে?

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

একটি compromised Tailscale কোঅর্ডিনেশন সার্ভার আসলে কী করতে পারে?

এটি একটি নোড এনরোল (enrol) করতে পারে। Tailscale-এর নিজস্ব tailnet lock ঘোষণায় গোপনে যোগ করা একটি নোডের ঝুঁকির কথা বলা হয়েছে, যা "আপনার বিদ্যমান নোডগুলোতে ট্রাফিক পাঠাতে বা গ্রহণ করতে পারে"। এক্ষেত্রে এনক্রিপশন কোনো কাজে আসে না, কারণ "পিয়ার নিজেই ক্ষতিকারক"। একটি compromised কন্ট্রোল প্লেন এমন পলিসি বিতরণ করতে পারে যা আপনার ডিভাইসগুলো কী অ্যাক্সেস করতে পারবে তা পরিবর্তন করে দেয়। tailnet lock হোয়াইট পেপার অনুযায়ী, এটি নতুন নোড কি (node keys) বিতরণ করতে ব্যর্থ হয়ে কানেক্টিভিটি নষ্ট করতে পারে। তবে এটি আপনার বিদ্যমান ডিভাইসগুলোর মধ্যকার ট্রাফিক ডিক্রিপ্ট করতে পারবে না, কারণ তাদের প্রাইভেট কি (private keys) কখনোই এর কাছে থাকে না।

এক্সিট নোড কি আমার ISP থেকে আমার ব্রাউজিং লুকিয়ে রাখে?

এটি আপনার বর্তমান নেটওয়ার্ক (যেমন আপনার বাসা বা ক্যাফের ISP) থেকে গন্তব্য লুকিয়ে রাখে, কারণ আপনার ডিভাইস থেকে সবকিছু এনক্রিপ্ট করা ট্রাফিক হিসেবে এক্সিট নোডের উদ্দেশ্যে রওনা হয়। এটি আপনাকে বেনামী (anonymous) করে না। এক্সিট নোড সেই গন্তব্যগুলো দেখতে পায়, এবং এর হোস্টিং প্রোভাইডার ও আপস্ট্রিম নেটওয়ার্কও তা দেখতে পায়; অন্যদিকে, আপনি যে সাইটগুলো ভিজিট করছেন তারা এক্সিট নোডের IP অ্যাড্রেস দেখতে পায়। আপনি যেহেতু একজন ভিন্ন পর্যবেক্ষক বেছে নিয়েছেন, তাই এমন কাউকে বেছে নিন যাকে আপনি সত্যিই বিশ্বাস করেন।

Headscale কি Tailscale-এর কোঅর্ডিনেশন সার্ভারের চেয়ে বেশি নিরাপদ?

এটি পুরোপুরি বেশি নিরাপদ হওয়ার চেয়ে বরং একটি ভিন্ন বিশ্বাসের সিদ্ধান্ত (trust decision)। Headscale ব্যবহার করলে কি ডিরেক্টরি এবং পলিসি আপনার নিয়ন্ত্রণে থাকে, তাই বাইরের কোনো পক্ষ আপনার tailnet-এ জোরপূর্বক কোনো ডিভাইস এনরোল করতে পারে না। তবে এই সার্ভার চালানোর দায়িত্বও আপনার: প্যাচিং, আপটাইম, ব্যাকআপ এবং হোস্টের নিরাপত্তা আপনাকেই নিশ্চিত করতে হবে। একটি compromised Headscale হোস্ট একজন আক্রমণকারীকে সেই একই এনরোলমেন্ট ক্ষমতা দেয় যা একটি compromised কোঅর্ডিনেশন সার্ভার দিতে পারত। এছাড়া, tailnet lock Headscale-এর ফিচার লিস্টে নেই, তাই সেই হোস্টটিকে সেভাবেই সুরক্ষিত রাখুন।

আমার tailnet-এ থাকা VPS-এ কি আমার এখনো ফায়ারওয়াল প্রয়োজন?

হ্যাঁ। পাবলিক নেটওয়ার্ক ইন্টারফেসটি এখনো বিদ্যমান, এবং 0.0.0.0-এ বাইন্ড করা যেকোনো সার্ভিস ইন্টারনেট থেকে অ্যাক্সেসযোগ্য থাকে, Tailscale চলুক বা না চলুক। সার্ভিসগুলোকে tailnet অ্যাড্রেসে বাইন্ড করুন, পাবলিক ইন্টারফেসে ডিফল্ট ডিনাই (deny) পলিসি বজায় রাখুন এবং আপনার পাবলিশ করা কন্টেইনার পোর্টগুলো চেক করুন। কারণ Docker নিজস্ব রুল ইনসার্ট করে এবং এমন পোর্ট ওপেন করে দিতে পারে যা আপনি ভেবেছিলেন বন্ধ আছে।