Terraform-এ GCP Classic VPN: টানেলটিকে রুট-ভিত্তিক করুন

প্ল্যান পরিষ্কারভাবে প্রয়োগ হয়, টানেল উঠে আসে, আর কনসোল এটিকে পলিসি-ভিত্তিক বলে। ট্র্যাফিক তখনও যায় না, আর Terraform রিসোর্সে রুট-ভিত্তিক টগল খোঁজা কোথাও পৌঁছায় না, কারণ এমন কোনো ফিল্ড নেই। Classic VPN-এ রুট-ভিত্তিক আচরণ কোনো মোড নয় যা আপনি বেছে নেন। এটি তখনই পাওয়া যায় যখন লোকাল ট্র্যাফিক সিলেক্টর 0.0.0.0/0, রিমোট সিলেক্টরগুলি সেই নেটওয়ার্কগুলি তালিকাভুক্ত করে যা আপনি সত্যিই চান, এবং একটি রুট টানেলের দিকে নির্দেশ করে। তিনটি জিনিস, আর লেবেল সেটাই অনুসরণ করে।

ভ্রান্ত ধারণা: টানেল মোড ফিল্ড

কনসোলের লেবেল প্রতিফলিত করে API সিলেক্টরগুলিতে কী দেখে। রিসোর্সে কিছুই রুট-ভিত্তিক বলে না, তাই সত্য মানে সেট করার মতো কিছু নেই।

সেই ফিল্ড খুঁজতে সমস্যার প্রথম ঘণ্টাটি চলে যায়, আর সিলেক্টরের মান পড়তে লাগে শেষ পাঁচ মিনিট।

এখানে রুট-ভিত্তিক মানে কী

Google Classic VPN-এর রুট-ভিত্তিক টানেলগুলিকে পলিসি-ভিত্তিক টানেল হিসেবে নথিভুক্ত করে যাদের লোকাল সিলেক্টর 0.0.0.0/0। শুধু রিমোট রেঞ্জগুলির নাম দেওয়া হয়, আর লোকাল দিকটিকে যেকোনো ঠিকানা হিসেবে ধরা হয়। এজন্যই আপনার কনফিগারেশনে চিহ্নটি মোড নয়, একটি মান। দুটি সিলেক্টরই স্পষ্টভাবে লিখুন এবং প্ল্যান আউটপুটে পড়ুন:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

ওই স্নিপেটের পিয়ার প্রিফিক্সটি উদাহরণমাত্র; আকৃতিটাই আসল বিষয়।

রুট একটি আলাদা অবজেক্ট

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

টানেলের সঙ্গে একই মডিউলে রুট তৈরি করুন, যাতে পর্যালোচনায় দুটি আলাদা হয়ে না যায়।

পিয়ারে সিলেক্টরগুলি প্রতিফলিত করুন

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

পরিবর্তন পর্যালোচনার সময় দুই দিকের সিলেক্টর পাশাপাশি ছাপুন।

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

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

এখন দুটি অ্যাপ্লাই প্রতি রিলিজে পিয়ার পরিবর্তনের চেয়ে সস্তা।

লেবেল নয়, নেগোশিয়েশন যাচাই করুন

প্রয়োগের পরে তিনটি আলাদা তথ্য যাচাই করুন: টানেল সংযোগ স্থাপিত বলে রিপোর্ট করে, রুটটি উদ্দিষ্ট পরের হপসহ বিদ্যমান, আর পিয়ার ফেজ 1 ও ফেজ 2 দুটোই চালু বলে রিপোর্ট করে।

টানেল চালু কিন্তু ফেজ 2 নিচে থাকার অর্থ দুই দিক সিলেক্টর নিয়ে একমত নয়:

• এক দিক এমন সাবনেট তালিকাভুক্ত করে যা অন্য দিক করে না।
• এক দিক এমন সমষ্টি ব্যবহার করে যা অন্য দিক সংকুচিত করেছে।
• রুট বিদ্যমান কিন্তু ভিন্ন একটি টানেলে নির্দেশ করে।

Classic VPN হলো HA VPN-এর চেয়ে কম SLA-যুক্ত একক টানেল, আর HA VPN দুটি ইন্টারফেস, দুটি টানেল এবং ভিন্ন রিসোর্স ধরনের BGP ব্যবহার করে। একটি ক্লাসিক উদাহরণ HA কনফিগারেশনে কপি করে সিলেক্টর ফিল্ডগুলি একইভাবে আচরণ করবে আশা করা আলাদা একটি ভুল যা এড়ানো উচিত। টানেল ফিল্ডগুলি নিজেরাই নথিভুক্ত করা হয়েছে google_compute_vpn_tunnel রেফারেন্সে।