সাইট থেকে সাইটে VPN শুধু এক দিকে কাজ করে: দুটি ভিন্ন ত্রুটি

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

এই পার্থক্যই ঠিক করে কোন কমান্ডগুলো চালানো মূল্যবান।

একই রকম দেখতে দুটি ত্রুটি

প্রথম ক্ষেত্রে B-র হোস্ট A-তে একটি SYN পাঠায়, কিছুই ফিরে আসে না। দ্বিতীয় ক্ষেত্রে A-র হোস্ট সফলভাবে একটি সেশন খোলে আর উত্তরটি ফেরার পথে উধাও হয়। দুই ব্যবহারকারীই বলেন সংযোগ একমুখী, আর দুজনেই হারিয়ে যাওয়া একটি প্যাকেটের বর্ণনা দেন, তাই কেবল বর্ণনা দিয়ে তাদের আলাদা করা যায় না।

জিজ্ঞেস করুন ব্যর্থ প্রচেষ্টাটি কোন দিক থেকে শুরু হয়েছিল। এই একক তথ্যই সম্ভাব্য কারণের অর্ধেক বাদ দেয়।

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

প্রথম ক্ষেত্র: ফিরতি পথ নেই

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

অনুবাদের পর গন্তব্য আসলে যে ঠিকানা দেখে সেটি যাচাই করুন, এবং মূল সাবনেটের বদলে সেই ঠিকানার ফিরতি রুট দেখুন।

দ্বিতীয় ক্ষেত্র: নীতি এটি কখনো অনুমোদন করেনি

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

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

একই হোস্টে আগে ও পরে মিলিয়ে দেখুন

একই প্রচেষ্টার দুই প্রান্ত দেখুন, দুটি আলাদা প্রচেষ্টা নয়। যে হোস্ট শুরু করছে তার গেটওয়ে এবং গন্তব্যে ক্যাপচার করুন, তারপর মিলিয়ে দেখুন কী ঢুকল, কী বেরোল এবং দূরের প্রান্ত কোন ঠিকানা দেখল।

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

গন্তব্যে ক্যাপচার যদি অনুরোধটি অপ্রত্যাশিত উৎস ঠিকানা নিয়ে দেখায়, উত্তর অনুবাদ বা রাউটিংয়ে, টানেলের নিরাপত্তা নীতিতে নয়। গন্তব্য যদি কোনো অনুরোধই না দেখায়, প্যাকেট সুরক্ষিত পথ কখনো পার হয়নি।

সংশোধনের পর একই হোস্ট থেকে একই পরীক্ষা আবার চালান এবং নিশ্চিত করুন অসম্পর্কিত প্রবেশাধিকার এখনো প্রত্যাখ্যাত। “established” টানেল স্ট্যাটাস একা দুই সিদ্ধান্তের কোনোটিই সমর্থন করে না।