ইন্টারনেট লিঙ্ক ছাড়া LAN-এ Raspberry Pi পরিচালনা

একটি ব্যক্তিগত LAN-এ দুটি ডিভাইস কোনো আপলিঙ্ক ছাড়াই সুরক্ষিত ট্র্যাফিক বিনিময় করতে পারে। যা তারা করতে পারে না তা হল তাদের নির্বাচিত নিরাপত্তা মডেল যে পরিষেবাগুলো আশা করে সেগুলো জাদু করে তৈরি করা। তাই কাজটা অর্ধেক বাছাই আর অর্ধেক তালিকা: কাজের সঙ্গে মানানসই সুরক্ষা বেছে নিন, তারপর নীরবে ইন্টারনেটের দিকে হাত বাড়াবে এমন সবকিছু তালিকাভুক্ত করুন।

এই নির্দেশিকার অনুমান হল দুটি ডিভাইসেরই একই ব্যক্তিগত নেটওয়ার্কে অনুমোদিত ঠিকানা আছে। দুটোই একই wifi-তে যুক্ত হয়েছে এই সত্য থেকে পৌঁছানোযোগ্যতা অনুমান করবেন না; সংযোগ, রাউটিং ও অ্যাক্সেস নিয়ম এখনও তা নির্ধারণ করে।

কাজ অনুযায়ী সুরক্ষা বাছুন, অভ্যাস অনুযায়ী নয়

একটি টার্মিনাল সেশন বা সমর্থিত ফাইল-প্রশাসন কাজ SSH-এর উপযুক্ত, যার স্থাপত্য সার্ভার প্রমাণীকরণ, ব্যবহারকারী প্রমাণীকরণ এবং সুরক্ষিত পরিবহনের ভেতরে বহন করা চ্যানেলগুলোকে আলাদা করে। এই ভূমিকাগুলোর কোনোটিই বাণিজ্যিক VPN প্রদানকারী দাবি করে না, এবং ইন্টারনেটের দিকে কোনো ডিফল্ট রুট না থাকার কারণে কোনোটিই কাজ করা বন্ধ করে না।

একটি অতিরিক্ত TCP পরিষেবা অনুমোদিত SSH ফরওয়ার্ডের মধ্য দিয়ে যেতে পারে যখন সার্ভার অনুমতি দেয়: স্থানীয় শ্রোতাকে শক্ত করে বেঁধে রাখুন এবং গন্তব্য স্পষ্ট রাখুন, এবং মনে রাখুন এটি সেই একটি পরিষেবাই এগিয়ে পাঠায়, ইথারনেট সেগমেন্ট পুনরুৎপাদন করে না।

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

তালিকা করুন LAN কী ছাড়বে

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

নামকরণ সচেতনভাবে করুন। অভীষ্ট স্থানীয় DNS পরিষেবা বা নথিভুক্ত ঠিকানা বিন্যাস ব্যবহার করুন, কারণ কনফিগার করা পাবলিক রিজলভার নিজের দিকে কোনো পথ তৈরি করে না। সকেট ঠিকানা বদলানোও অ্যাপ্লিকেশনের পরিচয় যাচাই এড়ানোর ন্যায্যতা নয়। উত্তর যদি হয় যে বেঞ্চ কেবল ঠিকানা ব্যবহার করে, তাও লিখে রাখুন, যাতে পরের প্রকৌশলীকে কখনও কনফিগার না করা অনুসন্ধান ডোমেইনে ঘণ্টা নষ্ট করতে না হয়।

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

পরিচয় যাচাই যেখানে থাকার সেখানেই রাখুন

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

সময় পরিকল্পনায় নিজের আলাদা লাইন পাওয়ার যোগ্য। অনেক প্রোটোকল ঘড়ি যথেষ্ট সরে গেলে অন্যথায় বৈধ প্রমাণপত্র প্রত্যাখ্যান করে, এবং নেটওয়ার্ক সময়ের উৎস ছাড়া একটি Pi মাসের পর মাস নীরবে সরে যেতে পারে, কিছু অভিযোগ করার আগে।

আপলিঙ্ক সত্যিই অনুপস্থিত থাকলে পরীক্ষা করুন

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

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