VPN বাড়িতে সংযুক্ত হয়, কিন্তু হোটেলের Wi-Fi-তে সময় শেষ হয়
একই ল্যাপটপ, একই অ্যাকাউন্ট, ভিন্ন নেটওয়ার্ক। ত্রুটির কোডটিকে একটি ধাপ হিসেবে পড়ুন, নামটি যাচাই করুন, তারপর কোনো সেটিং বদলানোর আগে বাইরের প্যাকেটটি ধরে নিন।
ল্যাপটপটি বাড়ির Wi-Fi-তে যুক্ত হয়, ক্লায়েন্টটি তিন সেকেন্ডে সংযুক্ত হয়, আর একই প্রোফাইল এক ঘণ্টা পরে হোটেলে ব্যর্থ হয়। এর মধ্যে কিছুই হালনাগাদ হয়নি। সামনে একটি ক্লায়েন্ট নিয়ে এটি ধরে ধরে দেখা মূলত এটা বোঝার বিষয় যে কোন ত্রুটি কোন ধাপের, কারণ কাজের তথ্য ক্লায়েন্ট যে কোডটি ছাপে তাতেই আছে, ব্যর্থ হয়েছে এই কথায় নয়। নিচের চারটি ধাপ ক্রমানুসারে কাজ করুন, তাহলে জানবেন একটি নাম, একটি প্যাকেট, একটি পোর্ট নাকি একটি নীতি আপনাকে প্রত্যাখ্যান করেছে।
ত্রুটির কোডকে রায় নয়, ধাপ হিসেবে পড়ুন
একটি টানেল তৈরি হওয়ার আগে ক্লায়েন্ট তিনটি আলাদা ধাপে পৌঁছায়। এটি সার্ভারের নাম সমাধান করে, নেটওয়ার্কের কোনো কিছু থেকে উত্তর পায়, এবং একটি নিরাপত্তা সংযোগে সম্মত হয়। প্রতিটি ধাপের নিজস্ব ব্যর্থতার বার্তা আছে, আর বিশেষ করে Windows আলাদা আলাদা কোড দিতে উদার, একবার জানলে কোন কোড কোন ধাপের।
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
এই কোডগুলোর মধ্যে দুটি বোঝায় নেটওয়ার্ক নির্দোষ। 789 বোঝায় প্যাকেটগুলি যাচ্ছিল এবং দুই প্রান্ত ক্রিপ্টো নিয়ে একমত হয়নি, যা একটি কনফিগারেশন সমস্যা এবং বাড়িতেই ঠিক করা যায়। 868 বোঝায় কোনো প্যাকেটই বেরোনোর দরকার হয়নি, তাই নাম সমাধান না হওয়া পর্যন্ত টানেলের নকশা অপ্রাসঙ্গিক। কোডটিকে সঠিক ধাপে ভাগ করলে যেকোনো ক্যাপচারের চেয়ে বেশি সময় বাঁচে, কারণ এটি বলে দেয় পরের তিনটি ধাপের কোনটি বাদ দিতে হবে।
ক্লায়েন্টটি Windows না হলে যথাযথভাবে সতর্ক থাকুন। থার্ড-পার্টি ক্লায়েন্ট এগুলোর বেশিরভাগকে "সংযোগ ব্যর্থ" বলে চেপে দেয়, তাই পরের দুটি ধাপ বার্তার ওপর একেবারেই নির্ভর করে না।
টানেলকে দোষ দেওয়ার আগে নামটি যাচাই করুন
হোটেল ও বিমানবন্দরের নেটওয়ার্ক নিয়মিত DNS আটকায়, আর এমন রিজলভার যা পোর্টালের ঠিকানা দিয়ে উত্তর দেয়, তা মৃত সার্ভারের মতো হুবহু দেখতে ব্যর্থতা তৈরি করে। স্থানীয় রিজলভার যা বলে তার সঙ্গে একটি পাবলিক রিজলভারের বলা তুলনা করুন:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"দুটি উত্তর আলাদা হলে আপনাকে ঘুরিয়ে দেওয়া হচ্ছে, আর এটা সমাধান না হওয়া পর্যন্ত বাকি রোগনির্ণয় বৃথা। বিশেষ করে পোর্টালের ঠিকানা সানন্দে TCP সংযোগ গ্রহণ করবে এবং তারপর আটকে যাবে, তাই ব্রাউজার দিয়ে পরীক্ষা করলে এটি ফায়ারওয়াল ব্লকের মতো দেখাতে পারে।
এখন নিশ্চিত করুন আপনি যে ঠিকানায় পৌঁছাতে চান সেটিই ব্যবহৃত হচ্ছে। কিছু ক্লায়েন্ট প্রোফাইলের আয়ু জুড়ে আগের সমাধানটি ক্যাশে রাখে, তাই DNS বদলের পরে পুনঃসংযোগও পুরনো ঠিকানায় যায়। নতুন করে পরীক্ষার আগে ক্লায়েন্ট সম্পূর্ণ বন্ধ করুন, একই জানালায় ডিসকানেক্ট ও কানেক্ট চাপার বদলে।
কোন বাইরের প্যাকেটটি হারিয়ে যায় তা বের করুন
টানেলের একটি বাইরের প্রবাহ আছে যা সম্পূর্ণভাবে আপনার আর সার্ভারের মধ্যকার পথের, আর ঠিক সেই প্রবাহটিকেই মধ্যস্থ ডিভাইস শ্রেণিবদ্ধ করে ফেলে দেয়। এটি ক্লায়েন্টে ক্যাপচার করুন, তারপর একটি কাজ করা নেটওয়ার্কের সঙ্গে ব্যর্থটির তুলনা করুন। Windows-এ প্রথম দেখার জন্য অন্তর্নির্মিত ক্যাপচারই যথেষ্ট:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlআপনি দেখতে চান আপনার প্যাকেটগুলো আদৌ বেরোচ্ছে কি না, এবং কিছু ফিরে আসছে কি না। বেরোনো প্যাকেটের কোনো উত্তর না থাকা মানে পথ বা দূরপ্রান্ত সেগুলো ফেলে দিচ্ছে; আদৌ কিছু না বেরোলে ক্লায়েন্ট কখনো পাঠানোর পর্যায়ে পৌঁছায়নি, যা নাম সমাধান বা স্থানীয় ফায়ারওয়াল নীতির দিকে ইঙ্গিত করে।
ফোনের হটস্পটে একই পরীক্ষা আবার করুন। এটি আপনার কাছে থাকা সবচেয়ে তথ্যবহুল তুলনা, কারণ এটি ল্যাপটপ, ক্লায়েন্ট ও ক্রেডেনশিয়াল একই রাখতে রেখে পথ থেকে হোটেলের প্রতিটি বাক্স সরিয়ে দেয়। হটস্পটে টানেল উঠে এলে সার্ভারের দিকে তাকানো বন্ধ করুন। সেখানেও ব্যর্থ হলে আপনার ক্লায়েন্ট বা অ্যাকাউন্টের সমস্যা আছে যা নেটওয়ার্ক কখনো ঘটায়নি।
একটি ট্রান্সপোর্ট বদলে আবার পরীক্ষা করুন
বাইরের প্রবাহ ফেলে দেওয়া হচ্ছে জেনে গেলে ব্যবহারিক প্রশ্ন হলো নেটওয়ার্ক কোন প্রবাহকে অনুমতি দেয়। বেশিরভাগ সীমিত নেটওয়ার্ক বহির্গামী TCP 443 অনুমতি দেয়, কারণ তা ছাড়া তারা চলে না, তাই লিসেনার সেখানে সরানোই স্বাভাবিক উত্তর। OpenVPN-এ এটি সার্ভার না বদলানো পর্যন্ত ক্লায়েন্ট-পার্শ্বের একটি সুইচ:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4IPsec ক্লায়েন্টের নিজস্ব সেটিংস প্যানেলে সমতুল্য একটি নব আছে, সাধারণত IPsec over TCP বা NAT traversal নামে বর্ণিত। এটি বদলানোও একটি রোগনির্ণয়: টানেল TCP-তে উঠে UDP-তে মরে গেলে আপনি প্রমাণ করলেন নেটওয়ার্ক UDP ফিল্টার করে, আর যে সেটিংটি ওই সাইটে প্রতিবার দরকার হবে তাও খুঁজে পেলেন।
প্রথম চেষ্টাতেই রাউটারের ফিচার বন্ধ করার প্রলোভন প্রতিরোধ করুন। হোটেল নেটওয়ার্কে stateful inspection বা flood protection বন্ধ করা আপনার জন্য যেভাবেই হোক নেই, আর নিজের সরঞ্জামে এটি একটি ল্যাপটপের বিনিময়ে সত্যিকারের সুরক্ষা বদল করে। কোন সেটিং ফলাফল বদলাল তা টুকে রাখুন, তারপর সেটি ফিরিয়ে আনুন এবং নেটওয়ার্ক যে ট্রান্সপোর্ট ইতিমধ্যে অনুমতি দেয় সেটি খুঁজুন।
দ্বিতীয় নেটওয়ার্কে একই প্রোফাইল যাচাই করুন
টিকিট বন্ধ করার আগে প্রমাণ করুন পরিবর্তনটি ভবন ছাড়ার পরেও টিকে আছে। মূল নেটওয়ার্কে মূল সেটিংসে আবার সংযোগ করুন, প্রথম ত্রিশ সেকেন্ড ক্যাপচার করুন, এবং ক্লায়েন্ট হটস্পটে যে অবস্থায় পৌঁছেছিল সেই একই অবস্থায় পৌঁছায় কি না নিশ্চিত করুন:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressশেষ কমান্ডটি যে পার্থক্য সামনে আনে তা ধরে রাখার যোগ্য: প্রোফাইল সংযুক্ত টানেল রিপোর্ট করতে পারে যদিও তার ভেতরের রাউটিং ভুল, আর তা "VPN চালু আছে কিন্তু কিছুই কাজ করছে না" তৈরি করে, যা ভিন্ন একটি নিবন্ধ। আপনার সম্পাদনার পরে টানেলের ধরন বদলে থাকলে, প্রোফাইলটি আপনি যে পরীক্ষা করেছিলেন সেটি নয়।
তারপর অনুসন্ধানটি এমন জায়গায় লিখুন যেখানে পরের মানুষটি তাকাবে। "এই সাইটে কর্পোরেট প্রোফাইলের TCP 443 দরকার; UDP 500 হোটেল ফিল্টার করে" এমন একটি বাক্য যা নিয়ে সহকর্মী কাজ করতে পারেন। "হোটেলে VPN অস্থির" তা নয়, এবং এটি নিশ্চিত করে আগামী মাসে একই ঘণ্টা আবার নষ্ট হবে।