পূর্ণ টানেল বনাম বিভক্ত টানেল: যে চারটি বিষয় আলাদা
লেবেলটি ঠিক করে ল্যাপটপের বাকি ট্রাফিক কোথা দিয়ে বেরোবে, কত দ্রুত যাবে তা নয়। বেছে নেওয়ার আগে এগ্রেস, লোড, DNS আর ব্যর্থতার আচরণ তুলনা করুন।
টানেলের লেবেল বোঝায় ল্যাপটপের বাকি ট্রাফিক কোথায় যায়, কত দ্রুত যায় তা নয়। পূর্ণ টানেলে পাবলিক অনুরোধ ইন্টারনেটে যাওয়ার আগে VPN গেটওয়ে পার হয়। বিভক্ত টানেলে ব্যক্তিগত গন্তব্য টানেল ব্যবহার করে আর বাকি সব স্থানীয় পথ নেয়। দুটোই অভ্যন্তরীণ অ্যাপে পৌঁছায়, তাই মানুষ প্রথমে যে পৌঁছানোযোগ্যতার পরীক্ষা চালায় তা কোন নীতি প্রয়োগ হয়েছে তা বলে না।
বরং প্রস্থান পরীক্ষা করুন: পাবলিক ইকো পৃষ্ঠা কোন ঠিকানা জানায়, আর কোন রিজলভার উত্তর দিয়েছে।
ভ্রম: বিভক্ত টানেল শুধু দ্রুততর বিকল্প
বিভক্ত টানেলকে প্রায়ই কর্মক্ষমতার বৈশিষ্ট্য হিসেবে বিক্রি করা হয়, আর তা হতে পারে, কিন্তু এটি সংজ্ঞা নয় বরং পার্শ্বপ্রতিক্রিয়া। সংজ্ঞা হলো কোন গন্তব্য টানেলে ঢুকবে তা নিয়ে রাউটিং সিদ্ধান্ত। গতির পার্থক্য তখনই দেখা যায় যখন সরাসরি পথ সত্যিই অফিসের মধ্য দিয়ে ঘুরপথের চেয়ে ভালো। ভিড়যুক্ত হোম লিংক আর হালকা লোডের গেটওয়েতে পূর্ণ টানেল দুটোর মধ্যে দ্রুততর হতে পারে।
তাই সৎ বাক্যবিন্যাস পথের মালিকানা ও নিয়ন্ত্রণ নিয়ে, আর কর্মক্ষমতা পরে মাপার জিনিস। গতির জন্য বেছে নেওয়া কোনো নীতি যদি চুপচাপ আপনার DNS আর পাবলিক এগ্রেস সরিয়ে দেয়, তবে সেটি ভুল কারণে বেছে নেওয়া হয়েছে।
আসলে কী বদলায়: প্রস্থান
পূর্ণ টানেলে পাবলিক ওয়েবসাইট অফিসের এগ্রেস ঠিকানা দেখে আর অফিসের ফিল্টারিং অনুরোধ দেখে। বিভক্ত টানেলে একই সাইট ব্যবহারকারীর হোম ঠিকানা দেখে আর অফিস কিছুই দেখে না। এগুলো আলাদা দৃশ্যমানতার মডেল, আর কোনোটিই স্বয়ংক্রিয়ভাবে নিরাপদ নয়। কাজের প্রশ্ন হলো সংস্থা আসলে কোনটি চালাতে পারে।
সংযুক্ত থাকার ব্যাজে ভরসা না করে সরাসরি এটি পরীক্ষা করুন। পাবলিক ঠিকানার ইকো প্রস্থান দেখায়, আর রিজলভার পরীক্ষা দেখায় কার DNS উত্তর দিয়েছে।
| Question | Full tunnel | Split tunnel |
|---|---|---|
| Public exit address | Office egress | Local connection |
| Gateway load | All covered traffic | Private destinations only |
| Office visibility | Requests and destinations | Private resource access only |
গেটওয়েকে তখন কী বহন করতে হয়
ভিডিও কল, ডাউনলোড আর ব্যক্তিগত অ্যাপ বহন করা গেটওয়ের সম্পূর্ণ ভিন্ন কাজের চাপের জন্য ক্ষমতা দরকার, শুধু অভ্যন্তরীণ অনুরোধ বহন করা গেটওয়ের চেয়ে। সাইটের ইন্টারনেট সংযোগ একসাথে ব্যবহারকারীর আগমন আর পরবর্তী পাবলিক এগ্রেস বহন করে, তাই দুটি লিংক একসাথে সম্পৃক্ত হতে পারে।
স্থানীয় ব্রেকআউট সেই লোড আর ঘুরপথ সরায়, আর এটি ভালো অভিজ্ঞতার নিশ্চয়তা দেয় না, কারণ সরাসরি পথও ভিড়যুক্ত হতে পারে। রাউটিং লেবেলকে কর্মক্ষমতার মাপ হিসেবে গণ্য না করে আসল অ্যাপ তুলনা করুন।
পূর্ণ টানেলেও ব্যতিক্রম থাকে
ডিফল্ট রুট প্রতিটি প্যাকেটের তালিকা নয়। আরও নির্দিষ্ট রুট, স্থানীয় নেটওয়ার্কের অনুমতি, অ্যাপ্লিকেশন বাদ আর আলাদা IPv6 নিয়ম সবই ট্রাফিক সরায়, তাই পূর্ণ টানেল নামে বর্ণিত নীতি এখনও ফাঁস হতে পারে। অপারেটিং সিস্টেমের রাউটিং ডকুমেন্টেশন জোরপূর্বক টানেলের ডিফল্টের জন্য এই পার্থক্য করে, আর ক্লায়েন্টের বাদ তালিকাই সাধারণত ফাঁসের জায়গা। আচরণ যাচাই করুন, অভিপ্রায় নয়।
IPv6 আলাদা করে দেখা দরকার, কারণ যে টানেল শুধু IPv4 বহন করে তা পুরো স্ট্যাক নীতির বাইরে রাখে।
DNS আলাদা নীতি
অভ্যন্তরীণ নামের জন্য এমন রিজলভার দরকার যা সেগুলো জানে, আর সেই রিজলভার হয়তো শুধু টানেল দিয়েই পৌঁছানো যায়। নিজস্ব এনক্রিপ্টেড DNS থাকা ব্রাউজার সিস্টেম রিজলভার পুরোপুরি এড়িয়ে যেতে পারে, ফলে এমন বিভাজন হয় যেখানে অভ্যন্তরীণ নাম ব্যর্থ হয় আর পাবলিক নাম কাজ করে, অথবা উল্টোটা।
লুকআপ কোথায় যাবে তা ঠিক করুন, তারপর ক্লায়েন্ট আর ব্রাউজারকে একমত করুন। সফল পাবলিক ব্রাউজিং কখনো অভ্যন্তরীণ নাম সমাধান পরীক্ষা করে না, তাই ইন্ট্রানেট সাইট হারিয়ে গেলে এটি ভুল প্রমাণ।
ব্যর্থতার নীতি লিখুন, তারপর তা পরীক্ষা করুন
টানেল পড়ে গেলে কী হবে তা ঠিক করুন: সব ব্লক করুন, শুধু ব্যক্তিগত সম্পদ ব্লক করুন, বা সরাসরি সংযোগ অনুমতি দিন। স্বয়ংক্রিয় পুনঃসংযোগ এই প্রশ্নের উত্তর দেয় না, আর যে কিল সুইচ শুধু টানেল ইন্টারফেস ঢাকে তা বাদ দেওয়া অ্যাপকে খোলাখুলি কথা বলতে দিতে পারে। সত্যিকারের সংযোগ বিচ্ছিন্নতা আর নেটওয়ার্ক পরিবর্তন পরীক্ষা করুন, তারপর ক্লায়েন্টের অবস্থা পড়ুন, কারণ ডকুমেন্টেশন অভীষ্ট আচরণ বর্ণনা করে, ইনস্টল করা আচরণ নয়।
ব্যক্তিগত রুট, পাবলিক প্রস্থান, DNS সার্ভার, স্থানীয় ব্যতিক্রম আর ব্যর্থতার আচরণ এক সংক্ষিপ্ত নোটে লিখুন। সেই নোটই নীতিটিকে এমন কারও কাছে যাচাইযোগ্য করে তোলে যে এটি লেখেনি।