VPN ক্লায়েন্ট ট্রাফিক ও ফায়ারওয়াল অবস্থা: বাইরের বনাম ভিতরের প্রবাহ

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

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

ফায়ারওয়াল দুটি আলাদা প্যাকেট দেখে

ডিক্যাপসুলেশনের আগে ফায়ারওয়াল VPN এন্ডপয়েন্টে পাঠানো ট্রাফিক দেখে: শ্রোতার দিকে বাইরের UDP প্রবাহ। ডিক্যাপসুলেশনের পরে ফরোয়ার্ড করা প্যাকেট ক্লায়েন্টের ভিতরের ঠিকানা ও সেবার গন্তব্য বহন করে।

বাইরের প্রবাহের অনুমতি ফরোয়ার্ড করা TCP সংযোগকে অনুমোদন করে না। এগুলো ভিন্ন চেইনে, ভিন্ন ইন্টারফেসের বিপরীতে এবং অনুবাদের পরে ভিন্ন ঠিকানায় মূল্যায়িত হতে পারে।

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

প্রথম সিদ্ধান্ত: টানেলের অনুমতি, না সেবার

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

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

দুটি নিয়ম আলাদাভাবে লিখুন। টানেল নিয়ম ও সেবা নিয়ম ভিন্নভাবে ব্যর্থ হয় এবং ভিন্ন প্রমাণ দিয়ে ডিবাগ করা হয়। একটি ব্যর্থ হলে আপনি জানেন কোন স্তর আগে দেখবেন।

দ্বিতীয় সিদ্ধান্ত: প্রতিটি সীমায় অবস্থা রাখা বা না রাখা

প্রতিষ্ঠিত-প্রবাহ নিয়ম অনুমোদিত বিনিময়ের উত্তরের অনুমতি দিতে পারে, কিন্তু এর আচরণ পণ্যের উপর নির্ভর করে। ক্লাউড নিরাপত্তা গ্রুপ সাধারণত অবস্থা রাখে; সাবনেট ACL প্রায়ই অবস্থা রাখে না এবং দুই দিকেই স্পষ্ট হ্যান্ডলিং দরকার। পথের প্রতিটি সীমা একইভাবে অবস্থা দেখে বলে ধরে নেবেন না। নিয়ম নকশা করার আগে প্রতিটি সীমা তালিকাভুক্ত করুন এবং অবস্থা রাখে কি না চিহ্নিত করুন।

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

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

একই নীতির অধীনে ফেরার পথ যাচাই করুন

ক্লায়েন্ট থেকে সেবায় নতুন অনুরোধ পাঠান, তারপর প্রতিটি সীমায় ফরোয়ার্ড ও ফেরত কাউন্টার দেখুন। উত্তরটি আপনার প্রত্যাশিত পথ ব্যবহার করছে কি না নিশ্চিত করুন, বিশেষত অনুবাদ জড়িত থাকলে।

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