কেন অনুমোদিত Tailscale সাবনেট রুট এখনও সময়সীমা ছাড়িয়ে যায়

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

চারটি ধাপ, একটি ব্যর্থতা

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

চতুর্থ ধাপটিই সবচেয়ে বেশি বাদ পড়ে, কারণ প্রথম তিনটি দৃশ্যমান অবস্থা তৈরি করে। রাউটারের নিজের tailnet ঠিকানা কভার করার অনুমতি তার পেছনের একটি ব্যক্তিগত সাবনেটকে স্বয়ংক্রিয়ভাবে কভার করে না। এগুলো ভিন্ন গন্তব্য, আর নীতি প্রতিটি গন্তব্যের জন্য পৃথকভাবে মূল্যায়ন করা হয়।

Linux-এ তৃতীয় ধাপের একটি ডিফল্টও আছে যা মানুষকে অবাক করে: সাবনেট রুট গ্রহণ ঐচ্ছিক। বেশ কয়েকটি GUI ক্লায়েন্ট ডিফল্টভাবে ঘোষিত রুট গ্রহণ করে, তাই মিশ্র ফ্লিটে একটি মেশিন ব্যর্থ দেখাতে পারে যখন বাকিগুলো কাজ করে।

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

ক্লায়েন্ট যেখানে চলে সেখানেই রুটটি যাচাই করুন

রাউটারে নয়, যে ক্লায়েন্ট ব্যর্থ হচ্ছে সেখান থেকেই শুরু করুন। নিশ্চিত করুন রুটটি উপস্থিত এবং ক্লায়েন্টের পছন্দ আদৌ রুট গ্রহণের অনুমতি দেয়।

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

Linux-এ রুট গ্রহণ করতে ফ্ল্যাগটি সেট আছে ধরে না নিয়ে সেটিসহ আবার সংযোগ করুন: tailscale up --accept-routes। ভিন্ন ফ্ল্যাগে যোগ দেওয়া ক্লায়েন্ট সেগুলো পরিবর্তন না করা পর্যন্ত ধরে রাখে, তাই আরেকটি যোগ করার আগে বর্তমান পছন্দটি দেখুন। পরিবর্তনের পর প্রথম কমান্ডটি আবার চালালে রুটটি টেবিলে দেখা উচিত।

ফরওয়ার্ডিং এবং ফেরার পথ প্রমাণ করুন

অনুমোদন রাউটারকে প্যাকেট ফরওয়ার্ড করতে সেট করে না, এবং উত্তরটিও ব্যবস্থা করে না। দুটোই রাউটারের LAN পাশে হোস্ট-স্তরের বিষয়। ক্লায়েন্টে নয়, রাউটারেই সেগুলো পরীক্ষা করুন।

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

প্রথম কমান্ডটি অবশ্যই 1 জানাতে হবে, নাহলে কার্নেল ফরওয়ার্ড করা প্যাকেটটি ফেলে দেবে। দ্বিতীয়টি দেখায় সাবনেট-রুট মাস্করেডিং উৎসটি আবার লিখছে কি না, যা ডিফল্ট আচরণ এবং সাধারণত যা আপনি চান। তৃতীয়টি দেখায় অনুরোধটি গন্তব্যে পৌঁছায় কি না এবং কিছু ফিরে আসে কি না; উত্তরহীন অনুরোধ ফেরার পথের সমস্যা, অনুমোদনের সমস্যা নয়। এর কোনোটিই পরিবর্তন করার আগে তিনটি ফলাফল একসঙ্গে পড়ুন।

মাস্করেডিং নিষ্ক্রিয় থাকলে গন্তব্য নেটওয়ার্কের tailnet ঠিকানাগুলোতে ফেরার একটি রুট দরকার, আর মাঝের প্রতিটি হপকে তা জানতে হবে। একটি সেবার জন্য মাস্করেডিং আবার চালু করা দ্রুততর সমাধান, তবে তাতে গন্তব্য থেকে মূল ক্লায়েন্ট ঠিকানাটি লুকিয়ে যায়। গন্তব্য অডিটের জন্য উৎস ঠিকানা লগ করলে এই বিনিময়টি গুরুত্বপূর্ণ, তাই ঘটনার সময় ফ্ল্যাগ উল্টে দেওয়ার বদলে সচেতনভাবে সিদ্ধান্ত নিন। কোন পছন্দটি করেছেন তা নথিভুক্ত করুন, কারণ পরের ব্যক্তি দুটি আচরণের একটিই দেখবেন।

রিসোর্সের জন্য অ্যাক্সেস নিয়মটি পড়ুন

রুট উপস্থিত এবং ফরওয়ার্ডিং প্রমাণিত হলে বাকি সন্দেহভাজনটি নীতি। যে অনুমতিটি সংযোগটির অনুমতি দেওয়ার কথা, সেটি পড়ুন এবং শুধু উৎস নয়, তার গন্তব্যও যাচাই করুন। ক্লায়েন্টের নিজের পরিচয়কেও নীতির সিলেক্টরের সঙ্গে মিলতে হবে, তাই যে মেশিনটি ব্যর্থ হচ্ছে সেখান থেকেই সেটি নিন।

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

স্ট্যাটাস আউটপুট ক্লায়েন্টের নিজের ঠিকানা এবং সে যে পিয়ারগুলো দেখতে পায় তা চিহ্নিত করে, আর নীতির উৎস-সিলেক্টরকে এগুলোর সঙ্গেই মিলতে হয়। tailscale ping নিজেই সাবনেট রাউটার পর্যন্ত tailnet পথ প্রমাণ করে; এটি পিয়ার নাম ও tailnet ঠিকানা সমাধান করে, ঘোষিত সাবনেটের ভেতরের হোস্ট নয়। তৃতীয় কমান্ডটি সাবনেট রুট দিয়ে একটি সাধারণ ICMP ইকো পাঠায়, তাই এর ফলাফল রাউটার নয়, গন্তব্যকে বর্ণনা করে। tailnet-স্তরের অস্বীকৃতি সাধারণত প্রত্যাখ্যান হিসেবে ফিরে আসে, আর যে প্যাকেট বেরিয়ে কখনও ফেরে না সেটি সময়সীমা ছাড়িয়ে যায়।

ব্যর্থ নাম ব্যর্থ ঠিকানা থেকে আলাদা প্রশ্ন; রুটকে দোষ দেওয়ার আগে হোস্টটি সরাসরি সমাধান করুন। পুরো সাবনেটের বদলে প্রকৃত রিসোর্স প্রয়োজন অনুসারে অনুমতিটি লিখুন। একটি অ্যাপ্লিকেশন কাজ করার জন্য গোটা /24 খুলে দেওয়া এভাবেই সংকীর্ণ অনুরোধ পরিণত হয় এমন বিস্তৃত অনুমতিতে যা পরে কেউ সরাতে সাহস করে না।

যদি লক্ষ্য ব্যক্তিগত সাবনেট নয়, ইন্টারনেট ইগ্রেস হয়ে থাকে, তবে সঠিক উপাদানটি একটি এক্সিট নোড, সাবনেট রাউটার নয়, আর নীতি ও রাউটিং সেই অনুসারে আলাদা। অনুমতি প্রশস্ত করার আগে সেই সিদ্ধান্তটি যাচাই করুন। একটি এক্সিট নোড ডিফল্ট রুট বদলায়; একটি সাবনেট রাউটার শুধু একটি প্রিফিক্স ঘোষণা করে।