পরপর দুটি VPN হপ: আপনার ট্রাফিক আসলে কে দেখে?
সিরিয়াল হপ প্রথম গেটওয়েতে ডিক্রিপ্ট ও পুনরায় এনক্রিপ্ট করে; নেস্টেড হপ শুধু বাইরের স্তর সরায়। দুটি ডিজাইনই ঘুরে দেখুন এবং কোন অপারেটর কী পড়ে তা জানুন।
প্রতিটি ক্লায়েন্ট প্রোফাইল একটি সার্ভারের নাম দেয়, তাই ব্যবহারকারীর জায়গা থেকে একটি টানেল এবং সুরক্ষা শেষ হওয়ার একটি জায়গা থাকে। সেই প্রথম গেটওয়ের পরে কী ঘটে তা এমন একটি ডিজাইন সিদ্ধান্ত যা ক্লায়েন্ট কখনও দেখে না, এবং দুটি প্রচলিত ডিজাইন পরীক্ষায় খুব ভিন্নভাবে আচরণ করে। সিরিয়াল চেইনে প্রথম গেটওয়ে ডিক্রিপ্ট করে আবার এনক্রিপ্ট করে। নেস্টেড চেইনে এটি একটি বাইরের স্তর সরিয়ে এমন একটি ভেতরের টানেল পাঠায় যা এটি খুলতে পারে না। হপ সংখ্যা দুটিতেই একই, তাই পার্থক্যটি গুনতে নয়, আঁকতে হয়।
ক্লায়েন্ট থেকে শুরু করুন এবং দুটি প্রান্তের নাম দিন
ব্যবহারকারী যেখানে শুরু করে সেখান থেকেই শুরু করুন, অর্থাৎ সংযোগ প্রোফাইলে। এতে একটি দূরবর্তী ঠিকানা, একটি প্রমাণীকরণ পদ্ধতি এবং ডিজাইন সমর্থন করলে একটি রুট তালিকা থাকে। ক্লায়েন্ট থেকে গেটওয়ে A পর্যন্ত সেই বাইরের টানেলের নাম দিন এবং উদাহরণ ঠিকানা দিন: ক্লায়েন্টের টানেল ঠিকানা 10.77.0.2, A-এর ঠিকানা 10.77.0.1, এবং A-এর পাবলিক এন্ডপয়েন্ট 198.51.100.10, যা TEST-NET-2 ডকুমেন্টেশন রেঞ্জ থেকে নেওয়া যাতে উদাহরণের কিছুই কোনো বাস্তব হোস্টের সঙ্গে সংঘর্ষ না করে।
সেই প্রোফাইলে গেটওয়ে B-এর কোনো উল্লেখ নেই, এবং এটি ত্রুটি নয়। দ্বিতীয় হপটি A-এর, আর ক্লায়েন্টের একমাত্র দায়িত্ব ট্রাফিক A-তে পৌঁছে দেওয়া এবং যা ফিরে আসে তা গ্রহণ করা। A টানেলটি সমাপ্ত করে, পাঠিয়ে দেয় নাকি নতুন একটি খোলে — এই প্রশ্নের উত্তর দেয় এই আলোচনার বাকি অংশ, এবং এটিই নির্ধারণ করে A কী পড়তে পারে।
সিরিয়াল: A ডিক্রিপ্ট করে, তারপর আবার এনক্রিপ্ট করে
সিরিয়াল ডিজাইনে A ট্রাফিক দুইবার সমাপ্ত করে। এটি ক্লায়েন্ট থেকে সুরক্ষা সরায়, অ্যাপ্লিকেশনের IP প্যাকেট পায়, এবং তারপর সেই প্যাকেটটি A-এর তৈরি একটি দ্বিতীয় টানেল দিয়ে B-এর দিকে পাঠায়। এই দুই কাজের মধ্যে প্যাকেটটি A-এর ফরওয়ার্ডিং পথে একটি ব্যক্তিগত গন্তব্যে ঠিকানা করা সাধারণ IP প্যাকেট হিসেবে থাকে।
এতে দুটি পরিণতি হয় যা স্পষ্ট করে বলা দরকার। A ভেতরের প্যাকেটে নীতি প্রয়োগ করতে পারে — রুট, ফিল্টার নিয়ম এবং উৎস ও গন্তব্যের লগিং — এবং A-কে দুই সেট শংসাপত্র রাখতে হয়: একটি ক্লায়েন্টের জন্য সার্ভার হিসেবে, আরেকটি B-এর ক্লায়েন্ট হিসেবে। সুরক্ষা প্রতি মুহূর্তে আছে, তবু সুরক্ষিত বস্তুটি A-তে পরিচয় বদলায়।
এর মানে এই নয় যে A অ্যাপ্লিকেশনের প্লেইনটেক্সট পড়ে। যখন ক্লায়েন্ট ও সার্ভিস TLS চালায় এবং একে অপরের সার্টিফিকেট যাচাই করে, A একটি পাঠযোগ্য অনুরোধের বদলে TLS রেকর্ড স্ট্রিম দেখে। সেই সুরক্ষা কোথায় শেষ হয় তা নিশ্চিত করতে টানেলের চিত্র নয়, সার্ভিসের সার্টিফিকেট চেইন দেখতে হয়।
নেস্টেড: A শুধু বাইরের স্তর সরায়
নেস্টেড ডিজাইনে ক্লায়েন্ট প্রথমে B-এর সঙ্গে একটি ভেতরের টানেল গড়ে এবং তারপর সেই টানেলটি বাইরের টানেলের ভেতরে করে A-তে নিয়ে যায়। A বাইরের হেডার খুলে ফেলে, একটি ভেতরের টানেল পায় এবং তার চাবি না রেখেই তা পাঠিয়ে দেয়, তাই ভেতরের সুরক্ষা এখনও B-তেই শেষ হয়।
তখন ক্লায়েন্টের আপলিংক দুই স্তর বহন করে, আর A ও B-এর মধ্যের পথ বহন করে এক স্তর। A ভেতরের টানেলের বাইরের ঠিকানাগুলো দেখে, যা ট্রাফিক আছে এবং মোটামুটি কোথায় যাচ্ছে জানার জন্য যথেষ্ট, আর পেলোড পড়ার জন্য নয়। সিরিয়াল ক্ষেত্রের সঙ্গে পুরো পার্থক্য এটাই, এবং কোনো হপ কাউন্টার তা দেখায় না। A এখনও যা করতে পারে তা হলো যা পড়তে পারে না তা ফরওয়ার্ড করতে অস্বীকার করা, এবং এটি সেই গেটওয়ের অপারেটরের জন্য সর্বদা খোলা থাকে।
নেস্টিং এই গুণের দাম নেয়। প্রতিটি স্তর হেডার ওভারহেড যোগ করে, তাই MTU ও MSS পরিকল্পনা সাজানোর বদলে বাধ্যতামূলক হয়ে যায়, এবং এক স্তরে যে পথ কাজ করে তা দুই স্তরে বড় প্যাকেট নিঃশব্দে ফেলে দিতে পারে। প্রতিটি স্তরের নিজস্ব পুনঃসংযোগ ও কিপঅ্যালাইভ আচরণ দরকার, আর এক স্তরের ব্যর্থতা অন্য স্তর দিয়ে আংশিক বিভ্রাটের মতো দেখায়।
শুধু টানেল নয়, পর্যবেক্ষকদের আঁকুন
টানেলগুলো ছবির সহজ অংশ। পর্যবেক্ষকরাই ডিজাইনের বিষয়, তাই প্রতিটি দৃষ্টিকোণে একটি সারি লিখুন এবং প্রত্যেকে আসলে কী পড়তে পারে তা ভরুন।
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
দুটি সারি বারবার মিশে যায়: A-এর অপারেটর এবং ক্লায়েন্টের টানেলের সরবরাহকারী। তারা একই সত্তা হতে পারে, আর আলাদা গেটওয়ে নাম তাদের স্বাধীন করে না। স্বাধীন মালিকানার জন্য আলাদা প্রশাসনিক নিয়ন্ত্রণ, আলাদা শংসাপত্র এবং আলাদা লগিং দরকার।
মেটাডেটা দুটি ডিজাইনই টিকে থাকে। সময়, প্যাকেটের আকার ও সংযোগ সংখ্যা প্রতিটি হপে পর্যবেক্ষণযোগ্য থাকে, তাই দুই হপ সংকেত সরানোর বদলে পারস্পরিক সম্পর্কের খরচ বাড়ায়। অদৃশ্যতার প্রতিশ্রুতি দেওয়া ডিজাইন কেউ তার উপর নির্ভর করার আগে ওই তালিকার সঙ্গে মিলিয়ে দেখা উচিত।
বেছে নেওয়ার আগে ব্যর্থতার পথগুলো ঘুরে দেখুন
ব্যবহারকারী যে ক্রমে পাবে সেই ক্রমে ক্লায়েন্ট থেকে ইচ্ছাকৃতভাবে জিনিস ভাঙুন। ইন্টারফেস ও তার MTU দিয়ে শুরু করুন, কারণ নেস্টিং প্রমাণীকরণে ব্যর্থ হওয়ার অনেক আগেই প্যাকেটের আকারে ব্যর্থ হয়।
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1তারপর সুরক্ষার প্রান্তগুলো ধরে নয়, নিশ্চিত করুন। যে টানেলই চালু থাকুক, তার ভেতর থেকে সার্ভিসের সার্টিফিকেট চান, এবং ক্লায়েন্ট যে চেইন দেখে তার সঙ্গে সার্ভিস আসলে যে চেইন উপস্থাপন করে তা মেলান। যে গেটওয়ে পুনরায় স্বাক্ষর করে বা হস্তক্ষেপ করে তা সেই সার্টিফিকেট বদলে দেয়, আর পরীক্ষাটি এক কমান্ডেই দৃশ্যমান হয়।
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullপুনঃসংযোগ ম্যাট্রিক্স দিয়ে শেষ করুন: ক্লায়েন্টের টানেল পড়ে যায়, B-এর টানেল পড়ে যায়, A ও B-এর মধ্যের পথ বদলায়। কী ফিরে আসে আর কী আসে না, এবং কোনো ভেতরের সংযোগ কখনও তার অভীষ্ট বাহকের বাইরের রুটে গিয়ে পড়ে কি না তা লিখুন। প্রতিটি পরীক্ষা যে ঠিকানা ব্যবহার করেছে তা লিখে রাখুন, কারণ ভিন্ন অ্যাক্সেস নেটওয়ার্কে পুনরাবৃত্তি ভিন্ন প্রশ্নের উত্তর দেয়। প্রতিটি পুনঃসংযোগের পর MTU প্রোবও আবার চালান, কারণ বদলে যাওয়া পথ একটি কনফিগারেশন লাইনও না নড়েই ব্যবহারযোগ্য আকার কমাতে পারে।
সিরিয়াল বেছে নিন যখন A-কে ভেতরের প্যাকেটে নীতি প্রয়োগ করতে হয়, বা যখন ক্লায়েন্ট দুটি স্তরযুক্ত টানেল চালাতে পারে না। নেস্টিং বেছে নিন যখন ভেতরের পেলোড A-তে অপাঠ্য থাকতে হয়। পর্যবেক্ষক ও MTU সংখ্যাসহ সিদ্ধান্তটি লিখে রাখুন, তাহলে পরের ব্যক্তিকে একটি প্রশ্নের উত্তর দিতে গোটা ছবি আবার আঁকতে হবে না।