কেন VPN পরিবর্তনের পর রাউটারের অ্যাডমিন সাড়া দেওয়া বন্ধ করে

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

প্রথমেই যে মিথটি মারা দরকার তা হলো: কাজ করা টানেল ভিতরে ফেরার পথ নয়। এটি নিজের বিশ্বাস-প্রশ্নসহ একটি নতুন নেটওয়ার্ক সংযুক্তি, এবং এটি আপনার পুরোনো ব্যবস্থাপনা পথ নীরবে সরিয়ে দিতে পারে আর এমন একটি নতুন পথ খুলে দিতে পারে যা কেউ পর্যালোচনা করেনি।

টানেল কখনোই ব্যবস্থাপনা পথ ছিল না

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

বিপরীত ভুলটি হলো ইন্টারফেসের নাম বিশ্বাস করা। টানেল পিয়ারের সাথে এনক্রিপ্ট করা, এর পেছনের প্রতিটি সেবার সাথে নয়, এবং ইন্টারফেস লেবেলে VPN শব্দটি কোন উৎসগুলো লগ ইন করতে পারবে সে সম্পর্কে কিছুই বলে না।

প্রথম স্তর: রাউটারের নিজের ঠিকানায় কি কোনো রুট আছে?

ক্লায়েন্টে শুরু করুন এবং কার্নেলকে জিজ্ঞাসা করুন প্যাকেট কোথায় যাবে। Linux-এ ip route get 10.6.0.1 নির্বাচিত রুট, বহির্গামী ইন্টারফেস ও উৎস ঠিকানা ছাপে। যদি এটি আপনার ISP-র দিকে ডিফল্ট রুট দেখায়, প্যাকেট কখনোই টানেলে ঢোকে না, এবং রাউটারের কোনো নিয়মই তা বাঁচাতে পারে না।

টানেল পক্ষের প্রশ্নটির নিজস্ব সংস্করণ আছে। WireGuard AllowedIPs-কে একটি ক্রিপ্টোকি রাউটিং টেবিল হিসেবে দেখে: প্রতিটি প্রান্তে এটি ঘোষণা করে পিয়ার কোন উৎস ঠিকানা ব্যবহার করতে পারে এবং কোন গন্তব্যগুলো সেই পিয়ারে পাঠানো হয়। যদি ক্লায়েন্ট এন্ট্রিতে রাউটারের টানেল ঠিকানা না থাকে, ক্লায়েন্টের সেখানে কোনো রুট নেই। যদি সেই ক্লায়েন্টের জন্য সার্ভার এন্ট্রি ক্লায়েন্টের টানেল ঠিকানা না ঢাকে, সার্ভার কোনো ফায়ারওয়াল নিয়ম দেখার আগেই প্যাকেটটি ফেলে দেয়।

নীতি ডিবাগ করার আগে আপনি যে সঠিক ঠিকানায় পৌঁছাতে চান তা নিশ্চিত করুন। পুরোনো DNS রেকর্ড বা পরিবর্তনের আগের ক্যাশ করা প্রতিবেশী এন্ট্রি আপনাকে এমন ঠিকানায় পাঠায় যা রাউটারের কখনো ছিল না।

দ্বিতীয় স্তর: ইনপুট নীতি, ফরওয়ার্ডিং নীতি নয়

ফায়ারওয়াল প্যাকেট যে ইন্টারফেসে আসে সেখানে নিয়ম মূল্যায়ন করে। pfSense ও OPNsense-এ ইন্টারফেস ট্যাব ও নিয়মের ক্রম ঠিক করে ফায়ারওয়ালের নিজের সেবায় ট্র্যাফিক অনুমোদিত কি না; যে নিয়ম LAN ক্লায়েন্টদের ইন্টারনেটে যেতে দেয় তা টানেল পিয়ারকে ওয়েব GUI খুলতে দেওয়ার নিয়ম নয়। firewall4 সহ OpenWrt-এ প্রতিটি জোন একটি ইনপুট নীতি বহন করে, option input 'ACCEPT' বা 'REJECT', এবং ইনপুট REJECT থাকা জোনের টানেল ইন্টারফেস ব্যবস্থাপনা সংযোগ প্রত্যাখ্যান করবে, তবে ফরওয়ার্ডিং অনুমোদিত থাকলে ট্র্যাফিক এখনো ফরওয়ার্ড করবে।

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

