VPN ঠিকানা হোয়াইটলিস্ট করেছেন, তবুও ব্লকড? এর পথ অনুসরণ করুন

VPN অ্যাপ যে ঠিকানা দেখায় তা হোয়াইটলিস্টে যোগ করা ব্লক করা পোর্ট খুব কমই ঠিক করে, আর প্যাকেটই তার কারণ ব্যাখ্যা করে। ফায়ারওয়াল আপনার নিয়ম উপেক্ষা করছে না; এটি এমন একটি উৎস ঠিকানা যাচাই করছে যা ক্লায়েন্ট স্ক্রিনে কিছুই দেখায় না। গন্তব্য সেই মান জানানোর আগ পর্যন্ত প্রতিটি নিয়ম সম্পাদনা একটি অনুমান।

সেবাটিতে পৌঁছানো অনুরোধ থেকে শুরু করুন। টানেল ঠিকানা, প্রস্থান ঠিকানা এবং মাঝের যেকোনো রূপান্তর তখন পর্যন্ত অনুমানই থাকে, যতক্ষণ না গন্তব্য তাদের একটিকে নিশ্চিত করে।

অ্যাপে দেখা ঠিকানাই পৌঁছানো ঠিকানা নয়

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

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

একটি অনুরোধকে তার ফিল্টারিং সীমা পর্যন্ত অনুসরণ করুন

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

অনুমোদিত Linux হোস্টে, পরিবর্তনের আগে লাইভ নিয়মগুলো ক্রমানুসারে পড়ুন। ফরওয়ার্ড করা ও কন্টেইনার সেবাগুলো প্রায়ই তাদের নিজস্ব চেইনে লাফ দেয়, তাই চূড়ান্ত রায়ের পাশাপাশি লাফের লক্ষ্যটিও পরীক্ষা করুন।

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

টিকিটে মিলে যাওয়া নিয়ম নম্বরটি উল্লেখ করুন। এটি ছাড়া পরবর্তী পাঠক বুঝতে পারবেন না কোন সম্পাদনা ফলাফল বদলেছে। টাইমস্ট্যাম্প ছাড়া নিয়ম নম্বর এখনও অস্পষ্ট।

একটি সীমিত ক্যাপচার দিয়ে পথ যাচাই করুন

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

tcpdump -ni any 'tcp dst port 9443' -c 20

তিনটি মান পাশাপাশি তুলনা করুন: ক্যাপচারে উৎস, মিলে যাওয়া নিয়ম যে উৎসের নাম দেয়, এবং অ্যাপ্লিকেশন যে প্রত্যাখ্যান লগ করেছে। এগুলো সবই আলাদা হতে পারে, আর কেবল প্রথমটিই IP নিয়মে নির্ধারিত বাদ পড়া ব্যাখ্যা করে। ফরওয়ার্ড করা HTTP হেডার প্রক্সি স্তরের, তাই সেই হেডার উদ্ধৃত করা লগ ফায়ারওয়াল যে উৎস যাচাই করেছে তা বর্ণনা করে না।

কেবল নিয়ম নয়, চেইনের ক্রম পড়ুন

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

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

যে নিয়মের মালিক নিয়ন্ত্রণ করেন সেটিই বদলান

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

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