Azure UDR থেকে VPN গেটওয়ে: একটি গন্তব্য, সব ইগ্রেস নয়

আপনি একটি বাহ্যিক প্রিফিক্সের জন্য একটি ব্যবহারকারী-সংজ্ঞায়িত রুট যোগ করেন, সেটিকে VPN গেটওয়েতে নির্দেশ করেন, এবং ট্রাফিক তবুও Azure-এর ইন্টারনেট পথ দিয়ে বেরিয়ে যায়। অথবা এটি সঠিকভাবে বেরোয় আর উত্তর কখনো ফেরে না। দুটি ফলই একই ভুল থেকে আসে—Azure-এর পরবর্তী হপকে পুরো ডিজাইন হিসেবে ধরে নেওয়া। রুট টেবিল শুধু ঠিক করে Azure-এর ভেতরে একটি প্যাকেট কোন প্রস্থান নেবে। টানেলের পরে তার কী হয় এবং উত্তর কীভাবে ফেরে, সেটি আপনাকে গড়ে তুলতে হবে এমন একটি দ্বিতীয় অর্ধ।

পরবর্তী হপ একটি গেটওয়ে, কোনো অ্যাপ্লায়েন্সের IP নয়

একটি UDR মিলে যাওয়া প্রিফিক্সকে একটি পরবর্তী-হপ ধরনে পাঠায়, এবং VirtualNetworkGateway একটি ধরন, কোনো ঠিকানা নয়। লোকেরা গেটওয়ের প্রাইভেট IP একটি VirtualAppliance রুটে পেস্ট করে তারপর ভাবে কেন কিছুই মেলে না, কারণ ওই ধরনটি বরং একটি NIC বা একটি অভ্যন্তরীণ লোড ব্যালান্সার প্রত্যাশা করে। Microsoft-এর রাউটিং ডকুমেন্টেশনও গেটওয়ে পরবর্তী হপকে এমন একটি ভার্চুয়াল নেটওয়ার্কে সীমাবদ্ধ করে যার গেটওয়ে একটি VPN গেটওয়ে। ExpressRoute, Route Server এবং একটি Virtual WAN হাব ওই অপশন দিয়ে ঠিকানা পায় না।

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

কিছু সম্পাদনার আগে কার্যকর রুট পড়ুন

Azure সিস্টেম রুট, BGP-শেখা প্রিফিক্স এবং UDR-গুলিকে প্রতি NIC-এর জন্য একটি কার্যকর রুট টেবিলে মিলিত করে, এবং দীর্ঘতম মিলে যাওয়া প্রিফিক্সই জেতে, তা যেখান থেকেই আসুক। একই প্রিফিক্সের জন্য একটি UDR একটি BGP রুটকে হারায়। এই ক্রমটাই কারণ আগের পরীক্ষার একটি পুরনো UDR চুপচাপ সেই প্রিফিক্সকে ছাপিয়ে যেতে পারে যা আপনি সবে টানেলের মাধ্যমে শিখেছেন।

আগে কার্যকর টেবিল দেখুন, তারপর সিদ্ধান্ত নিন আপনি একটি রুট যোগ করছেন নাকি একটি প্রতিস্থাপন করছেন:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

বাস্তব প্রিফিক্স ও সাবনেট অনুযায়ী রুট লিখুন

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

রুট তৈরি করুন, তারপর টেবিলটি যে সাবনেট ওয়ার্কলোড হোস্ট করে সেখানে বাঁধুন:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

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

অন-প্রিমিস অর্ধ শেষ করুন, নইলে প্রবাহ সেখানেই মরে

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

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

সিলেক্টর ও অনুমোদিত তালিকা এসব থেকে আলাদা। একটি Azure পরবর্তী হপ বেছে নেওয়া VPN ট্রাফিক সিলেক্টর প্রশস্ত করে না, এবং কোনো বাহ্যিক সেবার সোর্স অনুমোদিত তালিকা বদলায় না।

গন্তব্যের দেখা সোর্স দিয়ে যাচাই করুন

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

নির্বাচিত প্রিফিক্স ট্রানজিট জোরপূর্বক টানেলিংয়ের চেয়ে অনেক সংকীর্ণ পরিবর্তন। এটি সংকীর্ণ রাখুন, প্রত্যাবর্তন মানে একটি রুট মুছে ফেলা।