NAT-এর পিছনে FortiGate: local-gw, localid এবং পাবলিক IP

NAT-এর পিছনে থাকা একটি FortiGate তার WAN ইন্টারফেসে 10.0.0.2 ঠিকানার মালিক হতে পারে, অথচ ইন্টারনেট তাকে দেখায় 198.51.100.40 হিসেবে, এবং দুটি সংখ্যাই বাস্তব। ডিভাইসটি যে ঠিকানায় বাইন্ড করে এবং IKE প্রমাণীকরণের সময় যে পরিচয় পাঠায়, সেগুলো আলাদা সিদ্ধান্ত, আলাদা ফিল্ডে, আলাদা শ্রোতার জন্য। NAT যাওয়ার পথে বাইরের অ্যাড্রেসিং পুনর্লিখন করে; কিন্তু প্রমাণিত পরিচয়কে দূরের পিয়ারের প্রত্যাশা অনুযায়ী পুনর্লিখন করে না। এই ধরনের বেশিরভাগ ফেজ 1 ব্যর্থতা আসে সঠিক মান ভুল ফিল্ডে বসানো থেকে।

তিনটি মান, তিনটি মালিক

তিনটি মান এবং প্রতিটির মালিক কে তা নাম দিয়ে শুরু করুন। local-gw হলো সেই ঠিকানা যা FortiGate তার বাহ্যিক ইন্টারফেসে IKE-এর উৎস হিসেবে ব্যবহার করে, এবং এটি এমন ঠিকানা হতে হবে যা ডিভাইসটি সত্যিই ধারণ করে। পাবলিক এন্ডপয়েন্ট হলো NAT ডিভাইসের ঠিকানা, যার মালিক অনুবাদটি যে করে। IKE পরিচয় হলো একটি স্ট্রিং যা পিয়ার তার নিজের কনফিগারেশনের সাথে মেলায়, এবং এটি IP ঠিকানা হওয়ার কোনো বাধ্যবাধকতা নেই।

ফিল্ডের নামগুলো এতটাই কাছাকাছি যে প্রতিস্থাপনের প্রলোভন দেয়, আর এটাই ফাঁদ। localid এবং localid-type পরিচয় বর্ণনা করে; local-gw লোকাল বাইন্ডিং বর্ণনা করে।

একটি উদাহরণ পার্থক্যটি স্পষ্ট করে। FortiGate-এ config vpn ipsec phase1-interface খুলুন, তারপর set interface "wan1" এবং set local-gw 10.0.0.2 — এমন ঠিকানা যা বক্সটি ধারণ করে, এবং এটাই IKE সকেট সফলভাবে বাইন্ড হতে দেয়। local-gw কে 0.0.0.0 -এ রেখে দিলে ইন্টারফেসের ঠিকানা ব্যবহৃত হয়, যা সাধারণত একই জিনিস কিন্তু কম স্পষ্ট। local-gw কে 198.51.100.40 -এ সেট করবেন না, কারণ ডিভাইসটি ওই ঠিকানার মালিক নয় এবং সকেট সেখানে বাইন্ড হবে না। দুটি মান কাগজে সমান দেখানো কোনো কনফিগারেশন নয়।

ধাপ 1: পিয়ার যে পরিচয় গ্রহণ করবে তা বেছে নিন

এখন পরিচয়, যা ভিন্ন সিদ্ধান্ত। set localid সেই মান নেয় যা পিয়ার তুলনা করবে, আর set localid-type FortiGate-কে বলে এটি কীভাবে ব্যাখ্যা করতে হবে: একটি ঠিকানা, একটি FQDN, একটি ব্যবহারকারী FQDN বা একটি কী ID। auto দিয়ে ডিভাইসটি এটি উৎপন্ন করে, সাধারণত বহির্গামী ইন্টারফেসের ঠিকানা থেকে, যা ঠিক সেই মান যা একটি NAT ডিভাইস পরিবর্তন করতে যাচ্ছে।

