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