GCP HA VPN FortiGate কে প্রত্যাখ্যান করে: লোকাল ID টাইপের অমিল
Google শুধু প্রি-শেয়ার্ড কী নয়, FortiGate যে পরিচয় দাবি করে সেটিও মিলিয়ে দেখে। FQDN লোকাল ID সেই যাচাইয়ে ব্যর্থ হয়, অথচ লগ তখনও প্রমাণীকরণ বলে।
Google Cloud HA VPN থেকে আসা AUTHENTICATION_FAILED সাধারণত মানুষকে প্রি-শেয়ার্ড কী-র দিকে ফিরিয়ে পাঠায়, আর কী সাধারণত ঠিকই থাকে। টানেল 1 নম্বর ধাপে আটকে যায়, কারণ Google আরও একটি জিনিস মিলিয়ে দেখে: IKE বিনিময়ের সময় সঙ্গী যে পরিচয় দাবি করে। FortiGate-এ কেউ ঠিকানা সম্পাদনা না করেই সেই পরিচয়ের ধরন বদলে যেতে পারে। কী দুবার আবার লিখে দেওয়ার পর লগটিকে পরিচয়ের অমিল হিসেবে পড়ুন।
এক ব্যর্থতা, দুই যাচাই
IKE সঙ্গীকে দুটি আলাদা ধাপে যাচাই করে। প্রি-শেয়ার্ড কী প্রমাণ করে দুই প্রান্তের কাছে একই গোপন তথ্য আছে, আর দাবি করা পরিচয় উত্তরদাতাকে জানায় সঙ্গী নিজেকে কে বলে দাবি করছে। Google সেই পরিচয়টি যে সঙ্গীর সঙ্গে এটি কনফিগার করা হয়েছিল তার সঙ্গে মেলায়। নিজের মতো ছেড়ে দিলে FortiGate তার আউটগোয়িং ইন্টারফেস থেকে উদ্ভূত ঠিকানাভিত্তিক পরিচয় পাঠায়, আর তুলনাটি কেউ না জেনেই পাস হয়ে যায়।
দুই ধাপই লগে একই ঝুড়িতে পড়ে, যেটি ব্যাখ্যা করে পরিচিত চক্রটি: পরিচয়ের পেলোড কেউ পড়ার আগে কী চারবার আবার টাইপ করা।
FortiGate পরিচয়ের পেলোডে কী রাখে
ঝামেলা শুরু হয় যখন কেউ লোকাল ID সেট করে দুই দিককে মিলিয়ে দিতে চায়। সাম্প্রতিক FortiOS বিল্ডগুলি সেই পরিচয়কে পূর্ণ-যোগ্য ডোমেইন নাম হিসেবে চিহ্নিত করে, যদিও লেখা মানটি একটি বিন্দুযুক্ত ঠিকানা। তাই Google ঠিকানা প্রত্যাশা করার সময় FQDN পরিচয় পায় এবং সেশনটি প্রত্যাখ্যান করে। বার্তায় বলা নেই কোন অর্ধেকটি ব্যর্থ হয়েছে, তাই রিপোর্টটি প্রমাণীকরণ ব্যর্থতা হিসেবে পড়া হয়।
IKE ডিবাগিং চালু করে এটি একবার পুনরুৎপাদন করুন এবং ফায়ারওয়াল আসলে যে পরিচয়ের পেলোড পাঠায় তা পড়ুন।
একই ধাপে তিনটি সস্তা তথ্য নিশ্চিত করুন: দুই প্রান্ত যে IKE সংস্করণ ব্যবহার করে, অদৃশ্য শেষ অক্ষরসহ সঠিক কী, এবং Google যে সঙ্গী-ঠিকানা প্রত্যাশা করে। এগুলি আলাদা প্রশ্নের উত্তর দেয়, আর মিলে যাওয়া কী পরিচয় সম্পর্কে কিছুই বলে না।
বিকল্পগুলি, এবং প্রতিটির দাম
প্রতিটি পথ আলাদা স্তর ঠিক করে, এবং একটিও সব ডিপ্লয়মেন্টের জন্য উপলভ্য নয়।
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
ফায়ারওয়ালে পরিচয় সংশোধন করাই সবচেয়ে পরিষ্কার উত্তর, যেখানে ফার্মওয়্যার আপনাকে ধরন বাছতে ও মান ধরে রাখতে দেয়। ক্ষেত্রটি কিছু বিল্ডে আছে এবং অন্যগুলিতে ধরনটি ভুলভাবে ভরে, তাই রিলিজ নোটে ভরসা না করে আপনার সংস্করণ পরীক্ষা করুন।
নেগোশিয়েটিং ইন্টারফেসে রাউটেবল পাবলিক ঠিকানা হলো নথিভুক্ত সমাধানপথ, কারণ তখন ডিফল্ট পরিচয় Google-এর প্রত্যাশার সঙ্গে মেলে এবং কোনো ওভাররাইড লাগে না। ফায়ারওয়াল এমন ঠিকানা রাখতে পারলে বেশিরভাগ ডিপ্লয়মেন্ট এখানেই থামে।
আপনি যা তৈরি করেন তা যাচাই করে এমন সঙ্গীতে টার্মিনেট করা একটি টোপোলজি পরিবর্তন। এটিকে সহজতর বর্ণনার সমাধানপথ নয়, নকশার সিদ্ধান্ত হিসেবে ধরুন।
NAT যখন একটি বিকল্প সরিয়ে দেয়
NAT-এর পিছনে পাবলিক-ঠিকানার পথটি হারিয়ে যায়, আর যা থাকে তা আপনার নিয়ন্ত্রণের বাইরের ফার্মওয়্যার আচরণের উপর নির্ভর করে। এটিই সেই বিন্দু যেখানে আপগ্রেড, সঙ্গী সরানো বা ভিন্ন ক্লাউড এন্ডপয়েন্ট মেনে নেওয়ার মধ্যে সচেতনভাবে বাছতে হয়। এগুলি তিনটি আলাদা বাজেট, আর দুর্ঘটনাক্রমে একটি বেছে নেওয়াই অস্থায়ী সমাধানপথকে আর্কিটেকচারে পরিণত করে। পছন্দটি ও তার কারণ টানেলের পাশে লিখে রাখুন।
এর কিছু ব্যাখ্যা করার আগে Google-এর দিকে টানেলের অবস্থা নিশ্চিত করুন এবং IKE পথে শুধু ফেলে দেওয়া হচ্ছে না তাও। ফেলে দেওয়া প্যাকেট সময় শেষে থেমে যায়; এটি প্রত্যাখ্যান তৈরি করে না।
যতক্ষণ এটি কাজ করে কী লিখে রাখবেন
টানেল শেষবার উঠেছিল যখন যে পরিচয়ের ধরন, তার মান, ফার্মওয়্যার সংস্করণ ও সঙ্গী-ঠিকানা কার্যকর ছিল তা টুকে রাখুন। ফার্মওয়্যার হালনাগাদ ডিফল্টটি আবার বদলাতে পারে, আর পরের ব্যর্থতাটি হুবহু কী-র অমিলের মতো দেখাবে। পরিচয়টি কী ও সঙ্গী-ঠিকানার পাশে সংরক্ষিত থাকলে পরের ব্যক্তি সস্তা যাচাইগুলি থেকেই শুরু করেন।
এই রেকর্ডটিই পরের আপগ্রেডের পরে সমাধানপথটি এখনও দরকার কি না জানার একমাত্র উপায়।