Cloud VPN-এর যে সীমাগুলো আপনি টিউন করতে পারবেন না: IKE লাইফটাইম ও পিয়ার NAT

রিমোট ডিভাইসে 24 ঘণ্টার ফেজ 1 লাইফটাইম দিন আর Cloud VPN টানেল ডাউনই থাকবে, যদিও Google-এর দিকে সবকিছু ঠিকঠাক কনফিগার করা আছে। পিয়ার এমন একটি মান প্রস্তাব করছে যা রেসপন্ডার গ্রহণ করবে না, তাই নেগোশিয়েশন হয় সম্পূর্ণ ব্যর্থ হয়, নয়তো অনির্দিষ্টকাল ধরে আবার শুরু হয়। Cloud VPN ফেজ 1-কে 36,000 সেকেন্ডে সীমাবদ্ধ করে, অর্থাৎ দশ ঘণ্টা, এবং এই সীমা আপনি বাড়াতে পারবেন না। পরিবর্তনটি রিমোট ডিভাইসেই করতে হবে।

পিয়ার জিজ্ঞেস করে, রেসপন্ডার সিদ্ধান্ত নেয়

IKE হলো দুটি প্রস্তাব-সমষ্টির মধ্যে মিলিয়ে নেওয়ার ব্যাপার। টানেল কেবল তখনই তৈরি হয় যখন সমষ্টিগুলো রেসপন্ডারের গ্রহণযোগ্য সীমার ভেতরে ওভারল্যাপ করে, তাই সীমার বাইরের লাইফটাইম কোনো আংশিক টানেলই তৈরি করে না। পিয়ারের কনফিগারেশনকে প্রস্তাব না ভেবে ইচ্ছেতালিকা ভাবাই স্বাভাবিক ভুল। খালি ছেদ টানেলকে ডাউন রেখে দেয়, রাউটিং ও সিলেক্টর যতই সঠিক হোক।

কেস খোলার আগে টানেলের নিজের অবস্থা পড়ুন, কারণ বিস্তারিত স্ট্যাটাস সাধারণত কোন ধাপে ব্যর্থ হয়েছে তা বলে দেয়:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

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

36,000 সেকেন্ডই সর্বোচ্চ সীমা

ফেজ 1 36,000 সেকেন্ডে থেমে যায়। 86,400-এ সেট করা ডিভাইস এমন কিছু চাইছে যা রেসপন্ডার কখনোই মানবে না, আর আবার চেষ্টা করলে তার মন বদলায় না। রিমোট প্রস্তাবটি সীমার ভেতরে নামিয়ে আনুন, একই কনফিগারেশন দাঁড়িয়ে যাবে; এই অসমতাই পুরো শিক্ষা, কারণ আপনি নিজের মান কমাতে পারেন, Google-এর মান বাড়াতে পারেন না।

নির্বাচিত মানটি ডিজাইন নোটে লিখে রাখুন। নাহলে পরের ইঞ্জিনিয়ার আবার 24 ঘণ্টার পরীক্ষা চালিয়ে একই দেয়ালে পৌঁছাবে।

সমর্থিত সেটটি গেটওয়ে টাইপ ও IKE সংস্করণ অনুযায়ী প্রকাশিত হয় Cloud VPN সংক্ষিপ্তসারএতে, তাই সাধারণ IKE নির্দেশিকার বদলে আপনার টপোলজির অংশটি পড়ুন।

নির্দিষ্ট সময়ে ডাউন হওয়া টানেল

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

কিছু সম্পাদনার আগে সেই ডাউনের টাইমস্ট্যাম্পগুলো পিয়ারের নিজের লগের সঙ্গে মিলিয়ে নিন, কারণ সিলেক্টর বা রুট পরিবর্তন একই ছন্দ নকল করতে পারে। যদি তালটি ফেজ 2 টাইমারের সঙ্গে মেলে, তবে কোনো প্রস্তাবে হাত না দিয়েই কারণ পাওয়া গেল।

স্যুট আসে গেটওয়ে টাইপ থেকে

সাইফার ও ইন্টিগ্রিটি স্যুট আলাদা টানেল-প্রোফাইল নয় যা strongSwan-এর মতো সম্পাদনা করবেন। আপনি গেটওয়ে টাইপ ও IKE সংস্করণ দিয়ে সেগুলো বেছে নেন, আর না-থাকা প্রোফাইল খুঁজতে গিয়ে একটা দুপুর নষ্ট হয়।

যে পুরোনো ডিভাইস সমর্থিত সেটের ভেতরে কিছুই দিতে পারে না, তার সামনে দুটি সৎ পথ থাকে: ডিভাইসটি বদলান, নয়তো আপনার নিয়ন্ত্রণে থাকা সফটওয়্যার গেটওয়েতে টার্মিনেট করে সেখান থেকে VPC-তে রুট করুন। বাকি সব কাজই ঘুরপথ, যা পরের রিভিউতে ব্যর্থ হবে।

প্রতি ডিভাইসে একটি করে এক্সটার্নাল ঠিকানা

পিয়ারের এক্সটার্নাল ঠিকানা তার ইন্টার্নাল ঠিকানার সঙ্গে এক-এক মেলাতে হবে। ওভারলোডেড PAT পুল কাজ করতে পারে না, কারণ একটি পাবলিক ঠিকানার পিছনে কয়েকটি হোস্ট থাকলে রেসপন্ডারের কাছে সেগুলো আলাদা করার কোনো উপায় থাকে না। যেখানে কয়েকটি হোস্টকে একটি ঠিকানা ভাগ করতে হয়, সেখানে টানেলকে এমন জায়গায় শেষ করতে হবে যা তাদের আলাদা করতে পারে।

ওই এক্সটার্নাল ঠিকানাটি স্থিরও রাখুন। ডিভাইসটিকে অন্য NAT-এর পিছনে সরালে সম্পর্কটি ভেঙে যায়, যদিও প্রতিটি প্রস্তাব তখনো মেলে। কোন মানগুলো Google-এর আর কোনগুলো আপনার, তা লিখে রাখা মূল্যবান: লাইফটাইম, স্যুট ও এক-এক NAT তাদের দিকে স্থির, আর প্রস্তাব, সিলেক্টর, রাউটিং ও BGP অগ্রাধিকার আপনার।