একজন VPN ব্যবহারকারীর একটি প্রিন্টার দরকার, পুরো LAN নয়

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

লক্ষণ: সংকীর্ণ নিয়ম কিছুই বদলায়নি

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

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

দুটি লক্ষণই নতুন নিয়মের ক্ষেত্রগুলোর দিকে নয়, ক্রমের দিকে ইঙ্গিত করে। একটি এমন নিয়ম যা কখনো মেলেনি, অন্যটি এমন নিয়ম যা খুব আগে মিলেছে।

ট্রাফিক আসলে কোন নিয়মসমষ্টিতে পৌঁছায়

pfSense প্রতি ইন্টারফেসে নিয়ম মূল্যায়ন করে, আর OpenVPN-এর নিজস্ব ট্যাব আছে যার নিয়ম প্রতিটি সার্ভার ও ক্লায়েন্ট ইনস্ট্যান্সে প্রযোজ্য। সেই নিয়মগুলো নির্দিষ্ট OpenVPN ইন্টারফেসে বরাদ্দ নিয়মের আগে প্রক্রিয়া করা হয়। তাই OpenVPN ট্যাবে রেখে দেওয়া প্রশস্ত পাস ইন্টারফেস ট্যাব যা-ই বলুক, এই ব্যবহারকারীর ক্ষেত্রেও প্রযোজ্য। ওই ক্রম পরিবর্তন রেকর্ডে কপি করুন, যাতে পর্যালোচনা GUI না খুলেই তা যাচাই করতে পারে।

এই কারণেই নতুন সংকীর্ণ পাস অ্যাক্সেস কেড়ে নিতে পারে না। ফায়ারওয়াল নিয়ম অনুমতি যোগ করে, আগের মিল থেকে তা কেড়ে নেয় না।

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

প্রিন্ট কাজ থেকে পাস নিয়ম লিখুন

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

উইজার্ড খুশি করতে ডিসকভারি বা প্রশাসনিক পোর্ট যোগ করার প্রবণতা প্রতিরোধ করুন। পুরো প্রিন্টারকে অনুমোদন করা নিয়ম প্রিন্ট সারিকে অনুমোদন করা নিয়ম থেকে আলাদা নীতি।

প্রিন্টারের নিজস্ব প্রমাণীকরণ যথাস্থানে রাখুন। নেটওয়ার্ক অনুমতি তার বিকল্প নয়। সারি-স্তরের অ্যাকাউন্টই কে কী প্রিন্ট করতে পারবে তার সঠিক নিয়ন্ত্রণ।

ছয়টি মান পুরো অভিপ্রায় বহন করে: ক্রিয়া হিসেবে পাস, পরিবার হিসেবে IPv4, প্রোটোকল হিসেবে TCP, উৎস হিসেবে পুল উপনাম, গন্তব্য হিসেবে প্রিন্টার উপনাম এবং পোর্ট হিসেবে 631। এই ছয়টির বাইরে যা-ই হোক তা চাওয়া নীতির চেয়ে আলাদা নীতি।

LAN অনুমতি ছাড়াই ক্লায়েন্টকে পথ দিন

ক্লায়েন্টের প্রিন্টার ঠিকানায় একটি রুট দরকার, আর অফিস প্রান্তের VPN পুলে ফেরার পথ দরকার। একটি একক /32 পাঠানো ক্লায়েন্ট কনফিগারেশন সংকীর্ণ রাখে, যা সমস্যা সমাধানে সাহায্য করে। এটি অনুমোদনের সীমা নয়, কারণ ক্লায়েন্ট নিজেই রুট যোগ করতে পারে।

সারিটি নামে ঠিকানা পেলে রিজলভার নির্ভরতা আলাদাভাবে নির্ধারণ করুন। একটি নাম রিজলভ হতে গোটা LAN অনুমোদন করা কাজটির প্রয়োজনের চেয়ে অনেক বড় পরিবর্তন।

পুলে ফেরত রাউটিং আর উৎস অনুবাদের মধ্যে সচেতনভাবে বাছুন। দুটোই কাজ করে, আর প্রতিটি লগ থেকে আলাদা কিছু লুকায়।

কাজের পাশাপাশি প্রত্যাখ্যানও পরীক্ষা করুন

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

স্থাপনাকে শুধু-প্রিন্টার বলার আগে IPv6 এবং অন্য যেকোনো সক্রিয় VPN পথ পর্যালোচনা করুন। একটি ঠিকানা পরিবারে সংকীর্ণ নিয়মসমষ্টি অন্যটিতে পুরোপুরি খোলা থাকতে পারে।