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

একটি পথের তিন মালিক

একটি শাখা নেটওয়ার্ক নিন 192.168.50.0/24 এবং একটি ওয়ার্কলোড সাবনেট 10.0.10.0/24, অ্যাপ্লায়েন্সটি রয়েছে 10.0.0.4 ঠিকানায়, তার নিজের সাবনেটে। একটি রিকোয়েস্ট তিনটি আলাদা কনফিগারেশন স্পর্শ করে।

DecisionConfigured inHow it fails
Where the workload subnet sends branch trafficAzure route table entryTraffic leaves the subnet and never reaches the appliance
Whether a NIC may accept traffic not addressed to itAzure NIC IP forwardingPackets arrive and disappear at the interface
Whether the guest forwards decrypted trafficGuest OS or vendor appliance policyTunnel is up, workload is unreachable
Whether the workload accepts the sourceNSG and service policyRequests delivered, replies refused

বেশিরভাগ প্রতিষ্ঠানে প্রতিটি সারির মালিক আলাদা দল, তাই এই ব্যর্থতা সাধারণত একটি টিকিটের বদলে তিনটি টিকিট হিসেবে আসে।

যে রুটটি অ্যাপ্লায়েন্সের দিকে ইঙ্গিত করে

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

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

সবাই যে NIC ফ্ল্যাগ ভুলে যায়

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

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true একটি ইন্টারফেসের জন্য এটি চালু করে। Microsoft-এর NIC ফরওয়ার্ডিং নির্দেশিকা প্রত্যেক সংযুক্ত NIC-এ সেটিংটি দাবি করে যা ট্রাফিক ফরওয়ার্ড করে, তাই একক-NIC অ্যাপ্লায়েন্সেও সেই একটি NIC-এ এটি সেট করা দরকার।

ফ্ল্যাগটি কোনো রুট নয় এবং কোনো ফায়ারওয়াল নিয়মও নয়। এটি চালু করা কেবল অনুমতি দেয়, আর কিছু নয়।

ডিক্রিপ্ট করা প্যাকেট নিয়ে গেস্ট কী করে

টানেল শেষ হলে অ্যাপ্লায়েন্সের নিজের স্ট্যাক পরের সিদ্ধান্ত নেয়। একটি Linux গেস্টে IPv4 ফরওয়ার্ডিং রানটাইম সেটিং, এবং sysctl -w net.ipv4.ip_forward=1 পরবর্তী বুট পর্যন্ত টিকে থাকে। এর বদলে এটি একটি ফাইলে স্থায়ী করুন /etc/sysctl.d/ এর অধীনে। একটি ভেন্ডর অ্যাপ্লায়েন্সের নিজস্ব সমতুল্য ব্যবস্থা থাকে, আর ভেন্ডর প্ল্যাটফর্মে পেস্ট করা Linux নির্দেশনা সাধারণত কিছুই করে না।

গেস্ট ফায়ারওয়াল পলিসি আবার আলাদা, এবং ওয়ার্কলোডের নেটওয়ার্ক সিকিউরিটি গ্রুপও আলাদা। VM-এর পাবলিক ঠিকানায় UDP 500 এবং 4500 অনুমোদন করা টানেলকে রক্ষা করে; ডিক্রিপ্ট করা শাখা রিকোয়েস্ট ওয়ার্কলোড পোর্টে পৌঁছাতে পারবে কি না, সে সম্পর্কে এটি কিছুই বলে না।

একটি রিকোয়েস্ট ও তার উত্তর অনুসরণ করুন

একটি অনুমোদিত ফ্লো বেছে নিন এবং শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন। শাখার জন্য একটি রুট দরকার 10.0.10.0/24 সাইট সংযোগের ওপর দিয়ে, অ্যাপ্লায়েন্সের দরকার ওয়ার্কলোড সাবনেটে পৌঁছানোর পথ, আর ওয়ার্কলোড সাবনেটের দরকার শাখার দিকে ফেরত যাওয়ার রুট।

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

একটি সফল হ্যান্ডশেক সেই শৃঙ্খলের একটি লিঙ্ক প্রমাণ করে। পথটি সম্পূর্ণ হয় যখন উত্তরটি একই অ্যাপ্লায়েন্সের ভেতর দিয়ে ফিরে আসে এবং ওয়ার্কলোডের নিজের পলিসি তা অনুমোদন করে।

সম্পর্কিত নিবন্ধ