রিবুটের পর SSH শুনছে না: VPN ঠিকানাটি দেরিতে আসে

সেটআপের সময় আপনি SSH-কে টানেল ঠিকানায় বাঁধেন, এটি কাজ করে, আর পরের রিবুটের পর কেউ হাতে সার্ভিসটি পুনরায় চালু না করা পর্যন্ত কেউ লগ ইন করতে পারে না। ক্রেডেনশিয়াল সমস্যা নয়। ডেমন কার্নেলের কাছে এমন একটি ঠিকানা চেয়েছিল যা তখনো ছিল না, বাইন্ড ব্যর্থ হয়েছিল, এবং বার্তাটি বুট লগে চলে গিয়েছিল। যা প্রমাণীকরণের সমস্যা মনে হয়, তা আসলে স্টার্টআপ ক্রমের সমস্যা।

বাইন্ড ত্রুটি আসলে যা বলে

শোনার সকেট অবশ্যই এমন ঠিকানায় তৈরি হতে হবে যা সেই মুহূর্তে বিদ্যমান। যখন VPN ইন্টারফেস পরে ওঠে, কেবল টানেল ঠিকানায় বাঁধতে কনফিগার করা ডেমনটির সংযুক্ত হওয়ার কিছু থাকে না। কনফিগারেশন সিনট্যাক্সগতভাবে বৈধ থাকে; পরিবেশটি কেবল প্রস্তুত ছিল না। ম্যানুয়াল স্টার্ট থেকে চলা একটি সার্ভিস কখনো বুট পথটি পরীক্ষা করে না, তাই ত্রুটিটি কেবল পরের রিস্টার্টেই দেখা যায়। বাইন্ড ব্যর্থতার টাইমস্ট্যাম্পের সাথে ঠিকানা বরাদ্দের টাইমস্ট্যাম্প তুলনা করুন, ক্রমটি স্পষ্ট হয়ে যাবে।

কনফিগারেশনের বৈধতা ও রানটাইম প্রস্তুতি আলাদা বৈশিষ্ট্য। দুটোই পরীক্ষা করুন, কারণ একটি কিছু না বলেই ব্যর্থ হয়।

কোন প্রসেস পোর্টটির মালিক

ডেমন সবসময় লিসেনার তৈরি করা উপাদান নয়। সকেট অ্যাক্টিভেশন সেই দায়িত্ব একটি ইউনিটে সরিয়ে দেয়, এবং তখন ডেমন পুনরায় চালু করলে কিছুই বদলায় না।

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

সকেট তালিকা দেখায় কোন প্রসেস পোর্টটি এবং কোন ঠিকানায় ধরে আছে, আর ইউনিট ডাম্প দেখায় সকেট ইউনিট আদৌ আছে কি না। অ্যাক্টিভেশন চালু থাকলে ঠিকানাটি সকেট ইউনিটের অন্তর্গত এবং ডেমন ফাইল কর্তৃত্বপূর্ণ নয়। লক্ষণ থেকে অনুমান না করে প্রকৃত বাইন্ড ত্রুটির জন্য বুট লগ পড়ুন। সকেট ইউনিট না থাকার অর্থ কেবল চিরাচরিত বিন্যাস, যেখানে ডেমন সরাসরি বাঁধে।

প্রস্তুতিকে স্পষ্ট করুন, ঘুম নয়

নির্দিষ্ট বিলম্ব একটি অনুমান যা দ্রুত হার্ডওয়্যার ও ধীর নেটওয়ার্ককে একইভাবে বিবেচনা করে। বরং নির্ভরতাটি প্রকাশ করুন: ঠিকানার জন্য অপেক্ষা করুন, তারপর শুরু করুন।

ip -4 addr show dev tun0
systemctl edit ssh.service

একটি ExecStartPre কমান্ড যোগ করুন যা ঠিকানা না আসা পর্যন্ত পুনরাবৃত্তি করে, অথবা ইন্টারফেসের মালিক নির্দিষ্ট নেটওয়ার্ক টার্গেটের পরে ইউনিটটি সাজান। উভয় পদ্ধতিই নির্ভরতাটি এমন জায়গায় লিপিবদ্ধ করে যা পরবর্তী প্রশাসক পড়তে পারেন। লুপের একটি টাইমআউট দরকার, নইলে ব্যর্থ VPN ত্রুটি রিপোর্ট করার বদলে ঝুলে থাকা ইউনিট রেখে যায়। তারপর নিশ্চিত করুন যে ডেমন টানেল ঠিকানায় বাঁধে আর সাধারণ ইন্টারফেস আপনার ফিল্টার নিয়মের অধীনে থাকে।

একটি পরিচ্ছন্ন বুট ও পুনঃসংযোগ পরীক্ষা করুন

সবকিছু অনলাইনে আসার পর ম্যানুয়াল রিস্টার্ট বুট ক্রম সম্পর্কে কিছুই প্রমাণ করে না। টানেল স্বয়ংক্রিয়ভাবে ওঠার জন্য কনফিগার করা অবস্থায় মেশিনটি রিবুট করুন এবং হস্তক্ষেপ ছাড়াই লিসেনার দেখা দিচ্ছে কি না লক্ষ্য করুন।

systemctl status ssh.service
ss -ltnp 'sport = :22'

তারপর টানেলটি নামিয়ে আবার স্থাপন করুন, কারণ পুনঃসংযোগ ঠিকানাটি বদলাতে পারে এবং হার্ডকোড করা বাইন্ড তা অনুসরণ করবে না। পরীক্ষার সময় একটি আউট-অব-ব্যান্ড পুনরুদ্ধার পথ রাখুন, যাতে খারাপ ক্রম পরিবর্তন আপনাকে হোস্ট থেকে লক আউট করতে না পারে।

সফলতার মাপকাঠি হলো এমন একটি লিসেনার যা তার নথিভুক্ত নির্ভরতার অধীনে দেখা দেয়, কেউ যেটি পুনরায় চালু করতে মনে রেখেছিল এমন নয়।