VPN-এর মাধ্যমে দূরবর্তী SSH: টানেল যা করে না
একটি VPN একটি SSH সার্ভারকে পৌঁছানোযোগ্য করে, তার বেশি কিছু নয়। তিনটি শর্ত ঠিক করে এটি উপযুক্ত কি না, আর ব্যর্থতার ধাপ বলে দেয় কোন স্তর দায়ী।
একটি VPN একটি SSH সার্ভারকে একটি ব্যক্তিগত পথ দেয় এবং পোর্ট 22-এ একটি সর্বজনীন শ্রোতার প্রয়োজন দূর করে। এটি হোস্টকে প্রমাণিত করে না, ব্যবহারকারীকে অনুমোদন করে না, বা কোন অ্যাকাউন্ট লগ ইন করতে পারবে তা ঠিক করে না। এসব SSH-এর কাজই থাকে। একটি VPN সার্ভারে পৌঁছানোর সঠিক উপায় কি না তা তিনটি শর্তের উপর নির্ভর করে, আর টানেল কেবল সম্ভাব্য উত্তরগুলির একটি।
টানেল কী বদলায় এবং SSH এখনও কী ঠিক করে
টানেল পৌঁছানোযোগ্যতা বদলায়: কোন ঠিকানায় পৌঁছানো যায় এবং কোথা থেকে। TCP সংযোগ পৌঁছানোর পরে কী ঘটে তা এটি বদলায় না, যেখানে সার্ভার একটি হোস্ট কী উপস্থাপন করে এবং ব্যবহারকারীর পরিচয় চায়।
দুই স্তরকে আপনার মাথায় এবং আপনার নথিতে আলাদা রাখুন। একটি VPN লগইন প্রমাণ করে কে নেটওয়ার্ক ব্যবহার করতে পারে। এটি লক্ষ্যে কোন অ্যাকাউন্ট আছে সে সম্পর্কে কিছুই বলে না, এবং প্রতিটি পৌঁছানোযোগ্য মেশিনে সাইন ইন করার অনুমতি নয়।
ব্যর্থতার ধরনগুলিও আলাদা, এবং এটাই ঘটনার সময় বিচ্ছেদটিকে উপযোগী করে তোলে।
তিনটি শর্ত যা অ্যাক্সেস মডেল ঠিক করে
প্রথমত, সার্ভারটি কি আপনার নেটওয়ার্কের বাইরের লোকেদের জন্য পৌঁছানোযোগ্য হওয়া দরকার? যদি না হয়, একটি ব্যক্তিগত পথ এবং একটি বাস্টিয়ন বা একটি মেশ ছোট নকশা। দ্বিতীয়ত, ক্লায়েন্ট জনগোষ্ঠী কি সত্যিই VPN ক্লায়েন্ট চালাতে পারে, যাদের সীমাবদ্ধতা সহ পরিচালিত ডিভাইসে আছে তাদের সহ?
তৃতীয়ত, আপনার কি প্রতি-পরিষেবা নিয়ন্ত্রণ দরকার নাকি প্রতি-ব্যবহারকারী নিয়ন্ত্রণ? একটি VPN নেটওয়ার্ক পৌঁছানো দেয়; SSH অ্যাকাউন্ট অ্যাক্সেস দেয়। যদি প্রয়োজন হয় যে একজন ঠিকাদার একটি হোস্টে পৌঁছায় এবং আর কিছুই নয়, সেটি একটি অনুমোদনের প্রয়োজন এবং কেবল টানেল তা প্রকাশ করতে পারে না।
এই তিনটির উত্তর দিন এবং মডেল নিজেই বেছে নেবে। এগুলি এড়িয়ে যান এবং ক্লায়েন্ট রোলআউট এড়াতে আপনি SSH সর্বজনীনভাবে প্রকাশ করেন।
SSH-কে দোষারোপ করার আগে ব্যক্তিগত পথ নিশ্চিত করুন
অনুমোদিত VPN-এ সংযোগ করুন এবং লক্ষ্যের নথিভুক্ত ব্যক্তিগত নাম বা ঠিকানা ব্যবহার করুন। তারপর নির্বাচিত রুট, গেটওয়ের অনুমতি এবং ক্লায়েন্টের দিকে ফেরার পথ পরীক্ষা করুন। সঠিকভাবে রিজলভ হওয়া একটি নাম এই প্রমাণ নয় যে ঠিকানাটি উদ্দিষ্ট টানেল নেয়, কারণ ওভারল্যাপিং স্থানীয় এবং দূরবর্তী প্রিফিক্স অনুরোধটি সম্পূর্ণ ভিন্ন কোথাও পাঠাতে পারে। এই পার্থক্যটি রানবুকে লেখার যোগ্য।
যদি সংযোগ কখনও পৌঁছায় না, নিশ্চিত করুন সার্ভারটি আপনার প্রত্যাশিত ইন্টারফেসে শুনছে এবং এর হোস্ট ফায়ারওয়াল যে উৎসটি আসলে দেখে তা অনুমোদন করে। একটি গেটওয়ে NAT সেই উৎসটি পুনরায় লিখতে পারে, তাই ক্লায়েন্টের টানেল ঠিকানার জন্য লেখা একটি অনুমোদন তালিকা কখনও মিলতে পারে না।
এই অমিলটিই VPN-এর উপর সবচেয়ে সাধারণ স্ব-সৃষ্ট SSH ব্যর্থতা।
মিলিত ত্রুটি নয়, ব্যর্থতার ধাপ পড়ুন
তিনটি ধাপ তিনটি ভিন্ন বার্তা তৈরি করে, এবং তার মধ্যে কেবল একটি শংসাপত্র সম্পর্কে।
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
VPN এবং SSH শংসাপত্র একসাথে রিসেট করার বদলে সঠিক ত্রুটি এবং সার্ভারের নিজস্ব লগ ব্যবহার করুন। দুটোই রিসেট করা হল পাঁচ মিনিটের রোগনির্ণয় দুই দিনের পরিচয় ঘটনায় পরিণত হওয়ার উপায়।
বিস্তারিত আউটপুট দেখায় আপনি কোন ধাপে পৌঁছেছেন:
ssh -vv [email protected]হোস্ট কী এবং অনুমোদন অক্ষত রাখুন
উদ্দিষ্ট বিশ্বস্ত প্রক্রিয়ার মাধ্যমে হোস্ট কী যাচাই করুন, বিশেষত সার্ভার প্রতিস্থাপনের পরে। অপ্রত্যাশিত পরিবর্তিত-কী সতর্কতা হল একমাত্র বার্তা যা আপনি শুধু VPN সংযুক্ত হয়েছে বলে উপেক্ষা করতে পারবেন না, কারণ একটি ব্যক্তিগত টানেল গন্তব্যটিকে আপনার ভাবা মেশিন করে না। সংযোগ থেকে স্বাধীনভাবে বিশ্বস্ত একটি উৎসের সাথে ফিঙ্গারপ্রিন্ট পরীক্ষা করুন।
সার্ভারের দিকে, নিশ্চিত করুন যে অ্যাকাউন্টটি অনুমোদিত এবং আপনি যে প্রমাণীকরণ পদ্ধতি কনফিগার করেছেন সেটিই প্রস্তাবিত হচ্ছে। একটি কী যা উপস্থিত কিন্তু উপেক্ষিত হয় সাধারণত নেটওয়ার্কের নয় বরং অনুমতি বা কনফিগারেশনের সমস্যা।
পরিষেবা অ্যাক্সেস প্রয়োজনীয় পরিচয়গুলিতে সীমাবদ্ধ রাখুন এবং নেটওয়ার্ক পরিবর্তনের জন্য একটি অনুমোদিত পুনরুদ্ধার পথ রাখুন।