VPN ক্লায়েন্ট সংযোগ করলে ওয়েব সার্ভার অদৃশ্য হয়ে যায়
অনুরোধ LAN-এ আসে আর উত্তর টানেল দিয়ে বেরিয়ে যায়। হোস্টকে যা করতে হবে তার ভিত্তিতে বাদ দেওয়া রুট, নীতি-ভিত্তিক রাউটিং বা অনুবাদ বেছে নিন।
যে সেবা VPN ক্লায়েন্ট সংযোগ করার মুহূর্তেই অদৃশ্য হয়ে যায় সেটি সাধারণত ব্লক হয় না, বরং ভুল ইন্টারফেস দিয়ে উত্তর দেয়। অনুরোধটি ভৌত নেটওয়ার্ক কার্ডে আসে, ডেমন একটি উত্তর লেখে, এবং রাউটিং টেবিল সেই উত্তরটি টানেলকে দিয়ে দেয়, কারণ টানেল ডিফল্ট রুটটি দখল করেছে। দূরবর্তী ক্লায়েন্ট তার খোলা সংযোগের কোনো উত্তর কখনো দেখে না, তাই সে অপেক্ষা করে এবং পরে সময় শেষের কথা জানায়। সেই ধারাবাহিকতার কোথাও কোনো ফায়ারওয়াল নিয়ম জড়িত নয়।
লক্ষণ: অনুরোধ ভেতরে আসে, উত্তর ভুল দরজা দিয়ে বেরোয়
সংকেত হলো এমন একটি অন্তর্গামী সংযোগ যা ব্যর্থ হয়, অথচ হোস্টের বাকি সবকিছু কাজ করে। আরেকটি ইঙ্গিত হলো এমন হোস্ট যা LAN থেকে পৌঁছানো যায় কিন্তু ইন্টারনেট থেকে নয়, বা যা টানেল পুনরায় সংযোগ না হওয়া পর্যন্ত কাজ করে তারপর থেমে যায়। প্রতিটি ক্ষেত্রেই সম্মুখ দিক ঠিক ছিল আর ফেরত দিক ছিল না, যা নীতির বদলে রাউটিং অসমতার দিকে ইশারা করে।
অনুরোধ কীভাবে আসছে তা নয়, উত্তর কোথায় যাচ্ছে তা দেখে এটি নিশ্চিত করুন।
ভৌত ইন্টারফেসে এবং টানেল ডিভাইসে একসাথে ক্যাপচার করুন। যদি অনুরোধ ভৌত ইন্টারফেসে দেখা যায় আর উত্তর টানেলে দেখা যায়, তবে রোগনির্ণয় শেষ। যে উত্তর কোথাও দেখা যায় না তার অর্থ সেবাটি সংযোগটি কখনো গ্রহণ করেনি, যা আলাদা কারণসহ আলাদা তদন্ত।
দুটি ডিফল্ট রুট ও একটি রাউটিং সিদ্ধান্ত
যে ক্লায়েন্ট ডিফল্ট রুট ইনস্টল করে সে LAN গেটওয়ের চেয়ে ভালো মেট্রিকসহ একটি দ্বিতীয় এন্ট্রি যোগ করে। কিছু ক্লায়েন্ট এর বদলে আধা-পরিসরের দুটি রুট ইনস্টল করে, যেগুলো একই স্থানকে আরও নির্দিষ্টভাবে ঢেকে একইভাবে লুকআপ জিতে নেয়। দুই পদ্ধতিই সাধারণ বহির্গামী প্যাকেটগুলোকে টানেল ইন্টারফেস বেছে নিতে দেয়।
সেই পছন্দ কেবল গন্তব্য দিয়েই হয়। কার্নেল প্যাকেট কোথা থেকে এসেছে তা জিজ্ঞেস করে না, যদি না কোনো নীতি-নিয়ম তাকে তা করতে বলে। তাই একটি সর্বজনীন ক্লায়েন্ট ঠিকানার উত্তর টানেলকে দেওয়া হয়, যার দূরবর্তী প্রান্ত এমন উৎস ঠিকানার প্যাকেট পায় যা তার নিজের নয় এবং সেটি ফেলে দেয় বা অকেজো কোথাও পাঠিয়ে দেয়। লিনাক্সে কঠোর রিভার্স-পাথ ফিল্টারিংও মূল অনুরোধটি ফেলে দিতে পারে, আপনার সেবা তা দেখার আগেই, যা বাইরে থেকে হুবহু একই দেখায়। দুই লক্ষণই একটি অন্তর্গামী প্রবাহ ও তার উত্তরের মধ্যে একই অনুপস্থিত সম্পর্ক থেকে আসে।
টানেল সারাক্ষণ সঠিকভাবে আচরণ করে। তাকে ডিফল্ট রুট বহন করতে বলা হয়েছিল এবং সে ঠিক তা-ই করে।
টানেল না ভেঙে ফেরত পথ ঠিক করুন
মেরামতের তিনটি টেকসই রূপ আছে, এবং পছন্দটি নির্ভর করে হোস্টের নিজের কতটা ট্রাফিক টানেলের ভেতরে থাকা উচিত তার উপর। সেবার গন্তব্য বা পোর্ট বাদ দেওয়া সবচেয়ে ছোট পরিবর্তন। উৎস বা চিহ্ন অনুসারে নীতি-রাউটিং সবচেয়ে নিখুঁত। উৎস অনুবাদ সবচেয়ে মোটা এবং দুই বছর পরে ব্যাখ্যা করা সবচেয়ে সহজ।
হোস্টকে যা করতে হবে তার ভিত্তিতে বেছে নিন, আপনি প্রথমে কোন স্নিপেট পেয়েছেন তার ভিত্তিতে নয়।
গন্তব্য বাদ দেওয়া স্থিতিশীল সর্বজনীন ঠিকানার সেবার জন্য উপযুক্ত, আর ডেমনকে সব ঠিকানার বদলে ভৌত ঠিকানায় বেঁধে রাখা সেই বাদ দেওয়াকে আরও নিরাপদ করে। উৎস অনুসারে টেবিল বাছাই করা নীতি-নিয়ম হোস্টের নিজের সংযোগগুলো টানেলের ভেতরে রাখে, আর সেবার উত্তরগুলো WAN গেটওয়ে দিয়ে ফেরত পাঠায়। WAN ইন্টারফেসে উত্তর মাস্কারেড করা একই পথে পৌঁছায়, তবে সেবার লগ থেকে ক্লায়েন্টের ঠিকানা লুকানোর মূল্যে। ডিফল্ট রুটের তাৎক্ষণিক পরিবর্তন একটি রোগনির্ণয়, কনফিগারেশন নয়, কারণ ক্লায়েন্ট প্রতিবার পুনঃসংযোগে রুটগুলো আবার লেখে।
ip rule show
ip route get 203.0.113.9 from 192.0.2.44যখন হোস্ট নিজের পেছনের LAN-এর জন্যও রাউট করে
এক হপ আরও দূরে গেলে একই অসমতা আরও চলমান অংশ নিয়ে ফিরে আসে। ট্রাফিক ইন্টারনেট থেকে রাউটারে পৌঁছায়, অভ্যন্তরীণ ডিভাইসে ফরোয়ার্ড হয়, আর সেই ডিভাইসের ফেরার একমাত্র পথ টানেল, তাই উত্তরটি মূল ক্লায়েন্টের কাছে পৌঁছায় প্রদানকারীর নিজের ঠিকানা থেকে। এরপর সংযোগ ট্র্যাকিং এমন একটি প্রবাহের উত্তর পায় যার শুরু সে দেখেনি, এবং তা ফেলে দেয়। এদিকে ক্লায়েন্ট কিছুই দেখে না।
দুটি পরিবর্তন এটি সারায়: গন্তব্য অনুবাদ যাতে অন্তর্গামী সংযোগ অভ্যন্তরীণ ডিভাইসে পৌঁছায়, এবং উৎস অনুবাদ যাতে সেই ডিভাইসের উত্তর রাউটারের নিজের কাছ থেকে আসা বলে মনে হয়।
রাউটার ফার্মওয়্যারে সাধারণ প্রকাশ হলো একটি নীতি-নিয়ম যা পোর্ট-ফরওয়ার্ডিংকে WAN দিকে পিন করে রাখে, আর রাউটারের নিজের ট্রাফিক টানেলে চলে। উৎস অনুবাদ ছাড়া সেই উত্তর বাহ্যিক ক্লায়েন্টের উদ্দেশ্যে ঠিকানা পায় এবং অভ্যন্তরীণ ডিভাইসের কাছে তার কোনো রুটই নেই। তিনটি জিনিস আলাদাভাবে পরীক্ষা করুন, কারণ সেগুলো ভিন্ন কারণে ব্যর্থ হয়: বাইরে থেকে আসা সংযোগ, হোস্ট নিজে যে সংযোগ শুরু করে, এবং নাম খোঁজা।