GCP VM-এ Cloud VPN: NAT IP নয়, অভ্যন্তরীণ IP ব্যবহার করুন
গেটওয়ে এন্ডপয়েন্ট, VM-এর অভ্যন্তরীণ ঠিকানা এবং বাহ্যিক এক-থেকে-এক NAT ঠিকানা তিনটি ভিন্ন কাজ করে। আপনার রুট কোনটি ব্যবহার করে তা যাচাই করুন।
একটি অন-প্রিমাইজ নেটওয়ার্ক Cloud VPN-এর মাধ্যমে VPC-তে পৌঁছালে Compute Engine পরিষেবার গন্তব্য সাধারণত VM-এর অভ্যন্তরীণ ঠিকানা হয়। বাহ্যিক IPv4 ঠিকানা একই প্রাইভেট রুটে বসিয়ে দেওয়া যায় এমন দ্বিতীয় ঠিকানা নয়। এই ক্ষেত্রের বেশিরভাগ বিভ্রান্তি আসে তিনটি কাজের তিনটি ঠিকানাকে বিনিময়যোগ্য ভেবে নেওয়া থেকে, তাই শুরু করুন এটা নির্ধারণ করে যে একটি নির্দিষ্ট প্যাকেট কোনটি ব্যবহার করছে।
তিনটি ঠিকানা, তিনটি কাজ
এগুলোর যেকোনো একটি ডিবাগ করার আগে তিনটিরই নাম নির্ধারণ করুন, কারণ উত্তরটি বদলে দেয় আপনি পরে কোন বস্তুটি পরীক্ষা করবেন।
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
প্রথমটি টানেলের। দ্বিতীয়টি আপনার রুট ও ফায়ারওয়াল ডিজাইনের। তৃতীয়টি ইনবাউন্ড ইন্টারনেট অ্যাক্সেসের এবং এটি ম্যাপ করা হয়, সংযুক্ত নয়। এগুলোর একটির জন্য কাজ করা ডিজাইন অন্য দুটি সম্পর্কে কিছুই বলে না।
কেন বাহ্যিক ঠিকানা দ্বিতীয় ইন্টারফেস নয়
Compute Engine-এ অভ্যন্তরীণ ও বাহ্যিক পৌঁছানোর পার্থক্য কীভাবে হয়, তার কর্তৃত্ব হলো অ্যাড্রেসিং গাইড। Compute Engine-এর বাহ্যিক IPv4 হলো ইনস্ট্যান্সের একক অভ্যন্তরীণ NIC-এর উপর এক-থেকে-এক ম্যাপিং, তাই গেস্ট কখনো ওই NIC-এ দ্বিতীয় ইন্টারফেস বা দ্বিতীয় ঠিকানা দেখে না। VM ভেতরে যা রিপোর্ট করে তা এখনও একটি প্রাথমিক অভ্যন্তরীণ ঠিকানা।
এই কারণেই একটি প্রাইভেট ক্লায়েন্ট যখন টানেলের মাধ্যমে 10.24.1.7 ঠিকানায় রুট করে, আর একটি ক্লায়েন্ট VM-এর বাহ্যিক ঠিকানাকে লক্ষ্য করে, তারা ভিন্ন পথে থাকে। পাবলিক ঠিকানার জন্য ফায়ারওয়াল নিয়ম খুললে যে VPC রুটকে টানেল ট্রাফিক বহন করতে হয় তাতে কিছুই বদলায় না, আর গেস্ট রুট সম্পাদনা করলে প্ল্যাটফর্মের ম্যাপিং সরে না। আপনার রুট যে ঠিকানার নাম দেয় সেটি বেছে নিন, তারপর কেবল সেই বস্তুগুলো পরীক্ষা করুন যেগুলো এটি নিয়ন্ত্রণ করে। এই শৃঙ্খলা এই সমস্যা-সমাধানের পথ থেকে বেশিরভাগ অনুমান দূর করে।
gcloud দিয়ে পথটি হাঁটুন
ইনস্ট্যান্স থেকে শুরু করুন এবং একই বস্তু থেকে দুটি ঠিকানাই পড়ুন, যাতে বুঝতে পারেন আপনার ডকুমেন্টেশন কোনটির কথা বলছে:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"তারপর পথটি যেসব রাউটিং ও অনুমতির উপর সত্যিই নির্ভর করে সেগুলো নিশ্চিত করুন:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1টানেলের ঘোষিত ও শেখা রেঞ্জগুলো পড়ুন, ওয়ার্কলোড সাবনেটের জন্য VPC রুট, এবং অন-প্রিমাইজ উৎসকে অনুমোদন করা ফায়ারওয়াল নিয়ম। গেস্ট লিসেনার প্রাসঙ্গিক হওয়ার আগেই এই তিনটিকে মিলতে হবে।
তারপর গেস্ট পরীক্ষা করুন: পরিষেবাটি কি অভ্যন্তরীণ ঠিকানায় শুনছে, আর এর ফেরত পথ কি আবার VPC-র মধ্য দিয়ে যায়? কেবল একটি পাবলিক ঠিকানায় বাঁধা লিসেনার এই পরীক্ষায় ব্যর্থ হবে, যদিও ক্লাউড-সাইডের প্রতিটি বস্তু সঠিক থাকে।
পাবলিক প্রিফিক্স ভিন্ন প্রশ্ন
উপরের কিছুই বোঝায় না যে VPN-এর ভেতরে বহন করা প্রতিটি ঠিকানা RFC1918 হতে হবে। একটি রিমোট নেটওয়ার্ক বৈধভাবে পাবলিক স্পেস থেকে নম্বর দেওয়া যেতে পারে, শর্ত হলো প্ল্যাটফর্ম রাউটিং সমর্থন করে এবং অপারেটরের কাছে ঠিকানার কর্তৃত্ব থাকে। এটি একটি স্বাভাবিক ডিজাইন পছন্দ।
এটি কোনো সাধারণ বাহ্যিক NAT ঠিকানাকে অন্য একটি অভ্যন্তরীণ সাবনেট ঠিকানা হিসেবে গণ্য করার মতো নয়। একটি হলো আপনি যে প্রিফিক্স রুট করেন; অন্যটি হলো প্ল্যাটফর্ম ইনবাউন্ড অ্যাক্সেসে যে ম্যাপিং প্রয়োগ করে।
বাহ্যিক IPv6 এবং বিশেষভাবে নকশা করা ঠিকানা বিন্যাসের নিজস্ব অর্থ রয়েছে। আপনার পরিকল্পনা এগুলোর একটির উপর নির্ভর করলে IPv4 ক্ষেত্র থেকে সাধারণীকরণ না করে সেই বৈশিষ্ট্যের প্ল্যাটফর্ম ডকুমেন্টেশন পড়ুন। IPv4 ম্যাপিং সাধারণ ক্ষেত্র, একমাত্র নয়, এবং ব্যতিক্রমগুলোর প্রত্যেকের নিজস্ব নিয়ম আছে।
ওভারল্যাপিং রেঞ্জ ভিন্ন সমস্যা
ওভারল্যাপিং প্রাইভেট রেঞ্জ হলো মানুষ কেন পাবলিক ঠিকানার দিকে ঝোঁকে তার একটি বাস্তব কারণ, এবং এটি ভুল লিভার। গন্তব্যকে VM-এর NAT ঠিকানায় বদলালে ওভারল্যাপ সমাধান হয় না; এটি বদলায় প্যাকেটটি কোন ঠিকানার জন্য বলে দাবি করে, ফেরত পথ কীভাবে কাজ করে তা সংজ্ঞায়িত না করেই।
ওভারল্যাপটি সচেতনভাবে সমাধান করুন: পুনঃনম্বর করুন, সমর্থিত ট্রান্সলেশন ডিজাইন ব্যবহার করুন, অথবা এমন নেটওয়ার্ক দিয়ে রুট করুন যেখানে প্রিফিক্সগুলো সংঘর্ষ করে না। এগুলোর প্রত্যেকটি মালিকসহ একটি ডিজাইন। NAT ঠিকানা কোনো ডিজাইন নয়।
দুটি ফিল্ড আলাদাভাবে ডকুমেন্ট করুন
টানেল পিয়ার এবং ওয়ার্কলোড গন্তব্যকে দুটি আলাদা রানবুক ফিল্ড হিসেবে লিখুন, প্রত্যেকটির সঙ্গে সেই রুট ও ফায়ারওয়াল নিয়ম যা এটিকে সমর্থন করে। যে IPsec টানেল উঠে আসে তা কেবল বলে দুই পক্ষ একমত; ওয়ার্কলোড কোন ঠিকানায় পৌঁছানো যায় বা তার প্রাইভেট রুট সম্পূর্ণ কি না, সে সম্পর্কে কিছুই বলে না।
অন্যপ্রান্তে একটি বাস্তব ক্লায়েন্ট দিয়ে যাচাই করুন: নাম রিজলভ করুন, এটি অভ্যন্তরীণ ঠিকানা ফেরত দেয় কি না নিশ্চিত করুন, সংযোগ করুন এবং ফেরত ট্রাফিক পরীক্ষা করুন। Compute Engine IP ঠিকানা ডকুমেন্টেশন হলো উপরে ব্যবহৃত অভ্যন্তরীণ-বনাম-বাহ্যিক পার্থক্যের রেফারেন্স।