সাইট-টু-সাইট VPN-এ ASA DHCP রিলে: ধাপে ধাপে নির্দেশিকা

রিলেটি তিনটি ধাপে কাজ করে, এবং কেবল মাঝের ধাপটিই VPN অতিক্রম করে। একটি ক্লায়েন্ট শাখা সেগমেন্টে ব্রডকাস্ট করে, ASA সেই ব্রডকাস্টকে DHCP সার্ভারের কাছে ইউনিকাস্ট অনুরোধে পরিণত করে, এবং সার্ভার ক্লায়েন্টের বদলে রিলে ঠিকানায় উত্তর দেয়। এই ক্রমেই ধাপগুলো অনুসরণ করুন, আর «রিলে ভাঙা» ধরনের অধিকাংশ ক্ষেত্রেই অনুপস্থিত নীতি বা ভুলভাবে পড়া setroute লাইনে গিয়ে ঠেকে।

প্রথম ধাপ: ক্লায়েন্টমুখী ইন্টারফেসে রিলে সক্রিয় করুন

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

কিছু বদলানোর আগে চলমান কনফিগ যাচাই করুন: কোন ইন্টারফেসে রিলে সক্রিয়, কোন সার্ভার রূপটি উপস্থিত, এবং setroute ক্লায়েন্ট ইন্টারফেসে যুক্ত কি না। ASA যদি অন্য সেগমেন্টের জন্য DHCP সার্ভারও চালায়, তবে থামুন এবং নিষেধাজ্ঞার তালিকা পড়ুন; একই বক্সে সার্ভার ও রিলে একসঙ্গে সক্রিয় করা যায় না।

রিলে তার নিজের ক্লায়েন্টমুখী ঠিকানাটি গেটওয়ে-ঠিকানা ক্ষেত্রে বসায়। সার্ভার ওই ঠিকানাতেই উত্তর দেবে, তাই এটি কেবল স্থানীয়ভাবে নয়, টানেলের মাধ্যমে দূরের সাইট থেকেও পৌঁছনীয় হতে হবে।

দ্বিতীয় ধাপ: ASA-উৎপন্ন ট্রাফিক টানেলের মাধ্যমে বহন করুন

এই ধাপটিই মানুষ এড়িয়ে যায়। নীতিভিত্তিক সাইট-টু-সাইট VPN সাধারণত সাবনেটগুলোর মধ্যকার ট্রাফিকের জন্য তৈরি হয়, আর রিলে অনুরোধটি তৈরি করে ASA নিজেই। যদি টানেলের অ্যাক্সেস লিস্ট ও ক্রিপ্টো ম্যাপ কেবল শাখা-হোস্ট থেকে সার্ভার-সাবনেট প্রবাহের সঙ্গে মেলে, তবে রিলে প্যাকেটটি কখনোই টানেলে নাও ঢুকতে পারে। অ্যাক্সেস লিস্ট দুই দিকেই যাচাই করুন, কেবল শাখা-থেকে-সার্ভার লাইনটিতে নয়।

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

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

তৃতীয় ধাপ: উত্তর ও setroute অপশন পড়ুন

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

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

প্রস্তাবটি শুরু থেকে শেষ পর্যন্ত পড়ুন: প্রস্তাবিত ঠিকানা, মাস্ক, ডিফল্ট রাউটার, DNS এবং লিজের সময়। তারপর লিজটি নবায়ন হতে দিন। যে রিলে একবার কাজ করে নবায়নে ব্যর্থ হয়, তার সাধারণত স্কোপ, লিজ বা ফেরত-পথের সমস্যা থাকে যা প্রথম বিনিময়টি লুকিয়ে রেখেছিল।

ঠিক হয়ে গেছে বলার আগে আমি যা যাচাই করি

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

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

পরিবর্তন রেকর্ডে তিনটি ধাপ লিখুন: ক্লায়েন্টমুখী ইন্টারফেস, রিলে ট্রাফিক ঢেকে রাখা VPN নীতি, এবং সার্ভারের giaddr-এ ফেরার রুট। এই রেকর্ডই পরের শাখা নির্মাণকে ডিবাগিং সেশনের বদলে পুনরাবৃত্তিযোগ্য কাজ করে তোলে। এটি পরের প্রকৌশলীকে কোন কমান্ডের আউটপুট আগে সংগ্রহ করতে হবে তাও বলে দেয়।