সাপোর্ট টিকিট প্রায়ই আসে যখন ফায়ারওয়াল পরিবর্তন আগেই অনুমোদিত আর টানেল তখনও উঠতে অস্বীকার করে। এক প্রান্তে কেবল ফিচারটি থাকলে এটাই স্বাভাবিক ফল: RFC 9329 অনুযায়ী TCP এনক্যাপসুলেশন দুই প্রান্তেই বাস্তবায়ন ও কনফিগার করতে হয়, আর কোনো সুরক্ষিত ট্রাফিক চলার আগেই সংযোগের ভেতরে সমঝোতাটি ঘটে। পোর্ট খুললে এমন এক লিসেনারের ঘোষণা দেওয়া হয় যা হয়তো নেই-ই, আর অন্য প্রান্তে মিলে যাওয়া কনফিগারেশন ছাড়া লিসেনার সংযোগ গ্রহণ করে পরে চুপ করে থাকে। নিচের ক্রমটি সস্তা যাচাইগুলোকে আগে রাখে।

বিকল্পটি আসলে কী যোগ করে তা জানুন

নেটিভ IPsec এনক্রিপ্ট করা পেলোড বহন করে IP প্রোটোকল 50 হিসেবে, অনুমতি দেওয়ার মতো কোনো পোর্ট নম্বর ছাড়াই। NAT ট্রাভার্সাল ওই প্যাকেটগুলো UDP-তে মুড়ে 4500 পোর্টে পাঠায়, তাই এত ফায়ারওয়াল নিয়ম ওই পোর্টের কথা বলে। RFC 9329 একটি স্ট্রিম উপস্থাপনা যোগ করে: IKE ও IPsec প্যাকেট দুটোই একটি TCP সংযোগের ভেতরে চলে, সাধারণত 4500 পোর্টে।

স্ট্রিমটি কোনো ওয়েব সার্ভিস নয়। 4500-এ TCP সংযোগ HTTP, TLS বা প্রক্সি-বান্ধবতা সম্পর্কে কিছুই বলে না, আর পথে থাকা HTTP প্রক্সি সাধারণত এটি বহন না করে ফ্রেমিং ভেঙে দেবে।

ফায়ারওয়ালে হাত দেওয়ার আগে প্রাক-যাচাই

স্ট্যান্ডার্ড TCP-কে UDP পথ ফেলে দেওয়া নেটওয়ার্কের জন্য ব্যাকআপ হিসেবে রাখে, তার প্রতিস্থাপন হিসেবে নয়। প্রতিটি ভেন্ডরের কাছে দুটি তথ্য নিন: ফিচারের সঠিক নাম এবং যে সংস্করণটি মালিকানা-ভিত্তিক ভ্যারিয়েন্ট নয় বরং RFC 9329 বাস্তবায়ন করে। IPsec over TCP-এর মতো লেবেল অসম্পর্কিত ডিজাইনে ব্যবহৃত হয়েছে, তাই নথির রেফারেন্স ও এটি চালু করার কনফিগারেশন কী চেয়ে নিন। দুটি উত্তরই না পেলে তার-সামঞ্জস্য নিয়ে কিছু ধরে নেবেন না।

এটি এমন ল্যাবে প্রমাণ করুন যেখানে দুই প্রান্তই আপনার। যে গেটওয়ে TCP 4500-এ সাড়া দেয় কিন্তু IKE কখনও শেষ করে না, সেটি অন্য প্রান্তে মিলে যাওয়া এনক্যাপসুলেশন ছাড়া লিসেনারের চিহ্ন, আর পরিবর্তনের উইন্ডোতে আবিষ্কার করার চেয়ে সেখানে আবিষ্কার করা অনেক সস্তা।

রেসপন্ডারে: কোনো লিসেনার আছে কি

সকেট দিয়ে শুরু করুন। ss -ltnp | grep 4500 দেখায় TCP লিসেনার আছে কি না এবং কোন প্রক্রিয়া এর মালিক। একটি লাইন না থাকলেই তদন্ত নেটওয়ার্কে নয়, গেটওয়ে কনফিগারেশনে শেষ হয়।

সকেট থাকলে ক্লায়েন্টের দিক থেকে অনুমান না করে হ্যান্ডশেক দেখুন: tcpdump -ni any 'tcp port 4500'। সম্পূর্ণ তিন-ধাপের হ্যান্ডশেকের পর নীরবতা মানে স্ট্রিম গৃহীত হয়েছে কিন্তু তার ভেতরের IKE বিনিময় ব্যর্থ, আর উত্তরহীন SYN ফিল্টারিং বা ভুল ঠিকানার দিকে ইঙ্গিত করে।

দুটোকে গুলিয়ে না ফেলতে একই ক্যাপচার উইন্ডোতে UDP পথের সঙ্গে তুলনা করুন: tcpdump -ni any 'udp port 4500 or proto 50'। TCP ব্যবহার হচ্ছে বলে আপনি ভাবছেন অথচ প্রোটোকল 50 বা UDP পোর্ট 4500-এ ট্রাফিক থাকা মানে প্রান্ত দুটি ব্যাকআপ নিয়ে কখনও সম্মত হয়নি। সম্ভব হলে গেটওয়েতেও ক্যাপচার করুন, কারণ ক্লায়েন্ট-সাইড ক্যাপচার দূর প্রান্ত কী পাঠিয়েছে তা দেখাতে পারে না।

চারটি আলাদা ধাপে গ্রহণ করুন

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

StageWhat you checkWhat it proves
1TCP connection established to 4500A listener exists and the path permits it
2IKE_SA authenticated in the gateway logBoth peers agreed on the encapsulation
3CHILD_SA installed, visible with ip xfrm stateKeys exist for the protected traffic
4A new application exchange succeedsThe data path works, not just the control path

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

রোলব্যাক, আর এটি চালু রাখার খরচ

পরিবর্তনের আগেই ফেরানোর পরিকল্পনা করুন: দুই প্রান্তে এনক্যাপসুলেশন বিকল্প বন্ধ করুন এবং টানেল UDP-তে ফিরছে কি না নিশ্চিত করুন। ব্যাকআপ আবার দরকার হতে পারে ভেবে একটি রিভিউ চক্র TCP নিয়মটি রাখুন, তারপর সরিয়ে ফেলুন। 4500-এ একটি অব্যবহৃত লিসেনার কোনো পরিচালনগত মূল্য ছাড়াই শুধু আক্রমণ-পৃষ্ঠ।

এটি সত্যিকারের কাজ বহন শুরু করলে পারফরম্যান্সের চিহ্ন দেখুন। TCP-এর ভেতরে TCP স্বীকৃতির স্তর যোগ করে যা একটিমাত্র ক্ষতিতে আটকে যায়, আর একটি সংযোগ ভাগ করা স্ট্রিমগুলো একে অন্যকে ব্লক করতে পারে, তাই ping না মেপে যে অ্যাপ্লিকেশন টানেলটি ব্যবহার করবে তাকে মাপুন।

গ্রহণযোগ্যতার তালিকা

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

কোনো ধাপ ব্যর্থ হলে কেবল সেই ধাপটিই ঠিক করুন। ট্রান্সপোর্ট সমস্যার পিছনে ছুটতে সাইফার স্যুট বা পরিচয়ের সেটিংস বদলালে সাধারণত প্রথমটির ওপর আরেকটি অসম্পর্কিত ব্যর্থতা যোগ হয়।

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