Tailscale সাবনেট SNAT বন্ধ করার পর একমুখী ট্রাফিক
Tailscale সাবনেট রাউটারে SNAT বন্ধ করুন, তখন উত্তর আসা বন্ধ হয়ে যায়। প্রকৃত উৎস ঠিকানা থেকে যায়, তাই LAN-এর 100.64.0.0/10-এ ফেরার পথ প্রয়োজন।
Tailscale সাবনেট রাউটারে সোর্স NAT বন্ধ করুন, টানেল কাজ করতে থাকে কিন্তু এর মধ্য দিয়ে সংযোগগুলো থেমে যায়। অনুরোধগুলো গন্তব্যে পৌঁছায় দূরবর্তী ক্লায়েন্টের নিজের ওভারলে ঠিকানা নিয়ে, যা পরিবর্তনের উদ্দেশ্যই, এবং উত্তরগুলোর এখন এমন পথ দরকার যা LAN-কে কখনো জানতে হয়নি। সেই পথ ছাড়া প্যাকেটগুলো পৌঁছায়, উত্তরগুলো সাধারণ গেটওয়ে দিয়ে বেরিয়ে যায়, আর ব্যর্থতাটি এমন ফায়ারওয়াল সমস্যা হিসেবে দেখা যায় যা কোনো ফায়ারওয়াল নিয়ম ব্যাখ্যা করে না। টানেল সুস্থ; ফেরার অংশটি অনুপস্থিত।
SNAT কী লুকিয়ে রেখেছিল
SNAT চালু থাকলে রাউটার সাবনেটে ফরওয়ার্ড করার আগে উৎস ঠিকানাটি নিজের LAN ঠিকানায় পুনর্লিখন করে, তাই গন্তব্য এমন হোস্টে উত্তর দেয় যেখানে কীভাবে পৌঁছাতে হয় তা সে আগেই জানে এবং আর কিছু কনফিগার করতে হয় না। এটি বন্ধ করলে মূল উৎস অটুট থাকে, আর গন্তব্য নিজের তারের প্রতিবেশীর বদলে ওভারলে পরিসরের একটি ঠিকানা দেখে। সেই ঠিকানাটি বাস্তব এবং tailnet জুড়ে রুটযোগ্য, কিন্তু ডিফল্ট গেটওয়ে দিয়ে LAN থেকে তা পৌঁছানো যায় না। নথিভুক্ত সুইচটি হলো --snat-subnet-routes=false, যা Linux সাবনেট রাউটারেই প্রয়োগ করা হয়।
এটি প্রতি-প্যাকেট টগল নয়, একটি স্থায়ী সেটিং, তাই যে রাউটারটি যেসব গন্তব্য নেটওয়ার্কে সেবা দেয় তাদের প্রতিটির জন্য ফেরার পথ থাকতে হবে। এটাই পরিবর্তনটিকে চেকবক্সের বদলে একটি ডিপ্লয়মেন্ট সিদ্ধান্ত করে তোলে। সেই রাউটার যা কিছু সেবা দেয়, সবই একই মুহূর্তে এই প্রয়োজনটি উত্তরাধিকারসূত্রে পায়।
ফেরার পথ কোথায় থাকতে পারে
তিনটি স্থাপন প্রচলিত, এবং তারা সঠিকতায় নয়, নাগালে ভিন্ন। গন্তব্য হোস্টে স্ট্যাটিক রুট সবচেয়ে সরাসরি এবং সবচেয়ে কম স্কেলযোগ্য, কারণ প্রতিটি ডিভাইসের নিজের কপি দরকার। VPC বা সাইট রাউটারের রুট টেবিল একসাথে পুরো নেটওয়ার্ক ঢাকে, আর ক্লাসলেস স্ট্যাটিক রুট বহনকারী DHCP অপশন ক্লায়েন্টদের কাছে স্বয়ংক্রিয়ভাবে পৌঁছায় কিন্তু যেসব ডিভাইস এটি উপেক্ষা করে সেখানে নীরবে ব্যর্থ হয়।
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
যে স্থাপনই বেছে নিন, পরবর্তী হপ রাউটারের LAN ঠিকানা, কখনোই তার tailnet ঠিকানা নয়। LAN হোস্ট এই রুট না থাকলে ওভারলে-এ পৌঁছাতে পারে না, তাই ওভারলে-এর ভেতরের পরবর্তী হপ বৃত্তাকার এবং প্যাকেটকে কোথাও পাঠায় না। এই একক ভুলই সঠিক দেখতে পাওয়া অথচ ব্যর্থ হওয়া বেশিরভাগ কনফিগারেশনের কারণ, এবং এটি কেবল রাউটারের নিজের টেবিল পড়া প্রতিটি পরীক্ষা পার করে যায়। কোন স্থাপন ব্যবহার করেছেন লিখে রাখুন, নইলে পরের ব্যক্তি ভুলটিই পরীক্ষা করবে।
ব্যর্থতাকে একমুখী ট্রাফিক হিসেবে পড়া
লক্ষণ কারণের চেয়ে চেনা সহজ: সেবাটি রাউটারেই উত্তর দেয় এবং দূরবর্তী ক্লায়েন্ট থেকে নীরব থাকে। গন্তব্যে ক্যাপচার দেখায় অনুরোধ আসছে এবং উত্তর যাচ্ছে, যা সফল মনে হয় যতক্ষণ না খেয়াল করেন সেই উত্তরগুলো কোথায় যাচ্ছে। সেগুলো ডিফল্ট গেটওয়ের দিকে যাচ্ছে, অর্থাৎ আগমনের অংশ কাজ করেছে আর ফেরার অংশ করেনি।
বরং রাউটারে ক্যাপচার করুন, কারণ এটি এক বিনিময়ের দুই দিকই দেখে এবং উত্তর আদৌ এসেছে কি না দেখায়। উত্তর গন্তব্যে দেখা গেলে কিন্তু রাউটারে কখনো না দেখা গেলে, গন্তব্যের দিকে রুটটি অনুপস্থিত বা ভুল। আর তা রাউটারে দেখা গিয়ে সেখানেই থামলে সমস্যাটি আরও সামনে এবং ভিন্ন তদন্তের।
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
প্রকৃত ঠিকানা কি একটি রুটের যোগ্য
গন্তব্য নেটওয়ার্ক পুনরায় কনফিগার করা না গেলে SNAT রাখাই সরল উত্তর, আর এর খরচ হলো গন্তব্যের লগ ও নীতিতে প্রতিটি ক্লায়েন্ট রাউটারের মতো দেখায়। অ্যাপ্লিকেশনের প্রকৃত উৎস ঠিকানা দরকার হলে বা নেটওয়ার্ক নীতিকে একই রাউটার ভাগ করা ক্লায়েন্টদের আলাদা করতে হলে এটি বন্ধ করা ন্যায্য। দুটোই বৈধ কারণ এবং কোনোটিই বিনামূল্যে নয়। সুবিধাটি প্রতিটি গন্তব্য নেটওয়ার্কে রুট রক্ষণাবেক্ষণের পাশাপাশি নিচে বর্ণিত ফায়ারওয়াল পর্যালোচনার যোগ্য হতে হবে।
একটি ছোট LAN-এ এই বিনিময় সাধারণত লাভজনক, কিন্তু স্ট্যাটিক রুট নিতে না পারা বিপুল সংখ্যক যন্ত্রের ক্ষেত্রে সাধারণত নয়। সিদ্ধান্ত ও কারণ রাউটার কনফিগারেশনের পাশে লিখে রাখুন, যাতে পরের প্রশাসক জানেন কোন আচরণ ইচ্ছাকৃত। কেউ না লিখে রাখা ডিফল্ট কোনো অবহেলা থেকে আলাদা করা যায় না।
ফায়ারওয়াল, লগিং ও দ্বিগুণ ভূমিকা
রাউটারের LAN ঠিকানার সাথে মিলে যাওয়া প্রতিটি নিয়ম এখন ভিন্ন উৎসের সাথে মেলে, এবং এর মধ্যে আছে অনুমোদন নিয়ম ও যে কোনো লগ ফিল্ড যা রাউটারকে ক্লায়েন্ট হিসেবে রেকর্ড করত। প্রথম পরীক্ষার আগেই সেই নিয়মগুলো পড়ুন, প্রথম ব্যর্থতার পরে নয়, কারণ কেবল রাউটারের ঠিকানা অনুমোদনকারী নিয়ম নতুন উৎসকে সম্পূর্ণ আটকে দেয়। প্রতিস্থাপনটি প্রয়োজনীয় ক্লায়েন্ট ও পোর্টে সংকুচিত করুন, তারপর নিশ্চিত করুন এটি নীরবে পুরো tailnet গ্রহণ করছে না।
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
একটি নোড একইসাথে এক্সিট নোড ও সাবনেট রাউটার হিসেবে কাজ করা একটি নথিভুক্ত সমন্বয় যা সাবনেট SNAT বন্ধ হলে আপস্ট্রিম ট্রাফিক ফেলে দিতে পারে। সেই ভূমিকাগুলো আলাদা নোডে ভাগ করলে এই সতর্কতা দূর হয় এবং প্রতিটি রুট ও ফায়ারওয়াল নীতির একক মালিক থাকে। ভূমিকাগুলো একসাথে থাকতেই হলে এই আচরণ প্রত্যাশা করুন এবং ক্লায়েন্টকে দোষ দেওয়ার আগে পরীক্ষা করুন। রুট, সুইচ সেটিং ও ভূমিকা বণ্টন এক নোটে রাখুন, কারণ পরের সংযোগ ব্যর্থ হলে সেগুলো একসাথে পড়া হয়।