VPN দিয়ে সংযুক্ত দুই অফিসের মধ্যে অ্যাক্সেস কীভাবে সীমিত করবেন

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

এই ক্রমে কাজ করুন, এবং নিচের নীতি ধাপগুলো পাস না করা পর্যন্ত টানেল রুট প্রশস্ত করবেন না।

গেটওয়ে স্পর্শ করার আগে ম্যাট্রিক্স লিখুন

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

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

প্যাকেট যেখানে ডিক্রিপ্ট হয় সেখানেই প্রয়োগ করুন

যে নিয়মগুলো IKE ও ESP-কে অনুমতি দেয়, তারা কেবল বাইরের টানেল তৈরি করে। ভেতরের ট্র্যাফিক টানেল ইন্টারফেসে খোলাখুলিই পৌঁছায়, আর ঠিক সেখানেই অনুমোদন তালিকার জায়গা: ডিক্রিপ্ট করা ডিভাইসে একটি ফরওয়ার্ড চেইন, ডিফল্ট ড্রপ, ম্যাট্রিক্সের প্রতি সারিতে একটি নিয়ম। Linux গেটওয়েতে এর অর্থ হলো ফরওয়ার্ডিং চালু থাকা এবং ফিল্টার নিয়ম টানেল ডিভাইসে থাকা, ভৌত আপলিঙ্কে নয়, যেমনটি ব্যাখ্যা করে strongSwan ফরওয়ার্ডিং নির্দেশিকা।

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

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT ও ওভারল্যাপিং সাবনেট নিয়ম বদলে দেয়

যখন শাখা গেটওয়ে টানেলের আগে প্রতিটি হোস্টকে একটি একক ঠিকানায় রূপান্তর করে, তখন উৎসভিত্তিক প্রতিটি সারি সেই একটি ঠিকানায় মিলিয়ে যায়। হয় টানেল ট্র্যাফিকের রূপান্তর বন্ধ করুন, নয়তো মেনে নিন যে নিয়মগুলোকে অন্য কিছুর উপর নির্ভর করতে হবে, যেমন রূপান্তরের আগে রেকর্ড করা মূল উৎস ঠিকানা। দূর প্রান্তেরও একই সমস্যা, কারণ গন্তব্য হোস্ট মূল ঠিকানার বদলে NAT-পরবর্তী ঠিকানাটি দেখে।

ওভারল্যাপিং পরিসর হলো আরেকটি ফাঁদ। যে দুই অফিস একই 192.168.1.0/24 ব্যবহার করে, তাদের একটি দিক ম্যাপিং ছাড়া এক নীতি সারণিতে বর্ণনা করা যায় না, আর ম্যাপিং সংঘর্ষহীন অ্যাড্রেসিংয়ের বিকল্প নয়। পরে খুলে ফেলতে হবে এমন নিয়ম লেখার আগে পরিকল্পনা ঠিক করুন।

প্রত্যাখ্যান প্রমাণ করুন, কেবল সফলতা নয়

কেবল অনুমোদিত অ্যাপ্লিকেশন পরীক্ষা করা খুব কম প্রমাণ করে, কারণ উপরের দিকে কোথাও একটি অনুমোদনকারী নিয়ম একই ফল দেয়।

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

তালিকাটি জীবন্ত রাখুন

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

টানেলের পিছনেও হোস্ট-স্তরের নিষেধাজ্ঞা গুরুত্বপূর্ণ: সার্ভারের নিজস্ব ফায়ারওয়াল শাখার পরিসর কেবল যে সেবা এটি প্রকাশ করে তার জন্যই গ্রহণ করা উচিত। যে দুটি স্তর একমত হয়, তা সম্পূর্ণ বিশ্বাস করা এক স্তরের চেয়ে নিরীক্ষা করা সহজ।