Azure VPN NAT ওভারল্যাপিং VNet ঠিকানা ঠিক করে না
একই প্রাইভেট রেঞ্জের দুইটি VNet শুধু NAT থাকার কারণে সংযুক্ত হবে না। আগে সংযোগের ধরন দেখুন, তারপর পুনঃনম্বর করুন বা অনুবাদ উপনামের মালিকানা নিন।
দুইটি VNet-ই 10.40.1.0/24 ব্যবহার করে, টানেল উঠে আসে, কিন্তু কিছুই কাজ করে না। দ্বিতীয় কোনো VPN গেটওয়ে যোগ করলে তা বদলায় না, কম রুট মেট্রিকও না, কারণ সমস্যাটি পথ নির্বাচনে নয়। একই প্রাইভেট ঠিকানায় সাড়া দেওয়া দুইটি ওয়ার্কলোড প্রতিটি প্যাকেটকে অস্পষ্ট গন্তব্য ও যাচাইযোগ্য নয় এমন ফেরত পথ দিয়ে যায়। কোনো অনুবাদ পরিকল্পনার আগে আপনি আসলে কোন ধরনের সংযোগ তৈরি করেছেন তা বের করুন, কারণ এই একটি সিদ্ধান্তই ঠিক করে Azure-এর NAT সুবিধা আদৌ পাওয়া যায় কি না।
উপসর্গটি আসলে আপনাকে কী বলছে
যখন VNet A-এর একটি হোস্ট 10.40.1.10-এ পাঠায়, রাউটিং টেবিল শুধু এটিকে কোথাও নির্দেশ করতে পারে। যদি VNet B-তে 10.40.1.10-ও থাকে, তাহলে সেই ঠিকানাটি এমন গন্তব্য নয় যা পথ আলাদা করতে পারে; এটি দুই মালিকের একটি ঠিকানা।
মানুষ সাধারণত যে দ্বিতীয় গেটওয়ে স্থাপন করে তা সাহায্য করে না। এটি আপনাকে আরেকটি টানেল দেয়, আরেকটি ঠিকানা নয়, এবং নকল রেঞ্জটি অপরিবর্তিতভাবে টানেলের ভিতরে ভ্রমণ করে। এটি যে কনফিগারেশন আপনাকে সামঞ্জস্যপূর্ণ রাখতে হয় তাও দ্বিগুণ করে। যা এটি করতে পারে না তা হলো একটি ঠিকানাকে দুইটি হোস্ট বোঝানো।
VPN পিয়ারগুলোর পাবলিক ঠিকানা বদলানোও কিছুই করে না। সেই ঠিকানাগুলো টানেলের প্রান্তবিন্দু চিহ্নিত করে, অথচ সংঘর্ষটি ভেতরে বহন করা প্রাইভেট রেঞ্জে।
সংযোগের ধরনই ঠিক করে NAT পাওয়া যাবে কি না
Azure VPN Gateway-তে সত্যিই NAT সক্ষমতা আছে, এবং নির্দিষ্ট গেটওয়ে SKU-তে রুট-ভিত্তিক IPsec ক্রস-প্রিমাইজ সংযোগের জন্য তা নথিভুক্ত। একই নথি VNet-to-VNet ও point-to-site সংযোগ বাদ দেয়, তাই এটি এমন কোনো চেকবক্স নয় যা প্রতিটি গেটওয়ে সম্পর্কে দেখা যায়।
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
নেটিভ VNet-to-VNet-এর জন্যও শুরু থেকেই VNet ও লোকাল-নেটওয়ার্ক রেঞ্জ ওভারল্যাপ না হওয়া দরকার, যা বাদ দেওয়ার সঙ্গে সামঞ্জস্যপূর্ণ। একই কারণে VNet পিয়ারিংও ওভারল্যাপের সমাধান নয়।
একটি সমর্থিত বিকল্প আছে যা মানুষ নেটিভ ধরনের সঙ্গে গুলিয়ে ফেলে: অন্য VNet-কে লোকাল নেটওয়ার্ক হিসেবে মডেল করুন এবং সাইট-টু-সাইট হিসেবে সংযুক্ত করুন। এটি ভিন্ন রিসোর্স ও ভিন্ন ডিজাইন, তাই নাম পাল্টানো সংযোগকে নাম পরিবর্তন নয়, যাচাই করার মতো পরিবর্তন হিসেবে ধরুন।
পুনঃনম্বর করুন, বা এমন কিছু দিয়ে অনুবাদ করুন যা উপনামের মালিক
দুইটি VNet-ই যদি আপনার হয়, পরিকল্পিত পুনঃনম্বরকে অনুবাদের চলমান খরচের সঙ্গে তুলনা করুন। পুনঃনম্বর অ্যাপ্লিকেশন কনফিগারেশন, DNS রেকর্ড, নিরাপত্তা নিয়ম ও প্রতিটি বিদ্যমান সংযোগ স্পর্শ করে, কিন্তু পরে স্বাভাবিকভাবে পড়া যায় এমন নেটওয়ার্ক রেখে যায়। একবারে একটি সাবনেট করুন, DNS পরিবর্তন সবার শেষে। অর্ধ-পুনঃনম্বর করা রেঞ্জ দুই বিকল্পের চেয়েও খারাপ, কারণ তখন দুই প্রিফিক্সই পরেরবার টেবিল পড়া ব্যক্তির কাছে কর্তৃত্বপূর্ণ দেখায়।
যেখানে পুনঃনম্বর বাস্তবসম্মত নয়, সেখানে উপনামের প্রকৃত মালিকসহ অনূদিত ডিজাইন ব্যবহার করুন। VNet A-এর কলাররা VNet B-এর 10.40.1.10-এ 10.140.1.10 হিসেবে পৌঁছাতে পারে, কিন্তু সেই উপনামের জন্য দরকার অনুবাদকারী ডিভাইস, তার দিকে রুট এবং উত্তরের জন্য সামঞ্জস্যপূর্ণ আচরণ। শুধু DNS-এ যোগ করা ঠিকানা অনুবাদ নয়।
দুই রেঞ্জই দুই দিকে লিপিবদ্ধ করুন: কলার কী ডায়াল করে, গন্তব্য কী উৎস হিসেবে দেখে, এবং কোন পক্ষ উদ্যোগ নিতে পারে। Azure-এর নিজস্ব NAT নিয়মে তাদের SNAT ম্যাপিংয়ের জন্য বিপরীত অনুবাদ থাকে, তাই আপনাকে হাতে মিলে যাওয়া DNAT নিয়ম লিখতে হয় না, কিন্তু সেই সুবিধা ওই সংযোগ ধরনেই শেষ যেগুলো এই সুবিধা সমর্থন করে।
যা কাজ করবে না
ব্যবহারকারী-নির্ধারিত রুট বা রুট মেট্রিক অনুপস্থিত ঠিকানা-পার্থক্য তৈরি করতে পারে না। দুটোই এমন গন্তব্যে কাজ করে যা এখনও অস্পষ্ট, এবং প্যাকেট টেবিল যেই পরবর্তী হপ পছন্দ করে সেখানেই পৌঁছায়।
নকল রেঞ্জটি আরও নির্দিষ্ট প্রিফিক্স হিসেবে রাউট টেবিলে যোগ করলে অস্পষ্টতা শুধু এক ধাপ সরে। এটি অন্য দিকটিও ভাঙার প্রবণতা রাখে, যেখানে উত্তরের এখন দুইটি বিশ্বাসযোগ্য উৎস থাকে।
দুই দিকের ট্রাফিকসহ ডিজাইন গ্রহণ করুন
টানেল স্ট্যাটাস দিয়ে নয়, প্রতিটি পক্ষ থেকে নতুন অনুমোদিত অপারেশন দিয়ে ডিজাইন প্রমাণ করুন। সংযুক্ত IPsec টানেল বলে পিয়াররা ক্রিপ্টো নিয়ে একমত; গন্তব্যগুলো আলাদা করা গেছে কি না সে সম্পর্কে এটি কিছু বলে না।
তারপর প্রত্যাখ্যাত পথগুলো চালান: এমন ঠিকানা যা অপ্রাপ্য থাকা উচিত, এবং এমন সার্ভিস যা নীতির ব্লক করা উচিত। দুটোই যদি এখনও সফল হয়, অনুবাদটি ডিজাইনের ইচ্ছার চেয়ে বিস্তৃত।
যে তথ্যগুলো পরে এই সেটআপ ব্যাখ্যা করবে তা দিয়ে শেষ করুন: মূল রেঞ্জ, উপস্থাপিত রেঞ্জ, অনুবাদকারী ডিভাইস, এবং প্রতিটি পক্ষ কোন দিকে উদ্যোগ নিতে পারে। এর কোনোটি অনুপস্থিত থাকলে পরবর্তী ইঞ্জিনিয়ার এমন নেটওয়ার্ক উত্তরাধিকারে পান যেখানে দুই হোস্ট একই নাম ভাগ করে এবং কেন একটা সাড়া দেয় তা কেউ মনে রাখে না।