পিং ওয়াচডগ ভাঙা টানেলকে সুস্থ টানেল থেকে আলাদা করতে পারে না
ইন্টারনেটে পিং দেখতে যতটা সহজ, তার চেয়ে কম প্রমাণ করে। টানেলের ভেতর থেকে পরীক্ষা করুন, পদক্ষেপের আগে ব্যর্থতা গুনুন এবং ফেইলওভারকে আলাদা সিদ্ধান্ত হিসেবে ধরুন।
তিনটি শর্ত ঠিক করে ওয়াচডগ সাহায্য করে না ক্ষতি করে: পরীক্ষা কী আলাদা করতে পারে, কতগুলো ধারাবাহিক ব্যর্থতা পদক্ষেপকে ন্যায্যতা দেয়, এবং পদক্ষেপটি পুনঃসংযোগ না ফেইলওভার। একটি পাবলিক ঠিকানায় পিং করা cron লাইন এগুলোর কোনোটিরই ভালো উত্তর দেয় না। এটি সুস্থ টানেল পুনঃসংযোগ করে এবং ভাঙা টানেল রেখে দেয়, এবং দুটোই কোনো রেকর্ড ছাড়াই করে। যে নকশা ধরে রাখার যোগ্য, তা এই তিনটি পছন্দকে স্পষ্ট করে।
পরীক্ষাটিই সেই অংশ যা বাকি সবকিছু ঠিক করে।
ইন্টারনেটে পিং আসলে কী প্রমাণ করে
একটি পাবলিক রিজলভারে পিং করলে বোঝা যায় স্থানীয় ইন্টারনেট পথ সচল। এটি প্রমাণ করে না টানেল ট্রাফিক বহন করছে, আর পূর্ণ-টানেল প্রোফাইলে পিং নিজেই টানেলের ভেতর দিয়ে যায়, তাই সুস্থ উত্তর ও ভাঙা টানেল একসাথে থাকতে পারে, যদিও ক্লায়েন্ট তখনো প্যাকেট ফরওয়ার্ড করছে। প্রোফাইল যদি নামের খোঁজ টানেলের ভেতর দিয়ে পাঠায়, তাহলে DNS ব্যর্থতা মৃত সংযোগ হিসেবে পড়া হয় এবং এমন পুনঃসংযোগ শুরু হয় যা কিছুই সারাতে পারে না।
ত্রুটির দুই দিকের কোনোটিই এক্সিট কোডে দেখা যায় না। সেই সংকেতের ওপর গড়া ওয়াচডগ হলো cron সময়সূচিসহ একটি মুদ্রা নিক্ষেপ।
টানেলের পেছনে যা থাকে তা পরীক্ষা করুন
ip -brief addr show tun0 ip route get 10.100.20.10 nc -z -w3 10.100.20.10 443
ভেতর থেকে পরীক্ষা করুন, সবচেয়ে সস্তা যাচাই আগে। ইন্টারফেসের অস্তিত্ব বলে টানেল উঠেছে; পরিচিত অভ্যন্তরীণ ঠিকানায় রুট খোঁজা বলে ট্রাফিক সেখানে ঢুকবে; অপর পাশের হোস্টে TCP পরীক্ষা বলে সত্যিই কিছু উত্তর দিচ্ছে। কেবল echo অনুরোধ বিভ্রান্ত করে: অনেক অভ্যন্তরীণ হোস্ট আনন্দে TCP-তে উত্তর দেয় কিন্তু ICMP ফেলে দেয়, তাই পিংয়ের ওপর গড়া ওয়াচডগ এমন টানেল বারবার পুনঃসংযোগ করে যা কখনো কাজ করা থামায়নি।
পরীক্ষাকে সময়ে সীমিত রাখুন এবং তাকে আলাদা এক্সিট স্ট্যাটাস দিন। যে পরীক্ষা ত্রিশ সেকেন্ড ঝুলে থাকে, সে ওয়াচডগকে অন্তর্নির্মিত বিলম্বসহ বিভ্রাট শনাক্তকারীতে বদলে দেয়।
এক লাইন আর একটি লুপের মধ্যে বেছে নিন
* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect
cron এন্ট্রি এক লাইনের, স্মৃতিহীন, যা এমন ল্যাপটপে মানায় যেখানে অতিরিক্ত পুনঃসংযোগ কিছুই খরচ করে না। তত্ত্বাবধানে চলা লুপ একটি কাউন্টার রাখে এবং কয়েকবার মিসের পরেই কাজ করে, যা অস্থির সংযোগকে পুনঃসংযোগের ঝড় তোলা থেকে থামায়। যেভাবেই হোক, এটি একটি সুপারভাইজারের অধীনে চালান যাতে ক্র্যাশ কাটিয়ে ওঠে এবং জার্নালে লেখে। বাছাই করুন অতিরিক্ত পুনঃসংযোগ গুরুত্বপূর্ণ কি না তার ভিত্তিতে, কোন সংস্করণ ছোট তার ভিত্তিতে নয়।
failures=0 while sleep 30; do if nc -z -w5 10.100.20.10 443; then failures=0 else failures=$((failures+1)); fi if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi done
সেই লুপ একটি উইন্ডোতে অনুপাতের বদলে ধারাবাহিক ব্যর্থতা গোনে। উইন্ডোর জন্য ঘড়ি আর নমুনার স্মৃতি দরকার, আর হাতে লেখা ওয়াচডগের বেশিরভাগ বাগ ঠিক সেই হিসাবেই বাস করে।
ফেইলওভার একটি আলাদা সিদ্ধান্ত
সার্ভার বদলানো পুনঃসংযোগ থেকে আলাদা। আগে পুরোনো সংযোগ ছিঁড়ে ফেলুন, কারণ প্রথমটি যখন ঠিকানা ধরে আছে তখন দ্বিতীয় ক্লায়েন্ট শুরু হলে সংঘর্ষ হবে। বদলানোর আগে ধারাবাহিক ব্যর্থতা গুনুন, চেষ্টার সীমা দিন, এবং নতুন সংযোগ ওঠার পর আবার পরীক্ষা করুন, connect কমান্ডের এক্সিট স্ট্যাটাসে ভরসা না করে। ভুল কনফিগারেশন লুপে প্রতিটি সার্ভার ঘুরে দেখা উচিত নয়।
পূর্ণ টানেলের ভেতর থেকে VPN সার্ভারের নিজের পাবলিক ঠিকানা পরীক্ষা করবেন না। সেই যাচাই যে জিনিসটি পরীক্ষা করছে তার ওপরই নির্ভর করে, এবং যে পথ যাচাই করার কথা ছিল তা না থাকলেও সাফল্য জানায়।
কোন পরীক্ষা চলল, কী ফেরত দিল এবং কী পদক্ষেপ এল তা লিখে রাখুন। সেই রেকর্ড রহস্যময় পুনঃসংযোগকে একটি রোগনির্ণয়যোগ্য ঘটনায় বদলে দেয়।