Azure সাইট-থেকে-সাইট VPN ট্রাফিকের জন্য NSG কোথায় প্রয়োগ করবেন

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

NSG কোথায় রাখবেন যেখানে Azure এটি মূল্যায়ন করে

ওয়ার্কলোড ফিল্টারিংয়ের সমর্থিত সীমা হল গন্তব্য সাবনেট বা গন্তব্য নেটওয়ার্ক ইন্টারফেস। গেটওয়ে সাবনেট হল পরিকাঠামো, এবং Azure নথিভুক্ত করে যে সেখানে NSG সমর্থিত নয় এবং তা গেটওয়ের কাজ ক্ষতিগ্রস্ত করতে পারে।

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

কিছু পরিবর্তন করার আগে বর্তমান সংযোগগুলি পরীক্ষা করুন, যাতে জানেন কী সরাচ্ছেন:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

ডিক্রিপশনের পরে সোর্স ঠিকানা খুঁজুন

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

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

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

আপনি যে পরিষেবা প্রকাশ করতে চান তার জন্য একটি করে নিয়ম ব্যবহার করুন এবং পোর্টের তালিকা সংক্ষিপ্ত রাখুন। অন-প্রিমাইজ রেঞ্জ থেকে সব পোর্ট অনুমোদন করে এমন নিয়ম NSG-কে নিছক আনুষ্ঠানিকতা করে তোলে।

ডিফল্ট VirtualNetwork পরিসীমা পরীক্ষা করুন

VirtualNetwork পরিষেবা ট্যাগ স্থানীয় ভার্চুয়াল নেটওয়ার্কের চেয়ে বিস্তৃত। এর সংজ্ঞায় সংযুক্ত অন-প্রিমাইজ ঠিকানা স্পেস, পিয়ারড নেটওয়ার্ক এবং গেটওয়ে-সংযুক্ত অন্যান্য প্রিফিক্স অন্তর্ভুক্ত। এর অর্থ হল VirtualNetwork-এ সীমাবদ্ধ ডিফল্ট অনুমোদন নিয়ম ইতিমধ্যেই এমন টানেল ট্রাফিক অনুমোদন করতে পারে যা অপারেটর বহির্ভূত মনে করেছিলেন।

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

Microsoft-এর পরিষেবা ট্যাগ ডকুমেন্টেশন তালিকা করে VirtualNetwork ট্যাগ কী অন্তর্ভুক্ত করে, এবং কেউ যখন যুক্তি দেয় যে ট্যাগটি কেবল VNet পরিসীমা বোঝায় তখন এটিই উদ্ধৃত করার তথ্যসূত্র।

উভয় সীমানায় কার্যকর নিয়ম পড়ুন

যখন সাবনেট NSG এবং NIC NSG উভয়ই প্রযোজ্য, প্রবাহকে উভয়ই সন্তুষ্ট করতে হবে। একটিতে অনুমোদন অন্যটির অস্বীকার বাতিল করে না, এবং সংযুক্ত দৃশ্যই প্যাকেট আসলে যার মুখোমুখি হয়।

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Azure Virtual Network Manager নিরাপত্তা প্রশাসক নিয়ম যদি প্রযোজ্য হয়, সেই স্তরটিও পর্যালোচনা করুন। প্রশাসক Always allow নিয়ম NSG মূল্যায়ন ছাড়াই ট্রাফিক পৌঁছে দিতে পারে, আর প্রশাসক Deny নিয়ম NSG দেখার আগেই তা থামায়। এই বিন্যাসে কেবল NSG পর্যালোচনা অসম্পূর্ণ।

মনে রাখবেন NSG স্টেটফুল। নিয়ম সম্পাদনা করলে বিদ্যমান অনুমোদিত সংযোগ অবশ্যই বন্ধ হয় না, তাই গ্রহণযোগ্যতা পরীক্ষার জন্য নতুন প্রবাহ দরকার। এই বৈশিষ্ট্য উৎপাদনে উপযোগী এবং পরিবর্তনের সময়ে বিভ্রান্তিকর।

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

অন-প্রিমাইজ ক্লায়েন্ট থেকে পরিষেবা পোর্টে নতুন সেশন খুলুন, তারপর যে হোস্ট অস্বীকৃত হওয়া উচিত সেখান থেকে পুনরাবৃত্তি করুন। VM-এর দিক থেকেও প্রবাহ পরীক্ষা চালান, যাতে জানেন ফেরার পথ অক্ষত।

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

NSG অনুমোদন একটি অ্যাক্সেস সিদ্ধান্ত, কোনো রুট নয় এবং কোনো লিসেনার নয়। নিয়ম প্রবাহ অনুমোদন করলেও সংযোগ ব্যর্থ হলে, গ্রুপ আবার সম্পাদনার আগে VPN-এ ক্লায়েন্টের রুট, Azure-এর ফেরার রুট এবং হোস্ট ফায়ারওয়াল পরীক্ষা করুন। প্রকৃত সোর্স ঠিকানা, NSG সংযোগ এবং মিলে যাওয়া নিয়ম অনুমোদিত পরিষেবার সঙ্গে নথিভুক্ত করুন, কারণ পরবর্তী পিয়ারিং বা রুট পরিবর্তন VirtualNetwork ট্যাগ কী অন্তর্ভুক্ত করে তা বদলে দিতে পারে।