VPN দিয়ে 169.254: ঠিকানাটি কখনোই রাউটেবল ছিল না
লিংক-লোকাল গন্তব্য টানেলে পৌঁছানোর আগেই বাদ পড়ে, তাই রুট যোগ করলে কেবল ব্যর্থতা বাড়ে। সাবনেট মেরামত আর ব্রিজের মধ্যে বেছে নিন।
আপনি রুট যোগ করেন, টানেল ওঠে, তবু ওপারের ping সম্পূর্ণ লসে মরে, «network unreachable» আসে না। এই পার্থক্যটি গুরুত্বপূর্ণ, কারণ এটি রাউটিং টেবিল থেকে ঠিকানার দিকেই দেখায়। 169.254 গন্তব্য লিংক-লোকাল, আর লিংক-লোকাল পরিসর নকশা অনুযায়ী প্রথম hop-এই শেষ হয়, ভুল কনফিগারেশনে নয়।
এর পরের সিদ্ধান্তটি সংকীর্ণ এবং স্পষ্টভাবে নেওয়া উচিত: সার্ভার পাশের সাবনেট মেরামত করুন, নাকি Layer 2 সেগমেন্ট বাড়িয়ে ঠিকানাটিকে আবার স্থানীয়ভাবে অর্থবহ করুন। বাকি সব, চওড়া রুট যোগ করাও شامل, একই ব্যর্থতাকে আরও গন্তব্যে ছড়িয়ে দেওয়ার উপায় মাত্র।
ঠিকানাটি রুটহীন নয়, এটি রাউটেবল নয়
IPv4 লিংক-লোকাল ঠিকানা নিজেরাই নিজেদের দেয় যখন ভালো কিছু উত্তর দেয় না; Windows-এর স্বয়ংক্রিয় ব্যক্তিগত ঠিকানা পদ্ধতির উৎস এখানেই, অন্য সিস্টেমেও সমতুল্য বিকল্প আছে। পরিসরটি প্রতিটি লিংকে একসাথে ব্যবহৃত হয়, এবং এজন্যই এটি কাজ করে: একই সেগমেন্টের দুই হোস্ট কোনো সমন্বয় ছাড়াই কথা বলতে পারে।
এই একই ধর্মের কারণে রাউটারকে এই প্যাকেট নেটওয়ার্কের মধ্যে ফরোয়ার্ড করা চলবে না। লিংক-লোকাল গন্তব্যে পাঠানো প্যাকেট নিয়ে অন্য ইন্টারফেসে পাঠালে অস্পষ্টতা তৈরি হয়, কারণ প্রেরকের «স্থানীয়» আর গ্রাহকের «স্থানীয়» আলাদা জায়গা। প্রেরক কোনটি বুঝিয়েছে তা নির্ধারণ করার কোনো অনুসন্ধান নেই। এখানে ফরোয়ার্ডিং প্রশাসকের চালু করার নীতি-বিকল্প নয়; ঠিকানা শ্রেণি এটিকে বাদ দেয়।
তাই যে গেটওয়ে 169.254.1.10-কে টানেল দিয়ে পৌঁছানো যায় বলে বসায়, সে কার্নেলকে ঠিকানার বিন্যাসে নিষিদ্ধ একটি কাজ করতে বলে। প্যাকেটটি দূরের হোস্টে পৌঁছানোর বহু আগেই বাদ পড়ে, আর রুটের বিশেষত্ব সেই ফল বদলায় না।
টানেল কেন পরিসরের সমস্যাটি দৃশ্যমান করে
TUN ইন্টারফেস দুই প্রান্তের মধ্যে IP প্যাকেট বহন করে এবং পিছনে কোনো ভাগ করা সেগমেন্ট থাকে না। কোনো ব্রডকাস্ট নেই, ওপারের জন্য ARP নেই, আর প্রতিবেশী আবিষ্কারও নেই যা লিংক-লোকাল গন্তব্যকে লিংক-স্তরের ঠিকানায় পরিণত করতে পারে। ফরোয়ার্ডিং অনুমোদিত হলেও কোন প্রান্ত উত্তর দেবে তা জানার উপায় ক্লায়েন্টের নেই।
কী খুঁজতে হবে জানলে লক্ষণগুলো ঠিকঠাক মেলে। রুট টেবিলে আছে, ping অগম্য নেটওয়ার্কের বদলে সম্পূর্ণ লস জানায়, আর প্রতিবেশী টেবিলে গন্তব্যের জন্য অসম্পূর্ণ বা ব্যর্থ এন্ট্রি দেখা যায়। টানেলে ক্যাপচার প্যাকেট বেরিয়ে যেতে দেখায়, যা মানুষকে ঠিকানা শ্রেণির বদলে দূর প্রান্তে তাকাতে পাঠায়।
Windows-এ একই মূলে দ্বিতীয় একটি, দেখতে অসম্পর্কিত লক্ষণ আছে: কেবল লিংক-লোকাল ঠিকানা থাকা অ্যাডাপ্টারের ব্যবহারযোগ্য গেটওয়ে থাকে না, তাই নেটওয়ার্ক শনাক্তকরণ সংযোগটি শ্রেণিবদ্ধ করতে পারে না এবং ফায়ারওয়াল প্রোফাইল public-এ পড়ে। টানেল কারণ নয়; ঠিকানাই কারণ।
তিনটি প্রশ্নে সিদ্ধান্ত নিন
সাবনেট মেরামত আর লিংক ব্রিজ করার মধ্যে বাছাই তিনটি শর্তের উপর নির্ভর করে, আর এর যেকোনো একটি কনফিগারেশন ফাইল খোলার আগেই সিদ্ধান্ত দিতে পারে।
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
বেশিরভাগ ক্ষেত্র প্রথম প্রশ্নেই থেমে যায়। লিংক-লোকাল ঠিকানা দেখানো হোস্ট সাধারণত বোঝায় DHCP উত্তর দেয়নি, কেবল বা VLAN ভুল, বা কেউ হাতে ঠিকানা লিখেছে। এটি মেরামত করা যেকোনো টানেল কাজের চেয়ে সস্তা, আর সমস্যাটি এই একটি ক্লায়েন্টের নয়, ভবিষ্যতের সবার থেকে সরায়। সাইটে কাজ করা DHCP পরিসরও রেখে যায়, যা আপনি আসলে চেয়েছিলেন।
কিছু ধরে নেওয়ার আগে সার্ভার পাশ দেখুন। হোস্টে ip addr show ও ip route চালান, আর ক্লায়েন্টে arp -n বা route print -4, যাতে দেখতে পারেন prefix সত্যিই আছে নাকি কেবল পুরোনো এন্ট্রি তা দাবি করছে।
ব্রিজ যখন সঠিক উত্তর, তখন তার খরচ
একটি ভৌত অ্যাডাপ্টারকে TAP অ্যাডাপ্টারের সাথে ব্রিজ করলে দূরের ক্লায়েন্ট স্থানীয় ব্রডকাস্ট ডোমেনের অংশ হয়। তখন ব্রডকাস্ট ও প্রতিবেশী আবিষ্কার কাজ করে, আর লিংক-লোকাল ঠিকানা আবার অর্থবহ হয়, কারণ ক্লায়েন্ট সত্যিই সেই লিংকের স্থানীয়।
খরচ সত্যিই আছে এবং কেউ রাজি হওয়ার আগে বলা উচিত। ব্রডকাস্ট ট্র্যাফিক টানেল পার হয়, ক্লায়েন্ট কেবল প্রয়োজনীয় সেবার জন্য নয় বরং সব উদ্দেশ্যে স্থানীয় সেগমেন্টে উন্মুক্ত থাকে, আর সার্ভারকে এখন প্যাকেট রাউট করার বদলে ফ্রেম ফরোয়ার্ড করতে হয়। ল্যাব বেঞ্চ বা রাউটেবল কনফিগারেশন পথ নেই এমন ডিভাইসের জন্য এটি যুক্তিসঙ্গত বিনিময়, দূরবর্তী অ্যাক্সেসের জন্য খারাপ ডিফল্ট।
ব্রিজ করলে দুই অংশই দরকার: সার্ভারে ব্রিজ, আর ক্লায়েন্ট প্রোফাইলে কোন গন্তব্যগুলো ওপারে আছে তা বলা একটি রুট। কেবল ব্রিজ ক্লায়েন্টকে অনুমানে রেখে দেয়, আর কেবল রুট ঠিকানা শ্রেণি ঠিক করতে পারে না।