VPN ঠিকানায় আবদ্ধ NFS এক্সপোর্ট: এটি কী প্রমাণ করে না
এক্সপোর্ট নিয়ম দেখে প্যাকেট কোথা থেকে এসেছে; AUTH_SYS একটি স্থানীয় UID দাবি করে আর Kerberos ব্যবহারকারীকে প্রমাণ করে। আপনার ফাইল সেবার কোনটি দরকার তা ঠিক করুন।
একটি হোস্ট একটি ডিরেক্টরি VPN ঠিকানায় এক্সপোর্ট করে, মাউন্ট সফল হয়, আর নকশায় লেখা হয়ে যায় যে এটি প্রমাণিত। আসলে ওই নিয়ম কেবল সীমাবদ্ধ করে প্যাকেটগুলো কোথা থেকে আসছে বলে মনে হয়। ফাইল পরিচালনার নেতৃত্বে থাকা ব্যক্তি সত্যিই সে-ই কি না, তা নির্ভর করে NFS নিরাপত্তা ফ্লেভারের উপর, আর এ ধরনের বেশিরভাগ এক্সপোর্টে কেউ তা ডিফল্ট থেকে বদলায়নি।
একটি অনুরোধে তিনটি পরিচয় আসতে পারে
VPN পিয়ার একটি নিবন্ধিত পরিচয় বহন করে, যেমন ক্লায়েন্ট সার্টিফিকেট বা পিয়ার কী। ভেতরের IP প্যাকেট একটি উৎস ঠিকানা বহন করে। ফাইল পরিচালনা বহন করে তার NFS ব্যবস্থা যে ব্যবহারকারী-প্রমাণপত্র দেয় তা। যে নকশা ঠিকানাকে তিনটিরই প্রতিনিধি ভাবে, সে চুপচাপ সেই অংশটাই ধরে নিয়েছে যা তার যাচাই করা দরকার ছিল।
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ওই তিনটি সারি লিখে ফেলাই পুরো ব্যায়াম। এক্সপোর্ট নিরাপদ কি না—এই বিতর্কের বড় অংশ ভেঙে পড়ে যখন স্পষ্ট হয় কোন নিয়ন্ত্রণ কোন সারিতে থাকে।
ঠিকানার মালিকানা একটি বাস্তবায়ন-বিস্তারিত
একটি গেটওয়ে গৃহীত পিয়ারকে একটি টানেল ঠিকানা দিতে পারে, বা তার জন্য একটি রাউটেড সাবনেট অনুমোদন করতে পারে। এরপর বাস্তবায়নটি এমন প্যাকেট প্রত্যাখ্যান করে কি না যার ভেতরের উৎস অন্য ক্লায়েন্টের, তা ওই বাস্তবায়নের বৈশিষ্ট্য, এবং ধরে নেওয়ার বদলে তা যাচাই করা উচিত।
প্রচলিত Community OpenVPN ব্যবহারকারী-স্পেস সার্ভার কোড, উদাহরণস্বরূপ, TUN ডিভাইসের মাধ্যমে প্যাকেট পৌঁছানোর আগেই অন্য ক্লায়েন্টের সঙ্গে যুক্ত উৎস প্রত্যাখ্যান করতে পারে। এটি বাস্তব মূল্যবান ঠিকানা-মালিকানা যাচাই, এবং এটি এখনও NFS ব্যবহারকারী প্রমাণ নয়, কারণ এটি বলে না কোন অ্যাকাউন্ট কাজটি করছে।
উৎস অনুবাদ এমনকি তাও ক্ষয় করে। একটি NAT গেটওয়ে প্রতিটি ক্লায়েন্টকে একটিমাত্র ঠিকানা হিসেবে দেখাতে পারে, তখন এক্সপোর্ট নিয়ম তার পেছনের মানুষদের আলাদা করতে পারে না। নিয়মের আপাত নিখুঁততা তখন চিত্রে রক্ষিত একটি কল্পকাহিনিতে পরিণত হয়। এক্সপোর্ট গুরুত্বপূর্ণ হলে ঠিকানাবিন্যাস স্পষ্ট রাখুন, অনুবাদককে কে কার প্রতিনিধি তা ঠিক করতে দেবেন না।
এক্সপোর্টে ভরসা করার আগে নিরাপত্তা ফ্লেভার পড়ুন
Red Hat-এর NFS নির্দেশিকা sec=sys, যা AUTH_SYS-এর মাধ্যমে স্থানীয় UNIX UID ও GID ব্যবহার করে, এবং Kerberos মোডগুলিকে আলাদা করে। krb5 ব্যবহারকারী প্রমাণ যোগ করে, krb5i অখণ্ডতা সুরক্ষা যোগ করে, আর krb5p ট্র্যাফিকের গোপনীয়তা সুরক্ষা যোগ করে।
AUTH_SYS প্রমাণপত্রে আহ্বানকারীর UID ও গ্রুপ আইডির মতো ক্ষেত্র থাকে, এবং RFC 5531 স্পষ্টভাবে সতর্ক করে যে এই ফ্লেভার নিজে থেকে কোনো নিরাপত্তা দেয় না এবং বাইরের সুরক্ষার উপর নির্ভর করে। এটি VPN-এর ভেতরে চালালে পরিবহনের সুরক্ষা মেলে, কিন্তু প্যাকেটের ভেতরের দাবিতে কিছুই বদলায় না।
exportfs -v
showmount -e nfs.example.internalক্লায়েন্ট তালিকা পড়ার আগে ওই আউটপুটে ফ্লেভারটি পড়ুন। সীমিত দেখানো একটি এক্সপোর্ট কেবল ঠিকানা দিয়েই সীমিত হতে পারে, অথচ প্রতিটি আহ্বানকারী তখনও যা চায় সেই UID দাবি করে।
মডেল বাছুন, তারপর অনুমতিগুলো রাখুন
আপনি সত্যিই যেসব ক্লায়েন্ট পরিচালনা করেন, তাদের উপযুক্ত ফাইল-সেবা প্রমাণ মডেল বাছুন। Kerberos-এর পেছনে পরিচয় ও সেবা স্থাপন দরকার, তাই একটি মাউন্ট অপশন বদলানো কোনো মাইগ্রেশন নয় এবং Kerberos ডোমেইন, প্রিন্সিপাল ও keytab তৈরি না হওয়া পর্যন্ত তা কেবল ব্যর্থ হবে।
দুই মডেলের যেকোনোটিতে এক্সপোর্ট অনুমতি ও ফাইলসিস্টেম অনুমোদন ধরে রাখুন, যা প্রমাণিত প্রিন্সিপাল কী করতে পারে তা সীমাবদ্ধ করে। প্রমাণ বলে কে জিজ্ঞাসা করছে; অনুমোদন ঠিক করে উত্তরটি হ্যাঁ হওয়া উচিত কি না। এই দুটিকে একটি সেটিংয়ে মিলিয়ে ফেলাই মাইগ্রেশনকে পুরনো কনফিগারেশনের চেয়ে বেশি অধিকার দিতে বাধ্য করে।
ঠিকানা নিয়মটি তার আসল উদ্দেশ্যে ব্যবহার করুন
সেবাটিকে অনুমোদিত পথ ও উৎসে সীমাবদ্ধ রাখা মূল্যবানই থাকে, যার মধ্যে হোস্ট ইনপুট নীতি অন্তর্ভুক্ত যখন VPN এন্ডপয়েন্ট ও NFS সার্ভার একই মেশিন ভাগ করে। ট্র্যাফিক ফরোয়ার্ড করা নিয়মগুলো সেই অনুরোধ নিয়ন্ত্রণ করে না যেগুলো একই হোস্টে স্থানীয়ভাবে চলা সেবার দিকে করা হয়। এই ফাঁকটি বিস্ময়কর সংখ্যক এক্সপোর্ট ব্যাখ্যা করে যেগুলো ব্যক্তিগত হওয়ার কথা ছিল। টানেল নিয়মগুলো এটি ঢাকে ধরে না নিয়ে স্থানীয় ইনপুট নীতি স্পষ্টভাবে যাচাই করুন।
যাচাই করুন যে অন্য একটি ইন্টারফেস বা উৎস-অনুবাদ করা গেটওয়ে অপ্রত্যাশিতভাবে নিয়মটি পূরণ করতে পারে না, এবং এটিকে ঠিকানা জাল করা কার্যকর মাউন্ট নিশ্চিত করে—এমন দাবি নয়, বরং উৎস প্রতিষ্ঠার কারণ হিসেবে ধরুন।
একটি নয়, তিনটি গ্রহণযোগ্যতার ক্ষেত্রে চালান। অনুমোদিত ক্লায়েন্ট দিয়ে অনুমোদিত ব্যবহারকারী হিসেবে শুরু করুন, তারপর কখনও অনুমোদিত হয়নি এমন পিয়ার থেকে পুনরাবৃত্তি করুন, তারপর এমন কিছু করার চেষ্টা করুন যা অনুমোদিত ব্যবহারকারীর এখনও করার অধিকার নেই। পরে জিজ্ঞাসা করুন একটি অনুমোদিত ক্লায়েন্ট আপস হলে কী বদলায়, কারণ পরিবহন প্রমাণ ওই মেশিনের প্রতিটি প্রসেসকে বিশ্বাসযোগ্য করে না। চুরি হওয়া সার্টিফিকেট আর কৌতূহলী স্থানীয় অ্যাকাউন্ট ভিন্ন নিয়ন্ত্রণসহ ভিন্ন সমস্যা।