আপনার ওয়েব সার্ভারের VPN ক্লায়েন্ট কি তার উত্তর ভাঙে?

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

উৎসভিত্তিক রুট নিয়ম প্রায়ই উপসর্গটি সারায়। এটি সাধারণত যে সাইটের কারণে তৈরি হয়েছে তার চেয়ে বেশি ট্রাফিককেও ছাড় দেয়, আর নিয়মটি সংরক্ষণ করার আগে বোঝার মতো অংশটি ঠিক এটাই।

উপসর্গ: এটি স্থানীয়ভাবে উত্তর দেয়, বাইরে থেকে নয়

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

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

কাজ করার সময় একটি স্বাধীন প্রশাসনিক পথ খোলা রাখুন। যে নিয়ম আপনার নিজের SSH সেশন ভাঙে, সেটি দশ মিনিটের সংশোধনকে একটি শারীরিক পরিদর্শনে পরিণত করে।

উৎস সিলেক্টর আসলে কী মেলায়

Linux নীতিনির্ভর রাউটিংয়ে from 192.168.50.2 এর মতো একটি নিয়ম সেই প্যাকেটগুলো মেলায় যাদের উৎস ওই ঠিকানা। এটি এই তথ্য এনকোড করে না যে প্যাকেটটি হোম রাউটারের মাধ্যমে প্রবেশ করা একটি কথোপকথন চালিয়ে যাচ্ছে, এবং এটি জানে না কোন প্রক্রিয়া এটি তৈরি করেছে। ওই উদাহরণের ঠিকানাটি দৃষ্টান্তমূলক; আপনার হোস্ট আসলে যে ঠিকানা ব্যবহার করে তা বসান। লাইনটিকে ঠিকানা সম্পর্কে একটি বিবৃতি হিসেবে দেখুন, আর কিছু নয়।

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

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

ফেরত পথ এবং আপনি যে ট্রাফিক চাননি তা পরীক্ষা করুন

নিয়ম ও টেবিলগুলো পড়ুন, তারপর কার্নেলকে জিজ্ঞাসা করুন একটি নির্দিষ্ট উৎস ও গন্তব্য জোড়া কোন রুট নেবে। হোস্টের নিজের থেকে পরীক্ষা করা বাইরে থেকে পরীক্ষা করার সমান নয়, তাই দুটোই করুন।

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

ব্রাউজারে একটি পাবলিক ঠিকানা পরীক্ষা কেবল ওই ব্রাউজার যে অনুরোধ করেছে তা জানায়। এটি ওয়েব সার্ভারের উত্তর সম্পর্কে, অন্য একটি স্থানীয় অ্যাপ্লিকেশনের উৎস নির্বাচন সম্পর্কে, বা পরবর্তী VPN পুনঃসংযোগের পরে ব্যবস্থাপনা ট্রাফিকের কী হয় তা নিয়ে কিছুই বলে না।

ব্যতিক্রমটি কত সংকীর্ণ হতে পারে তা ঠিক করুন

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

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

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