কর্মক্ষম VPN থাকলেও উত্তরের জন্য অপেক্ষা কেন শেষ হয়ে যায়
একটি ব্যক্তিগত সার্ভারে অনুরোধ পৌঁছানো লেনদেনের মাত্র অর্ধেক। তার উত্তরকে নির্ধারিত গেটওয়ে, রুট বা অনুবাদের মধ্য দিয়ে টানেল ক্লায়েন্টের কাছে পৌঁছাতে হয়।
অনুরোধ পৌঁছায়, সার্ভার তা লগ করে, তবু ক্লায়েন্ট সময় শেষ হয়ে যাওয়ার কথা জানায়। এই সমন্বয়ের অর্থ হলো উত্তরটি ফেরার পথ খুঁজে পায়নি, আর এটি সেই অল্প কয়েকটি ত্রুটির একটি যা আপনি দুই প্রান্ত থেকেই একসাথে নিশ্চিত করতে পারেন। পরীক্ষাগুলো ক্রমানুসারে করুন এবং কোনোটি ব্যর্থ হলে থামুন।
অনুরোধ কোথায় পৌঁছেছে সেখান থেকেই শুরু করুন
অন্য কিছু যাচাই করার আগে নিশ্চিত করুন যে প্যাকেটটি সেবাটিতে পৌঁছেছে। সার্ভার-সাইড লগ এন্ট্রি, সংযোগ গণনা বা দূর প্রান্তে অনুমোদিত ক্যাপচার—সবই একই প্রশ্নের উত্তর দেয়, আর এগুলোর অনুপস্থিতি আপনাকে উত্তরের দিকে নয়, টানেলের দিকে ফিরিয়ে দেয়। এই পরীক্ষাটিই ফরওয়ার্ডিং সমস্যা ও ফেরার পথের সমস্যাকে আলাদা করে।
অনুরোধ যদি কখনোই না পৌঁছায়, এখানেই থামুন। টানেল, ব্যক্তিগত প্রিফিক্সের রাউটিং বা অ্যাক্সেস নিয়ম হলো বিষয়, আর উত্তরের পথ এখনো প্রাসঙ্গিক নয়। সার্ভার যে সোর্স ঠিকানা দেখেছে সেটিও লিখে রাখুন। এটি হয় ক্লায়েন্টকে দেওয়া পুল ঠিকানা, নয়তো অনূদিত ঠিকানা, এবং এই পার্থক্যই নির্ধারণ করে পরের কোন পরীক্ষাটি প্রযোজ্য।
উত্তরের জন্য পুলে যাওয়ার রুট দরকার
রিমোট-অ্যাক্সেস ক্লায়েন্ট সাধারণত পুল থেকে ঠিকানা পায়, আর ব্যক্তিগত নেটওয়ার্কের সেই পুলে ফেরার রুট দরকার। যে সার্ভারের ডিফল্ট রুট নিজের গেটওয়ের দিকে যায়, সে প্যাকেটটি সেই গেটওয়েকে দিয়ে দেয়, যার পুল কোথায় আছে তা জানা নেই, তাই উত্তর সেখানেই মরে যায়। ক্লায়েন্ট সময় শেষ দেখে কারণ কিছুই ফেরেনি, আর এটি কখনো বের না হওয়া অনুরোধ থেকে আলাদা করা যায় না।
সার্ভার নিজের সাবনেটের জন্য যে রুট ব্যবহার করে তা নয়, ক্লায়েন্ট ঠিকানার জন্য যে রুট বেছে নেয় সেটি পরীক্ষা করুন। এই দুই অনুসন্ধান ভিন্ন উত্তর দিতে পারে, আর এখানে দ্বিতীয়টিই গুরুত্বপূর্ণ। অনুবাদ হলো বিকল্প নকশা এবং এটি সার্ভার যা দেখে তা বদলে দেয়। এটি ফেরার পথ সরল করতে পারে, আবার সার্ভারের লগ থেকে মূল ক্লায়েন্ট ঠিকানাটিও সরিয়ে দেয়, যা ওই ফিল্ডের ওপর গড়া যেকোনো নিয়ম বা প্রতিবেদনকে প্রভাবিত করে।
সার্ভার ক্যাপচারের সাথে গেটওয়ে ক্যাপচার মিলিয়ে দেখুন
সার্ভার থেকে যা বেরোয় আর গেটওয়েতে যা পৌঁছায় তা মিলিয়ে দেখুন। সার্ভারের আউটবাউন্ড ইন্টারফেসে ক্যাপচার আর টানেল গেটওয়েতে ক্যাপচার প্রশ্নের ভিন্ন দুই অর্ধের উত্তর দেয়, আর তাদের মধ্যের ফাঁক ক্ষতির জায়গা নির্দেশ করে।
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
গেটওয়ে নিজে যে অনুরোধ তৈরি করে তা ক্লায়েন্ট পরীক্ষার দুর্বল বিকল্প, কারণ এটি ভিন্ন ঠিকানা থেকে আসে এবং ভিন্ন নিয়মে পড়ে। এজন্যই গেটওয়ে থেকে সফল ping আর ক্লায়েন্ট থেকে ব্যর্থ অনুরোধ একসাথে সত্যি হতে পারে।
পথে একাধিক রাউটার থাকলে পুলে রুট দরকার এমন প্রত্যেকটি পরীক্ষা করুন। সাইট-টু-সাইট নকশায় প্রায়ই দূরবর্তী প্রিফিক্স একাধিক ডিভাইসে জানা থাকা লাগে, আর গেটওয়েকেই টানেল ও ল্যানের মধ্যে ফরওয়ার্ড করতে হয়; strongSwan-এর ফরওয়ার্ডিং নোট এটির sysctl ও ফায়ারওয়াল দিকটি কভার করে।
পুল, প্রিফিক্স ও মালিক লিখে রাখুন
নোটে চারটি তথ্য থাকা উচিত: ক্লায়েন্ট যে পুল পেয়েছে, তার প্রয়োজনীয় ব্যক্তিগত প্রিফিক্স, উত্তরের জন্য দায়ী রাউটার, এবং থাকলে অনুবাদ নিয়ম। এগুলো থাকলে পরে গেটওয়ে বদলানো একটি তুলনা, তদন্ত নয়।
তারপর সাধারণ ক্লায়েন্ট ও প্রকৃত অ্যাপ্লিকেশন অ্যাকাউন্ট দিয়ে আবার পরীক্ষা করুন। অ্যাপ্লিকেশন সুবিধা বাড়ালে প্যাকেটের ফেরার পথ ঠিক হয় না, আর এই নির্ণয়ের সময় অ্যাকাউন্ট বদলালে পরের তুলনা গুলিয়ে যাবে। নকশা যদি অনুবাদের ওপর নির্ভর করে, তবে সার্ভারের লগ যেখানে পড়া হয় সেখানেই তা নথিভুক্ত করুন। অডিট ট্রেইলে অপরিচিত সোর্স ঠিকানা যে দেখে, তাকে টিকিট থেকে ম্যাপিং আবার আবিষ্কার করতে হওয়া উচিত নয়।