একটি লিনাক্স মেশিনে দুটি VPN: ফলাফল না মিশিয়ে প্রতিটি আলাদা করে পরীক্ষা করুন
দুটি সবুজ আইকন কোনো তুলনা নয়। প্রতিটি টানেলকে নিজের নেমস্পেসে রাখুন, আগে প্রত্যাশা লিখুন, এবং ফলাফলে ভরসা করার আগে পথটি প্রমাণ করুন।
দুটি সবুজ সংযোগ আইকনকে তুলনা মনে হয়, কিন্তু সাধারণত সেটি কেবল কাকতালীয়। যদি পরীক্ষার অনুরোধ দুটি টানেলের যেকোনোটি ব্যবহার করতে পারত, তবে ফলাফলটি ভালো ক্ষেত্রে দুইয়ের একটি এবং খারাপ ক্ষেত্রে কোনোটিকেই বর্ণনা করে না। প্রতিটি পর্যবেক্ষণকে একটি নেটওয়ার্ক প্রসঙ্গ, একটি অভীষ্ট গন্তব্য এবং পরীক্ষা শুরুর আগে লেখা একটি প্রত্যাশা দিন। নিজে পরিচালিত লিনাক্স মেশিনে নামযুক্ত নেটওয়ার্ক নেমস্পেস হলো সেই বিচ্ছিন্নতা কেনার সবচেয়ে সস্তা উপায়।
দুটি সবুজ বাতি কোনো তুলনা নয়
একটি নেমস্পেস রাউটিং টেবিল, ইন্টারফেস ও নেটওয়ার্ক-স্ট্যাকের অবস্থা আলাদা রাখে, তাই একটির ভিতরে শুরু হওয়া অনুরোধ নিঃশব্দে অন্যটির টানেল ধার করতে পারে না। যা এটি আলাদা করে না তা হলো প্রসেসর, একটি ভৌত আপলিংক, বা হোস্টে চলা রিজলভার ডেমন। শেষের এই ফাঁকেই এসব পরীক্ষার বেশিরভাগ নিঃশব্দে ব্যর্থ হয়। যে লুকআপ নেমস্পেস ছেড়ে হোস্টের রিজলভারকে জিজ্ঞাসা করে, সেটি পরীক্ষাধীন টানেলের সঙ্গে কোনো সম্পর্কহীন উত্তর ফেরত দেয়।
এই পদ্ধতিটি ধরে নেয় দুটি আগেই প্রস্তুত, অনুমোদিত পরীক্ষা নেমস্পেস, কার্যকর বাহ্যিক সংযোগ ও সমর্থিত ক্লায়েন্ট। এটি কিছু তৈরি করে না, কিছু নথিভুক্ত করে না এবং কোনো কনফিগারেশন প্রতিস্থাপন করে না। ক্লায়েন্টের সম্পূর্ণ ডেস্কটপ সেশন দরকার হলে বা তার বাইরে চলতে অস্বীকার করলে আলাদা ভার্চুয়াল মেশিনই সৎ পছন্দ।
প্রথম চালনার আগেই প্রত্যাশা স্থির করুন
প্রতিটি প্রসঙ্গের জন্য ঠিক করুন সাফল্য কেমন দেখায়: রিজলভার, সার্ভিসের নাম, প্রত্যাশিত ঠিকানা এবং টানেল পড়ে গেলে প্রয়োজনীয় আচরণ। এই পরিকল্পিত মানগুলো নিজের কলামে রাখুন, কারণ যে রেকর্ড পরিকল্পনা ও পর্যবেক্ষণ মেশায় তা টাইমস্ট্যাম্পযুক্ত কল্পনা। নিচের চেকলিস্টটাই সেই আকৃতি যা রেকর্ডের দরকার, এবং প্রথম সংযোগের আগে প্রতিটি সারি পূরণযোগ্য হতে হবে।
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
রিজলভারের তার জোড়া সেই রেকর্ডে নিজের লাইন চায়, কারণ এই ক্ষেত্রটিই মিথ্যা বলার সম্ভাবনায় সবচেয়ে বেশি। নেমস্পেস-সংযুক্ত ফাইল, যেমন /etc/netns/vpn-a/resolv.conf নেমস্পেসের ভিতরে কমান্ড চললে স্বাভাবিক পথেই দেখা যায়, যেমনটি iproute2-এর নেমস্পেস রেফারেন্স বর্ণনা করে, তবে নাম-সেবা সুইচ কনফিগারেশন এবং এটি চালু করা যেকোনো স্থানীয় রিজলভার এখনও লুকআপকে হোস্টের দিকে ফিরিয়ে টানতে পারে।
একবারে একটি টানেল, অন্যটি সংযোগবিহীন
B বন্ধ থাকা অবস্থায় A-কে তার বিদ্যমান মালিকের মাধ্যমে সংযুক্ত করুন, তারপর প্রশাসনিক প্রসঙ্গ থেকে পলিসি, রুট ও নির্বাচিত পথ পরীক্ষা করুন। নিচের কমান্ডগুলোর তিনটি অবস্থা পড়ে; কেবল শেষটিই একটি নাম-সেবার সঙ্গে যোগাযোগ করে, এবং কোনোটিই কোনো অ্যাপ্লিকেশন অনুরোধ পাঠায় না।
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalরুট লুকআপ কোনো গন্তব্য সম্পর্কে একটি অনুমানমূলক প্রশ্নের উত্তর দেয়, তাই এটি দেখাতে পারে না যে সেবাটি ট্রাফিক গ্রহণ করে। এই দুই ধরনের প্রমাণ আলাদা কলামে রাখুন, কারণ প্রত্যাখ্যাত সংযোগের পাশে সুস্থ রুট একটি বাস্তব ও সাধারণ ফলাফল। তারপর আসল অ্যাপ্লিকেশন দিয়ে একটি নিরীহ অনুমোদিত অনুরোধ পাঠান, যা A-এর প্রসঙ্গে তার স্বাভাবিক অ-বিশেষাধিকারপ্রাপ্ত ব্যবহারকারী হিসেবে চালু হবে, সার্টিফিকেট যাচাই ও অ্যাপ্লিকেশন প্রমাণীকরণ অক্ষত রেখে, এবং সেবাটি যে উৎস ঠিকানা দেখেছে তার সঙ্গে ফলাফল লিখে রাখুন। A-কে তার মালিকের মাধ্যমে বিচ্ছিন্ন করুন এবং B-এর জন্য পুরো বেসলাইন পুনরাবৃত্তি করুন, আপনার করা যেকোনো কনফিগারেশন পরিবর্তন উল্লেখ করে, নইলে দুই বেসলাইন আর তুলনীয় থাকে না।
দুটোই চালু, তারপর একবারে একটি বন্ধ
স্থির অবস্থা সহজ অংশ। দুটি টানেল সংযুক্ত থাকলে প্রতিটি প্রসঙ্গের লুকআপ ও অ্যাপ্লিকেশন অনুরোধ পুনরাবৃত্তি করুন, তারপর একটি টানেল ভেঙে অন্যটি পরীক্ষা করুন। সংযোগের ক্রম নিজেই যদি প্রশ্ন হয়, তবে উল্টো ক্রমে পুনরায় সংযুক্ত করুন।
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20ক্যাপচার এমন বিতর্ক মেটায় যা অ্যাপ্লিকেশন ফলাফল মেটাতে পারে না: এটি দেখায় অনুরোধটি আপনার প্রত্যাশিত ইন্টারফেস দিয়ে বেরিয়েছে, নাকি সম্পূর্ণ অন্য কিছু দিয়ে। প্রতিটি রূপান্তরের জন্য মালিকের কাজ, টাইমস্ট্যাম্প, রুট ফলাফল, নাম ফলাফল ও অ্যাপ্লিকেশন ফলাফল লিখুন। তারপর ক্ষতিগ্রস্ত নেমস্পেসের ভিতরে ফেইল-ক্লোজড শর্তটি পরীক্ষা করুন, কারণ বিচ্ছিন্নতা কোনো কিল সুইচ নয়। একটি নেমস্পেস দুটি টানেলকে আলাদা রাখে; কিন্তু প্রোফাইল যখন বলে ট্রাফিক থামতেই হবে, তখন এটি কোনোটিকেই ট্রাফিক বহন করা থেকে বিরত করে না।
এই রেকর্ড কী দাবি করতে পারে আর কী পারে না
একটি পাস এই ব্যবস্থার জন্য, এই হোস্টে, ওই সময়ে সেই পর্যবেক্ষণগুলো প্রমাণ করে। এটি একটি ডেস্কটপ রাউটিং টেবিল ভাগ করা দুটি ক্লায়েন্ট সম্পর্কে কিছু বলে না, এবং দুটি টানেল লোড বহন করার সময় থ্রুপুট সম্পর্কেও কিছু বলে না। ওগুলো আলাদা পরীক্ষাসহ আলাদা প্রশ্ন, আর তুলনা ঠিক ততটাই ভালো যতটা প্রতিটি সারির সঙ্গে যুক্ত প্রসঙ্গ।
ব্যর্থতাগুলো সফলতার পাশে রেকর্ডে রাখুন, ওই সময়ে কোন টানেল চালু ছিল তা চিহ্নিত করে। যে পরিচ্ছন্ন পাতা পরিমাপের সময়কার অবস্থা লুকায়, তা অবস্থা দেখানো কুৎসিত পাতার চেয়ে খারাপ। পরে রেকর্ডটি পুনরায় ব্যবহারযোগ্য করে তোলে প্রসঙ্গ, স্কোর নয়।
একটি মেশিনে দুটি টানেল সৎভাবে তুলনা করা যায়, কিন্তু কেবল ততগুলো প্রসঙ্গের ভিতরে যতগুলো আপনি সত্যিই নিয়ন্ত্রণ করেছেন। এর বাইরে যা কিছু তা পাশে সবুজ আইকন লাগানো একটি আকাঙ্ক্ষা।