একটি ASA সাইট-টু-সাইট VPN-এর মাধ্যমে অভ্যন্তরীণ সেবা প্রকাশ

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

যাচাই 1: টানেল উৎসের ঠিকানা সুরক্ষিত করে

এমন একটি টানেল দিয়ে শুরু করুন যা ইতিমধ্যে ট্রাফিক পার করে, তারপর নিশ্চিত করুন যে আপনি যে ঠিকানাটি প্রকাশ করার পরিকল্পনা করছেন তা সুরক্ষিত পরিসরের ভিতরে রয়েছে। ASA-তে সেই পরিসর আসে ক্রিপ্টো ACL থেকে বা VTI-এর রুট থেকে, এবং এটি উৎসের আসল ঠিকানা ঢাকতে হবে, শাখাটি ব্যবস্থাপনার জন্য যে সাবনেট ব্যবহার করে তা নয়। যে সিলেক্টর উৎসটি মিস করে, তা আপনাকে একটি ওঠা টানেল আর এমন প্রবাহ দেয় যা কখনো সেখানে ঢোকে না।

অনুবাদে হাত দেওয়ার আগে টানেল কাউন্টার ও রুট টেবিল দিয়ে নিশ্চিত করুন। যদি হাব থেকে টানেল পেরিয়ে উৎসে পৌঁছানো না যায়, তবে এই তালিকার পরের কিছুই তা সারাতে পারবে না।

সুরক্ষিত পরিসর ও উৎসের ঠিকানা যদি মিলে না যায়, তবে এখানেই থামুন।

যাচাই 2: শাখাটি কোন সোর্স দেখবে তা ঠিক করুন

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

অনুবাদ আরও বদলে দেয় উৎস কী লগ করতে পারে এবং সোর্সভিত্তিক নিয়ম কীসের সাথে মিলতে পারে। যদি অ্যাপ্লিকেশনকে কোনো অনুরোধের পেছনের মানুষটি জানতে হয়, তার জায়গা প্রমাণিত রিভার্স প্রক্সি, NAT-এর সিদ্ধান্তে নয়।

যাচাই 3: প্রকৃত ইন্টারফেসের বিপরীতে অনুবাদটি লিখুন

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

আপনি যে পথটি বানাচ্ছেন তার চারটি অংশ আছে, এবং চারটিকেই মিলতে হবে:

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

যাচাই 4: অ্যাক্সেস নিয়মটি প্রকাশিত পোর্টে সীমাবদ্ধ করুন

পোর্ট প্রকাশ করুন, হোস্ট নয়। যে নিয়ম উৎসকে প্রতিটি সেবায় অনুমতি দেয়, তা একটি প্রকাশিত অ্যাপ্লিকেশনকে উৎস যা চালায় তার সবকিছুর পথ বানিয়ে দেয়, যার মধ্যে সেই ব্যবস্থাপনা ইন্টারফেসও আছে যা আপনি ইচ্ছাকৃতভাবে ইন্টারনেটের বাইরে রেখেছেন। অনূদিত সোর্স থেকে উৎসে প্রকাশিত পোর্টটির অনুমতি দিন, আর প্রশাসনিক সেবাগুলোকে তাদের শুধু-VPN পথে রেখে দিন।

একই সময়ে নিয়মের ক্রম যাচাই করুন। আপনার নির্দিষ্ট নিয়মের উপরে বসে থাকা প্রশস্ত অনুমতি নির্দিষ্ট নিয়মটিকে অদৃশ্য করে দেয়।

যাচাই 5: একটি অনুরোধ ও তার উত্তর অনুসরণ করুন

ব্রাউজার দিয়ে শুরু করবেন না, কারণ ব্রাউজার লুকিয়ে রাখে কোন অংশটি ব্যর্থ হয়েছে। হাবে প্রবাহটি অনুসরণ করুন এবং কিছু বদলানোর আগে ফলাফল পড়ুন।

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

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