পাবলিক VPN কনফিগ আর কাজ করছে না? ব্যর্থতার স্তরটি পড়ুন
ডাউনলোড করা প্রোফাইল এক দিনে একটি হোস্ট বর্ণনা করে। কোন দাবিটি ভেঙেছে তা পড়ুন, প্রতিপক্ষ যে সার্টিফিকেট দেয় তা যাচাই করুন, এবং যাচাইকরণ কখনো বন্ধ করবেন না।
প্রোফাইলটি মঙ্গলবার কাজ করছিল, আর শুক্রবার ক্লায়েন্ট ত্রিশ সেকেন্ড ঘুরে ঘুরে হাল ছেড়ে দেয়। আপনার মেশিনে কিছুই বদলায়নি। ঠিক এটাই মূল কথা: ডাউনলোড করা কনফিগারেশন এক মুহূর্তে একটি হোস্ট বর্ণনা করে, আর ওপারের অপারেটরের সেই বর্ণনা সত্য রাখার কোনো বাধ্যবাধকতা নেই। প্রলোভন হলো টানেল ফিরে আসা পর্যন্ত নিরাপত্তা সেটিংস সম্পাদনা শুরু করা। এই প্রবৃত্তিই মানুষকে সার্টিফিকেট যাচাই বন্ধ করা প্রোফাইল চালাতে নিয়ে যায়, যা টানেল একেবারেই না থাকার চেয়েও খারাপ।
ফাইলটি একটি মুহূর্ত বর্ণনা করে, কোনো চুক্তি নয়
কনফিগারেশন ফাইল হলো কিছু দাবির সমষ্টি: এই হোস্টনাম এই পোর্টে এই প্রোটোকলে শোনে, এই নামের সঙ্গে মেলে এমন সার্টিফিকেট উপস্থাপন করে, এবং এই ক্রেডেনশিয়াল গ্রহণ করে। এর যেকোনো একটি সত্য হওয়া বন্ধ করলেই ফাইলটি পুরোনো হয়ে যায়, আর সমাধান সীমার অপারেটরের দিকে, আপনার সেটিংসে নয়।
পাবলিক নোড তালিকা স্বভাবতই এটি স্পষ্ট করে তোলে। নোডগুলো স্বেচ্ছাসেবকরা চালান, সেগুলো আসে ও যায়, ঠিকানা পুনরায় ব্যবহৃত হয় এবং পোর্টগুলো তাদের পেছনে থাকা নেটওয়ার্ক দ্বারা ব্লক হয়। তালিকাটি একটি স্ন্যাপশট যা পুনরায় তৈরি হয়, আর আপনার ডিস্কের কপিটি পুরোনো স্ন্যাপশটের একটি ছবি।
বাণিজ্যিক সেবা আরও ধীরে বদলায়, তবে কখনোই নয়। সার্টিফিকেট কর্তৃপক্ষ পরিবর্তিত হয়, লিসেনার শেয়ার করা ঠিকানা থেকে আলাদা ঠিকানায় সরে যায়, পুরোনো প্রোটোকল প্রত্যাহার হয় এবং নতুন সাইফার তালিকা আসে। এর প্রতিটি অদৃশ্য থাকে যতক্ষণ না আপনার ক্লায়েন্ট সংযোগের চেষ্টা করে ফাইলের প্রত্যাশার চেয়ে ভিন্ন উত্তর পায়।
কোনো সেটিংসে হাত দেওয়ার আগে ব্যর্থতার স্তরটি পড়ুন
ত্রুটির বার্তা বলে কোন দাবিটি ভেঙেছে, আর প্রতিটি দাবির প্রতিকার সম্পূর্ণ ভিন্ন। হোস্টনাম আর রিজলভ না হলে সাইফার সম্পাদনা করা একটি বিকেল নষ্ট করে এবং কাউকে কিছু শেখায় না।
| What happens | The assertion that broke | Supported response |
|---|---|---|
| Name never resolves | The host still exists under that name | Get a current endpoint from the operator |
| TCP connect times out | The listener is on that port and reachable | Check the current published port, then the local network |
| TLS or key exchange fails | The peer presents the expected identity | Compare the certificate, not the cipher list |
| Authentication rejected | The account is still valid | Get credentials reissued or stop using the service |
dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/nullমাঝের লাইনটি ব্লক হওয়া পথকে ভাঙা হ্যান্ডশেক থেকে আলাদা করে, আর তৃতীয়টি প্রকৃতপক্ষে উপস্থাপিত সার্টিফিকেটের ইস্যুয়ার ও বৈধতার তারিখ দেখায়। সেই ইস্যুয়ার যদি প্রোফাইলে পিন করা ইস্যুয়ার না হয়, তাহলে সার্টিফিকেট বদলে গেছে, এবং কোনো ক্লায়েন্ট-সাইড অপশন পুরোনো পিনকে আবার সঠিক করতে পারবে না।
সার্টিফিকেট ও পরিচয়ের পরিবর্তনগুলোই নীরব
বেশিরভাগ ব্যর্থতা নিজেকে ঘোষণা করে। পরিচয়ের পরিবর্তন করে না, কারণ যে ক্লায়েন্ট সার্টিফিকেটের নাম পিন করে সে সম্পূর্ণ ভালো একটি নতুন সার্টিফিকেট প্রত্যাখ্যান করবে এমন বার্তা দিয়ে যা অনেকে বাগ হিসেবে পড়ে। টানেল ঠিক আছে। পিনটি পুরোনো।
কিছু সিদ্ধান্তে পৌঁছানোর আগে পরিচয়ের অপশনগুলো খুঁজুন:
grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -datesপ্রোফাইলে এমবেড করা CA থাকলে এবং অপারেটর নতুন কর্তৃপক্ষে সরে গেলে, পুরোনো ফাইল নতুন সার্ভার যাচাই করতে পারে না। CA ব্লকটি অপারেটরের প্রকাশিত ব্লক দিয়ে প্রতিস্থাপন করা বৈধ সমাধান। যাচাইকরণের নির্দেশ মুছে ফেলা নয়, আর এগুলো একই কী-স্ট্রোক, ফলাফল সম্পূর্ণ ভিন্ন।
অপারেটরের কোনো পরিবর্তন ছাড়াও ক্লায়েন্ট আপগ্রেড একই লক্ষণ তৈরি করতে পারে। যে অপশনগুলো নীরবে সহ্য করা হতো সেগুলো প্রত্যাখ্যাত হয়, বা একটি বাতিল প্রোটোকল সরিয়ে দেওয়া হয়। এটি আপনার সফটওয়্যারে একটি সামঞ্জস্যের সীমা, আর সার্ভারকে দোষ দেওয়ার আগে একই ক্লায়েন্টে দ্বিতীয় প্রোফাইল পরীক্ষা করা উচিত।
শুধু অপারেটরই বৈধ প্রতিস্থাপন প্রকাশ করতে পারে
কোনো নোড হারিয়ে গেলে প্রতিস্থাপনটিকে আসতে হবে সেই একই উৎস থেকে যা মূলটি প্রকাশ করেছিল। সরাসরি বার্তায় আসা একটি প্রোফাইল, কারণ এটি «একই সার্ভার নাম ব্যবহার করে», তা অজানা পক্ষের একটি অযাচাইকৃত কনফিগারেশন, আর এটি আমদানি করা সেই পক্ষকে আপনার রাউটিংয়ের নিয়ন্ত্রণ দেয়।
পরীক্ষাটি সস্তা। প্রকাশিত অবস্থান থেকে বর্তমান ফাইলটি আনুন, এন্ডপয়েন্ট ও প্রোটোকল তালিকার সঙ্গে মিলিয়ে দেখুন, এবং ফাইলের নামে ভরসা না করে CA উপাদানের ফিঙ্গারপ্রিন্ট নিশ্চিত করুন:
curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpnদুটি হ্যাশ যদি কেবল শ্বেতস্পেসে ভিন্ন হয়, তবে এটি ফরম্যাটিং পরিবর্তন। যদি এন্ডপয়েন্টে ভিন্ন হয়, তবে অপারেটর কিছু সরিয়েছে এবং প্রকাশিত ফাইলটিই কর্তৃত্ব। প্রকাশিত ফাইল আপনার কাছে থাকা ফাইলের চেয়ে পুরোনো হলে আপনি সম্ভবত একটি ক্যাশ দেখছেন, আর পুরোনো উত্তর আপনাকে ভুল দিকে পাঠাবে।
পুরোনো এন্ট্রি অবসর দিন এবং কী ঘটেছে তা লিখে রাখুন
একটি কার্যকর প্রতিস্থাপন যাচাই হওয়ার পর পুরোনো প্রোফাইলটি ফলব্যাক হিসেবে রাখবেন না, মুছে ফেলুন। অর্ধেক সংযোগ করা পুরোনো এন্ট্রি একটি ফাঁদ: বিভ্রাটের সময় এটি বেছে নেওয়া হবে, ধীরে ব্যর্থ হবে, এবং যে ব্যক্তি ডিবাগ করবে সে প্রথম দশ মিনিট ভুল ফাইলে ব্যয় করবে।
কনফিগারেশনের বাইরে একটি সংক্ষিপ্ত রেকর্ড রাখুন: তারিখ, পুরোনো এন্ডপয়েন্ট, ব্যর্থতার স্তর এবং কী এটি প্রতিস্থাপন করেছে। পাবলিক নোড বদলায়, আর ছয় সপ্তাহ পরে একই প্রশ্ন অন্য একজনের সঙ্গে আসে। নোট ফাইলের একটি লাইন সেকেন্ডে তার উত্তর দেয়।
যদি একটি নেটওয়ার্ক থেকে প্রতিটি নোড একইভাবে ব্যর্থ হয় আর অন্যটি থেকে কোনোটিই না হয়, তবে প্রোফাইল সম্পাদনা বন্ধ করে স্থানীয় পথটি দেখুন। একটি ক্যাপটিভ পোর্টাল, ফিল্টার করা পোর্ট পরিসর বা ইন্টারসেপ্ট করা প্রক্সি অসংযুক্ত প্রভাইডারদের ক্ষেত্রে অভিন্ন ত্রুটি তৈরি করবে, আর সেই ধরনটিই একমাত্র সংকেত যে সমস্যাটি কখনোই ফাইলে ছিল না।