এই উৎপাদনই ব্যাখ্যা করে কেন এই টপোলজিতে স্পষ্ট পরিচয় গুরুত্বপূর্ণ। পিয়ার যদি ঠিকানা-পরিচয় প্রত্যাশা করে, তাহলে localid-type address এবং localid কে সেই পাবলিক ঠিকানায় সেট করুন যা পিয়ার দেখবে, তারপর নিশ্চিত করুন যে পিয়ার সেই মানকে রাউটিং লক্ষ্য নয়, পরিচয় হিসেবে গ্রহণ করে। পিয়ার যদি FQDN প্রত্যাশা করে, তাহলে localid-type fqdn এবং যে নাম দিয়ে এটি কনফিগার হয়েছিল তা ব্যবহার করুন। প্রকৃতপক্ষে কী পাঠানো হয়েছে তা diagnose vpn ike gateway list দিয়ে যাচাই করুন, যা গেটওয়ে অবস্থা ও ব্যবহৃত আইডেন্টিফায়ার দেখায়, আপনি কী টাইপ করতে চেয়েছিলেন তা নয়। ধরে নেবেন না যে পরিচয়-ধরনের অপশন কোনো ইচ্ছামতো নন-লোকাল ঠিকানা গ্রহণ করে; আগে রিলিজের নথিভুক্ত অর্থ দেখুন।

ধাপ 2: UDP 500 এবং 4500 ডিভাইসে ফরোয়ার্ড করুন

তৃতীয় মানটি NAT ডিভাইসের, এবং এটাই মানুষ যাচাই করতে ভুলে যায়। পাবলিক এন্ডপয়েন্টকে UDP 500 এবং UDP 4500 FortiGate-এ ফরোয়ার্ড করতে হবে, কারণ NAT-T শনাক্তকরণ এবং তার পরের এনক্যাপসুলেটেড ESP দুটোই এই পোর্টগুলো আসার উপর নির্ভর করে। এই নকশা যা ধরে নেয় তা হলো এক-থেকে-এক ম্যাপিং; একটি পাবলিক ঠিকানা একাধিক পিয়ারের মধ্যে পোর্টভিত্তিক ভাগ করা ভিন্ন সীমাবদ্ধতার ভিন্ন টপোলজি।

ফরোয়ার্ডিং নিশ্চিত করুন ক্যাপচার দিয়ে, আশা দিয়ে নয়: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 দেখায় প্যাকেট আসছে কি না এবং উত্তর বের হচ্ছে কি না।

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

ধাপ 3: ফেজ 1 কী সমাধান করে না তা দেখুন

NAT ট্রাভার্সাল টানেল তুলে, পরিচয়ের সম্মতি ঠিক করে পিয়ার তা গ্রহণ করবে কি না, আর ভেতরের প্রিফিক্স রাউটিং ঠিক করে আসলে কী পার হবে। সঠিক লোকাল ID অনুপস্থিত স্ট্যাটিক রুট বা অনুপস্থিত ট্রাফিক সিলেক্টর জোগাতে পারে না।

তাই স্তরে স্তরে যাচাই করুন। get vpn ipsec tunnel details দেখায় টানেল উঠেছে কি না এবং কোন সিলেক্টরগুলো নিয়ে দরকষাকষি হয়েছে, আর কনফিগার করা দূরের সাবনেট ও দরকষাকষি করা সিলেক্টরের মধ্যে অমিল হলো ফেজ 2-এর পোশাকে রাউটিং সমস্যা। execute vpn ike gateway clear পুনরায় দরকষাকষি করতে বাধ্য করে, তাই আপনি বর্তমান কনফিগারেশনই পরীক্ষা করছেন, আপনার শেষ পরিবর্তনের আগে প্রতিষ্ঠিত সেশন নয়। তারপর দূরের প্রিফিক্সের একটি হোস্টে ট্রাফিক পাঠান এবং কাউন্টার নড়ছে কি না নিশ্চিত করুন, কারণ উঠে থাকা কিন্তু কিছু না পাঠানো টানেল দেখতে কাজ করা টানেলের মতোই, যতক্ষণ না আপনি যাচাই করেন।

তিনটি মান নোটে এক জায়গায় রাখুন: ডিভাইসের নিজের লোকাল ঠিকানা, NAT ডিভাইসের উপস্থাপিত পাবলিক এন্ডপয়েন্ট, এবং পিয়ারের প্রত্যাশিত পরিচয় স্ট্রিং। এগুলো ভিন্ন কারণে ও ভিন্ন সময়ে বদলায়।

NAT ডিভাইস রিনাম্বার করা FortiGate-এর local-gw স্পর্শ করার কারণ নয়, আর পরিচয় বদলানো কিছু রিনাম্বার করার কারণ নয়। দুটো মেশানোই হলো অসম্পর্কিত মেইনটেন্যান্স উইন্ডোতে কাজ করা টানেল পুনর্নির্মাণের উপায়। Cloud VPN NAT নির্দেশিকা ওই দিকের সমর্থিত টপোলজির রেফারেন্স।

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