একই সার্ভার IP, দুটি পথ: OpenVPN-এর বাহ্যিক প্রবাহ চিহ্নিত করা

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

যে দুটি প্রবাহ আলাদা করতে চান সেগুলো দিয়ে শুরু করুন

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

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

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

খামটি বহনকারী সকেট চিহ্নিত করুন

ক্লায়েন্ট কনফিগারেশন তার এনক্রিপ্টেড বহির্গামী প্যাকেটের জন্য একটি চিহ্ন পায় এবং নিজে রুট স্থাপন করা বন্ধ করে, যাতে প্রতিস্থাপন নীতিই পথ নির্ধারণকারী একমাত্র জিনিস হয়:

mark 42
route-noexec
disable-dco

দশমিক 42 হলো হেক্সাডেসিমাল 0x2a, এবং হেক্স রূপটিই রাউটিং নিয়ম মেলাবে। link-options-এর রেফারেন্স mark-কে Linux-এ এনক্রিপ্টেড বহির্গামী প্যাকেটে প্রযোজ্য বলে বর্ণনা করে, অর্থাৎ ঠিক সেই সকেট যার পথ আপনাকে নিয়ন্ত্রণ করতে হবে। ডেটা চ্যানেলের অফলোড বন্ধ করলে এই উদাহরণটি ব্যবহারকারী-স্পেস পথে থাকে, যেখানে চিহ্নের আচরণ বর্ণিতটিই।

route-noexec OpenVPN-এর স্বয়ংক্রিয় রুট যোগ ও অপসারণ দমন করে। এটি তাদের জায়গায় কিছুই স্থাপন করে না, তাই এই মুহূর্ত থেকে রুটের মালিককে টানেলের প্রয়োজনীয় প্রতিটি রুট রক্ষণাবেক্ষণ করতে হয়। পরিবর্তনের পর কোনো ব্যক্তিগত গন্তব্য হারিয়ে গেলে সেটি অনুপস্থিত প্রতিস্থাপন নীতি, চিহ্নের ত্রুটি নয়।

এটি করার সময় 198.51.100.25-এর জন্য মূল টেবিলে হোস্ট রুট রাখবেন না। এমন রুট ঠিক সেই ছাড়টিই ফিরিয়ে আনে যা ডিজাইন সংকুচিত করতে চায়, এবং নিচের কোনো নীতির কাছে জিজ্ঞাসা করার আগেই এটি HTTPS প্রবাহের জন্য জিতে যাবে।

বাকি সব টানেল টেবিলে পাঠান

টানেল ইন্টারফেস থাকলে এবং তার ঠিকানা ধরে রাখলে নীতিটি এমন দেখায়:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

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

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

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

ফেরার পথও একই চিহ্ন দেখুক

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

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

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

দুটি রুট অনুসন্ধান দিয়ে এটি প্রমাণ করুন

কার্নেল দুটি প্রসঙ্গে কী সিদ্ধান্ত নেয় তা তুলনা করুন, এবং প্রস্থান অবস্থার বদলে dev ও src ফিল্ড পড়ুন:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

প্রথম অনুসন্ধান টানেল উৎসসহ tun1-এ মিলানো উচিত, এবং দ্বিতীয়টি আপলিংকে। এগুলো কৃত্রিম অনুসন্ধান, তাই এগুলো নীতি প্রমাণ করে, চলমান প্রক্রিয়া নয়: চলমান ক্লায়েন্টের প্রকৃত পরিবহন পথ আলাদাভাবে নিশ্চিত করুন, তারপর সার্টিফিকেট যাচাই চালু রেখে সত্যিকারের HTTPS অনুরোধ করুন।

সম্পূর্ণ ঘোষণা করার আগে ডিজাইন কী ঢাকে না তা লিখুন। DNS, IPv6 এবং নিয়মের জীবনচক্রের প্রত্যেকের নিজস্ব সিদ্ধান্ত দরকার, এবং এটি IPv4 রাউটিংয়ের উদাহরণ, পূর্ণ গোপনীয়তা কনফিগারেশন নয়। এর মূল্য নির্বাচকে: খাম আপলিংকের ছাড় পায়, এবং একই ঠিকানার সাধারণ সেবাকে তা উত্তরাধিকারে নিতে হয় না।