Nextcloud শুধু VPN দিয়ে: আগে প্রতিটি প্রবেশপথের তালিকা করুন

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

চেকলিস্ট ক্রমানুসারে সম্পূর্ণ করুন। প্রথম আইটেম নির্ধারণ করে এই স্থাপনার জন্য ব্যক্তিগত বলতে কী বোঝায়; পরের আইটেমগুলি যাচাই করে স্থাপনা সত্যিই সেই সংজ্ঞার সঙ্গে মেলে কি না।

সীমা বদলানোর আগে ব্যক্তিগত সংজ্ঞায়িত করুন

প্রয়োজনটি এক বাক্যে লিখুন: প্রতিটি ব্যবহারকারীকে অ্যাপ্লিকেশন পৌঁছানোর আগে VPN-এ যোগ দিতে হবে, অথবা অ্যাপ্লিকেশন প্রকাশ্য থাকতে পারে এবং এর উৎস ব্যক্তিগত থাকে। এগুলি ভিন্ন নকশা, এবং ব্যক্তিগত টানেলে পাঠানো প্রকাশ্য রিভার্স প্রক্সি কেবল দ্বিতীয়টি পূরণ করে।

ব্যক্তিগত backend ঠিকানা অ্যাপ্লিকেশনকে ব্যক্তিগত করে না। যদি প্রকাশ্য ম্যাপিং, দ্বিতীয় হোস্টনাম বা IPv6 শ্রোতা এখনও একই Nextcloud ইনস্ট্যান্সে পৌঁছায়, তবে backend যেখানেই থাকুক প্রবেশপথ বিদ্যমান। সেবাকে ব্যক্তিগত ঘোষণা করার আগে প্রতিটি নাম বাইরে থেকে পরীক্ষা করুন। অনুপস্থিত DNS রেকর্ড বন্ধ পোর্টের সমান নয়।

লক্ষ্যভুক্ত দর্শকদের নিয়েও একমত হোন: কর্মচারী, একটি পরিবার, অংশীদার সংস্থা বা অ্যাকাউন্টের উপসেট। উত্তর নির্ধারণ করে প্রকাশ্য শেয়ার লিংক বৈশিষ্ট্য না দ্বন্দ্ব। সেই দর্শকদের অ্যাক্সেস পরিকল্পনায় লিখুন। এটি পরবর্তী প্রতিটি ব্যতিক্রমের পরীক্ষা।

প্রতিটি প্রবেশপথ এবং প্রতিটি নামের তালিকা করুন

প্রকাশ্য ঠিকানা ম্যাপিং, রিভার্স প্রক্সি, বিকল্প হোস্টনাম, IPv6 শ্রোতা এবং সেবায় পৌঁছানো যেকোনো টানেল বা mesh ঠিকানা তালিকাভুক্ত করুন। যে নামগুলি সেই ঠিকানায় সমাধান হয় সেগুলিও অন্তর্ভুক্ত করুন, কারণ ভুলে যাওয়া DNS রেকর্ড বন্ধুত্বপূর্ণ লেবেলযুক্ত প্রবেশপথ।

প্রক্সি কনফিগারেশন ফরোয়ার্ড করা হেডার এবং বিকল্প সার্ভার ব্লকের জন্য পরীক্ষা করুন। অন্য অ্যাপ্লিকেশনের জন্য যোগ করা প্রক্সি একই upstream পথ বা অবশিষ্ট ভার্চুয়াল হোস্টের মাধ্যমে প্রকাশ করতে পারে। পরিকল্পিত চিত্রের বদলে প্রকৃত কনফিগারেশন পড়ুন। অ্যাপ্লিকেশন সরানোর পরে দুটি সবচেয়ে বেশি ভিন্ন হয়।

তারপর যে প্রবেশপথ আপনি বেছে নেননি সেগুলি ব্লক করুন। প্রকাশ্য ফ্রন্টসহ ব্যক্তিগত backend কেবল VPN নকশা নয়, এবং কেবল IPv4 আচ্ছাদনকারী ফায়ারওয়াল নিয়ম IPv6 শ্রোতাকে খোলা রাখে। একই পরিবর্তনে দুই পরিবার ও দুই নাম বন্ধ করুন।

প্রতিটি ক্লায়েন্টকে একটি সেবা নাম দিন

ব্যক্তিগত DNS সেবার দিকে নির্দেশ করুন, সেই নাম VPN দিয়ে রুট করুন এবং এর জন্য সার্টিফিকেট জারি করুন। নামটি ব্যক্তিগত পথে সমাধান হতে হবে এবং সতর্কতা ছাড়াই যাচাই হতে হবে। সরাসরি IP-তে পৌঁছানো ক্লায়েন্টেরও নাম কাজ করা দরকার।

