উত্তরহীন আউটবাউন্ড ESP মানে VPN মৃত নয়
ESP প্রতি অ্যাসোসিয়েশনে এক দিক রক্ষা করে এবং কিছু স্বীকার করে না। সার্ভারকে সাড়াহীন বলার আগে ভেতরের কথোপকথন ও ইনবাউন্ড SA মিলিয়ে নিন।
আপনি IPsec হোস্টে ট্রাফিক ক্যাপচার করলেন, ESP প্যাকেটগুলো বেরিয়ে যেতে দেখলেন, কিছুই ফিরে আসতে দেখলেন না, এবং সিদ্ধান্তে পৌঁছালেন যে দূরের প্রান্তটি নষ্ট। ক্যাপচারটি সেই সিদ্ধান্তকে সমর্থন করে না। ESP কথোপকথনের এক দিক রক্ষা করে এবং IP স্তরে কিছু স্বীকার করে না, তাই ফিরতি ESP না থাকার অর্থ অ্যাপ্লিকেশনের বলার কিছু না থাকাও হতে পারে, ঠিক যেমন টানেলটি মৃত হওয়াও হতে পারে। যেকোনো প্রান্তকে দোষারোপ করার আগে ভেতরের বিনিময় ও গ্রহণকারী পক্ষের অবস্থা পড়ুন।
কাহিনি: প্রতিটি সুরক্ষিত প্যাকেট একটি উত্তর পাওয়ার যোগ্য
ESP কোনো অনুরোধ-প্রতিক্রিয়া প্রোটোকল নয়। নীতি যা বেছে নেয় তা-ই এটি এনক্রিপ্ট ও প্রমাণীকরণ করে, আর প্রাপক নিজের কোনো প্যাকেট তৈরি না করেই সেই ভেতরের প্যাকেট যাচাই, ডিক্রিপ্ট ও বিতরণ করে। গন্তব্য যে UDP অনুসন্ধান উপেক্ষা করে, বা ইনবাউন্ড নীতি যে ICMP ইকো বাতিল করে, তা সঠিক ফলাফল হিসেবে উভয় দিকেই নীরবতা তৈরি করে। সেই নীরবতাকে পরিবহন ত্রুটি ভাবলে আপনি এমন নেটওয়ার্ক ত্রুটির খোঁজে যাবেন যা কখনোই ছিল না।
একমুখী ক্যাপচার আসলে যা প্রমাণ করে তা হলো প্রেরকের স্ট্যাক সেই পর্যবেক্ষণ বিন্দুতে কিছু এনক্রিপ্ট করেছে। পৌঁছানো নিয়ে কিছুই নয়, এবং উত্তর দেওয়ার ইচ্ছা নিয়েও কিছুই নয়। কাজের প্রশ্নটি "উত্তর কেন নেই" নয়, বরং "ভেতরের কথোপকথনের কী উৎপন্ন করা উচিত ছিল"।
দুটি SA, দুটি SPI, একটি কথোপকথন
IPsec নিরাপত্তা অ্যাসোসিয়েশনগুলি একমুখী, তাই স্বাভাবিক সুরক্ষিত বিনিময়ে একটি ইনবাউন্ড অ্যাসোসিয়েশন ও একটি আউটবাউন্ড অ্যাসোসিয়েশন থাকে, আলাদা শনাক্তকারী ও স্বতন্ত্র অবস্থাসহ। তাই আউটবাউন্ড প্যাকেটের SPI-এর জন্য ফিরতি ট্রাফিক খোঁজা শ্রেণিগত ভুল, কারণ যেকোনো উত্তর সহকর্মীর নিজের আউটবাউন্ড SA-এর অধীনে তার নিজের SPI নিয়ে যায়। বরং ট্রাফিক সিলেক্টর ও সহকর্মীর ঠিকানা দিয়ে জোড়টি মেলান।
কী পুনর্গঠন একবারে কয়েক সেকেন্ডের জন্য চিত্রটি জটিল করে তোলে, কারণ পুরোনো ও প্রতিস্থাপনকারী অবস্থা ওভারল্যাপ করতে পারে। উপসর্গ যদি কোনো কী পুনর্গঠনের আশপাশে শুরু হয়ে থাকে, তবে কেবল সংযোগের নাম নয়, অ্যাসোসিয়েশন শনাক্তকারী ও টাইমস্ট্যাম্প একসঙ্গে সংগ্রহ করুন।
কিছু উত্তর দেওয়ার আগে প্রাপককে যা করতে হবে
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
প্রতিটি সারি স্বাধীনভাবে ব্যর্থ হয় এবং প্রতিটি ব্যর্থতার মালিক আলাদা, তাই একটি ক্যাপচার তাদের আলাদা করতে পারে না। ইনবাউন্ড কাউন্টারই পৌঁছানোর একমাত্র সরাসরি প্রমাণ, কারণ যে প্যাকেট তার প্রমাণীকরণ বা রিপ্লে যাচাইয়ে ব্যর্থ হয় তা কোনো প্রতিক্রিয়া ছাড়াই বাতিল হয়। যার ইনবাউন্ড কাউন্টার নড়েনি, এমন সহকর্মী তাই তার নীতি সম্পর্কে আপনাকে কোনো তথ্যই দিচ্ছে না।
বিতরণ ডিক্রিপশন থেকে আলাদা ধাপ। অবস্থা বৈধ হতে পারে এবং প্যাকেট পরে ইনবাউন্ড নীতি বা ভেতরের গন্তব্য অন্তর্ভুক্ত নয় এমন রুট দ্বারা বাতিল হতে পারে, তাই পরিষ্কার কাউন্টার মানেই প্যাকেট আপনার ইচ্ছামতো গেছে—এটা ধরে নেওয়ার বদলে লক্ষ্য হোস্ট প্লেইনটেক্সট দেখেছে কি না তা যাচাই করুন।
নেটিভ ESP কোনো UDP নয়
নেটিভ ESP হলো IP প্রোটোকল 50, যা TCPও নয় UDP-ও নয় এবং এর কোনো পোর্টই নেই। তাই UDP 500-এ IKE অনুমোদনকারী ফায়ারওয়াল নিয়ম ডেটা পথ সম্পর্কে কিছুই বলে না, আর পোর্ট ঘিরে লেখা ফিল্টার টানেলকে সমঝোতা করতে দিয়ে ভেতরে বহন করা সবকিছু বাতিল করতে পারে। ডেটা পথটি আলাদাভাবে, আপনি যে মোডে সত্যিই পর্যবেক্ষণ করেছেন সেই মোডে পরীক্ষা করুন।
NAT-এর পিছনে আকার বদলায়: সুরক্ষিত পেলোড UDP-এর ভেতরে যায়, সাধারণত 4500 পোর্টে, যেমন RFC 3948 নির্ধারণ করে। যেকোনো নিয়ম লেখার আগে সক্রিয় মোড নথিভুক্ত করুন, কারণ পথের কোনো ডিভাইস নেটিভ ESP ও UDP-এনক্যাপসুলেটেড ESP-কে সম্পূর্ণ আলাদাভাবে আচরণ করতে পারে, এবং কিছু মিডলবক্স একটি অনুমোদন করে অন্যটি বাতিল করে।
এই ঘটনার নিজস্ব কাউন্টার পড়ুন
strongSwan হোস্টে swanctl --list-sas প্রতি অ্যাসোসিয়েশনের প্যাকেট ও বাইট কাউন্টার উভয় দিকে দেখায়, যা "কখনো আসেনি" ও "এসেছিল কিন্তু উত্তর দেওয়া হয়নি" আলাদা করার জন্য যথেষ্ট। Linux-এ /proc/net/xfrm_stat অনুপস্থিত অবস্থা, অনুপস্থিত নীতি ও প্রোটোকল ত্রুটির মতো সমষ্টিগত ব্যর্থতা গণনা করে। এই মোটগুলি বুট থেকেই জমতে থাকে এবং একটি নেটওয়ার্ক নেমস্পেসের অন্তর্গত, তাই বড় সংখ্যা মানেই নির্দেশ নয়।
সঠিক নেমস্পেসে ঘটনার জানালার চারপাশে দুটি পাঠ নিন এবং পার্থক্য তুলনা করুন, নাহলে গত সপ্তাহের ত্রুটি আজ বিকেলের টিকিটে চাপিয়ে দেবেন। নেমস্পেস ও উভয় টাইমস্ট্যাম্প টিকিটে লিখুন যাতে পরের পাঠক মোটের ওপর ভরসা না করে তুলনাটি পুনরুৎপাদন করতে পারেন।
সন্দেহভাজনকে নয়, ধাপটির নাম দিন
কাজের সিদ্ধান্ত বলে প্যাকেটটি কোথায় থেমেছে: কখনো পাওয়া যায়নি, পাওয়া গেছে ও বাতিল হয়েছে, বিতরণ হয়েছে কিন্তু উত্তরহীন, অথবা উত্তর দেওয়া হয়েছে ও ফেরার পথে হারিয়ে গেছে। এর প্রতিটি আলাদা মালিক ও আলাদা পরবর্তী কমান্ডের দিকে ইশারা করে। "VPN সার্ভার থেকে কোনো সাড়া নেই" চারটি পৃথক ত্রুটি এক বাক্যে চেপে দেয় যা ক্যাপচার কখনোই ন্যায্যতা দেয়নি।
ক্যাপচার সংকীর্ণ রাখুন, এবং কাঁচা কার্নেল অবস্থা টিকিটের বাইরে রাখুন, কারণ এটি এমন কী উপাদান বহন করতে পারে যা হোস্ট ছাড়ার কোনো কাজই নেই। কাউন্টারের পার্থক্য ও টাইমস্ট্যাম্পই পরের ব্যক্তির কাছে হস্তান্তর করার যোগ্য অংশ।