তৃতীয় স্তর: ওই ঠিকানায় কি কিছু শুনছে?

একটি সেবা চলতে পারে এবং তবুও পৌঁছানো না যেতে পারে কারণ এটি একটি ঠিকানায় বাঁধা। OpenWrt-এর uhttpd /etc/config/uhttpd-এ স্পষ্ট লিসেন এন্ট্রি রাখে, যেমন list listen_http '0.0.0.0:80'; যে বিল্ড শুধু LAN ঠিকানায় বাঁধে তা টানেল ঠিকানায় কিছু গ্রহণ করে না, এবং লিসেন-ইন্টারফেস সেটিং দেখানো পণ্যগুলোও একইভাবে আচরণ করে। উপরের লিসেন কমান্ডগুলো এটির সরাসরি উত্তর দেয়।

তারপর প্রত্যাখ্যানকে নীরবতা থেকে আলাদা করুন। nc -vz 10.6.0.1 443 প্রত্যাখ্যাত সংযোগ ফেরত দিলে বোঝা যায় প্যাকেট রাউটারে পৌঁছেছে এবং কিছু তা প্রত্যাখ্যান করেছে, হয় বন্ধ পোর্ট বা স্পষ্ট প্রত্যাখ্যান নিয়ম। টাইমআউট পর্যন্ত ঝুলে থাকা বোঝায় প্যাকেট ফেলা হয়েছে বা কখনো রাউট হয়নি। এই পার্থক্য বলে দেয় পরের কোন স্তর দেখবেন, আর এতে পাঁচ সেকেন্ড লাগে।

VPN ইন্টারফেস একটি সীমানা, পুনরুদ্ধারের পথ নয়

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

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

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

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

নীতি স্পর্শ করার আগে ফেরার পথ প্রস্তুত করুন

প্রথম পরিবর্তনের আগে চারটি জিনিস লিখুন: টানেল মরে গেলে আপনি ডিভাইসে কীভাবে পৌঁছাবেন, যেমন সিরিয়াল কনসোল, প্রোভাইডার কনসোল বা LAN-এর একটি মেশিন; বর্তমান কনফিগারেশন কোথায় রপ্তানি হয়; আপনি কোন একক নিয়ম বা রুট পরিবর্তন করতে যাচ্ছেন; এবং ঠিক সেই আইটেমটি কীভাবে ফিরিয়ে আনবেন। OpenWrt-এ sysupgrade -b /tmp/backup.tar.gz কনফিগারেশন ধরে নেয়, এবং সম্পাদনাগুলো uci commit পর্যন্ত অপেক্ষমাণ থাকে, যা সময়মতো খেয়াল করলে আপনাকে সস্তা আনডু দেয়। pfSense কনফিগারেশন ইতিহাস রাখে, এবং AutoConfigBackup কেবল তখনই সাহায্য করে যদি তা আগেই চালু থাকে। রাউটার fail-closed নিয়মসমূহ চালালে, নিশ্চিত করুন আপনার পরিকল্পিত রক্ষণাবেক্ষণ পথ সেই নিয়মের ব্লক করা ট্র্যাফিকের ভিতরে নয়, এবং মনে রাখুন রিবুট স্থায়ী নিয়মগুলো মুছে ফেলার বদলে আবার প্রয়োগ করে।

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

চলে যাওয়ার আগে দ্রুত যাচাই:

• আপনি কি এমন উৎস থেকে রাউটারে পৌঁছাতে পারেন যা আপনি এইমাত্র সম্পাদনা করা নিয়মের উপর নির্ভর করে না?
• টানেল ইন্টারফেসের ইনপুট নীতি কি কেবল প্রশাসকের উৎসকে অনুমোদন করে?
• ব্যবস্থাপনা সেবা কি টানেলে বিদ্যমান এমন ঠিকানায় বাঁধা?
• আপনি কি একটি প্রত্যাখ্যাত পিয়ার ও একটি নতুন সেশন পরীক্ষা করেছেন?
• WAN ব্যবস্থাপনা পৃষ্ঠতল কি এখনো বন্ধ?