অসম্পর্কিত IP ঠিকানা দিয়ে সংযোগ করা ক্লায়েন্টদের নকশা কাজ করার জন্য সার্টিফিকেট ত্রুটি উপেক্ষা করতে হওয়া উচিত নয়। স্থিতিশীল নাম ঠিকানা বদলালে সিঙ্ক ক্লায়েন্টদের নকল সার্ভার এন্ট্রি তৈরি করাও রোধ করে। ব্যক্তিগত সেবা ও ব্যক্তিগত IP-এর মধ্যে পার্থক্য এটাই।

সার্টিফিকেট যাচাই সক্রিয় রাখুন। ব্যক্তিগত নেটওয়ার্ক এক্সপোজার কমায় কিন্তু যাচাই না করা TLS সংযোগ গ্রহণযোগ্য করে না, এবং সতর্কতা উপেক্ষা করতে অভ্যস্ত ক্লায়েন্ট অন্য নেটওয়ার্কেও সেগুলি উপেক্ষা করবে।

নেটওয়ার্ক অ্যাক্সেস সীমিত করুন, পুরো LAN নয়

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

VPN প্রবেশ Nextcloud অ্যাকাউন্ট, অনুমতি বা অতিরিক্ত প্রমাণীকরণের বিকল্প নয়। কোন ব্যবহারকারী কোন ফাইল পড়তে পারবে তা অ্যাপ্লিকেশনই নির্ধারণ করে, এবং নেটওয়ার্ক স্তর একমাত্র নিয়ন্ত্রণ হওয়া উচিত নয়।

অনুমোদিত উৎস পরিসর এবং সেবা পোর্ট নথিভুক্ত করুন। লক্ষ্যের মালিকের পর্যবেক্ষিত উৎস দরকার, এবং অনুরোধ অ্যাপ্লিকেশনে পৌঁছানোর আগে NAT বা প্রক্সি তা পুনরায় লিখতে পারে।

ব্রাউজারের বাইরের প্রতিটি কার্যপ্রবাহ পর্যালোচনা করুন

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

WebDAV সরঞ্জাম এবং ক্যালেন্ডার বা পরিচিতি ক্লায়েন্ট নিজস্ব কনফিগারেশনসহ আলাদা ইন্টিগ্রেশন। প্রকাশ্য URL ক্যাশ করা ক্লায়েন্ট সীমা পরিবর্তনের পরেও সেই URL চেষ্টা করে, এবং ব্যর্থতা অ্যাপ্লিকেশন সমস্যার মতো দেখায়।

শেয়ার করা লিংক স্পষ্ট সিদ্ধান্তের যোগ্য। লিংক তার প্রাপককে VPN অ্যাক্সেস দেয় না, তাই সত্যিই কেবল VPN নকশায় বাইরের প্রাপক লিংক বৈধ হলেও তা ব্যবহার করতে পারে না। বাইরে শেয়ার করা প্রয়োজন হলে তা নিজস্ব অ্যাক্সেস পথসহ ইচ্ছাকৃত ব্যতিক্রম, পরে আবিষ্কারযোগ্য অবহেলা নয়।

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

অনুমোদিত এবং প্রত্যাখ্যাত উভয় ক্ষেত্র গ্রহণ করুন

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

অননুমোদিত পথ থেকে নিশ্চিত করুন যে তালিকার প্রতিটি প্রবেশপথ দিয়ে অ্যাপ্লিকেশন পৌঁছানো যায় না। বিকল্প হোস্টনাম এবং IPv6 ঠিকানা পরীক্ষা করুন, কেবল প্রাথমিক URL নয়।

সবশেষে, নেটওয়ার্ক নীতির সঙ্গে সহজে গুলিয়ে ফেলা অ্যাপ্লিকেশন সেটিংস পর্যালোচনা করুন। trusted_domains ইনস্ট্যান্স যে নামগুলি গ্রহণ করে তা তালিকাভুক্ত করে; এটি ক্লায়েন্ট IP-র অনুমতি তালিকা নয়। যদি রিভার্স প্রক্সি ঠিকানার তথ্য সরবরাহ করে, trusted_proxies প্রকৃত প্রক্সির নাম দিতে হবে, এবং ফরোয়ার্ড করা হেডার কেবল তার থেকেই গ্রহণ করা উচিত।

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