বিভক্ত টানেল: আপনি সেট করা VPN-এর বাইরে লিংক কেন খোলে
রাউটিং সকেট খোলে যে প্রক্রিয়া সেটিকে অনুসরণ করে, আপনাকে লিংক দেখানো অ্যাপটিকে নয়। আপনার বর্জনগুলো বাড়ানোর আগে প্রমাণ করুন কোন প্রোগ্রাম সংযুক্ত হচ্ছে।
কোনো অ্যাপকে টানেলের ভিতর দিয়ে পাঠালে সেই অ্যাপ যা কিছু চালু করে তার সঙ্গে তার রাউটিংও চলে যায় না, যদিও ইন্টারফেস উল্টোটা ইঙ্গিত দেয়। একটি লিংক অনুরোধটি অন্য প্রোগ্রামের হাতে দেয়, সেই প্রোগ্রাম নিজের সকেট খোলে, এবং প্লাটফর্ম নিয়মগুলো নতুন প্রক্রিয়ার উপর প্রয়োগ করে, যে প্রক্রিয়া লেখাটি দেখিয়েছে তার উপর নয়। টানেল নীতি আসলে সেই দ্বিতীয় প্রক্রিয়াটিকেই দেখে, আর সেটি আপনি যে প্রক্রিয়া সেট করেছেন তা নয়।
তাই অন্তর্ভুক্ত কোনো অ্যাপ টানেলের বাইরে থাকা ব্রাউজার খুলতে পারে। বর্জিত ব্রাউজার কাজ ফিরিয়ে দিতে পারে এমন কোনো অ্যাপকে যা তার ভিতরে থাকে। এই আশ্চর্যের দুই দিকই সাধারণ আচরণ।
কর্মপ্রবাহের যে অংশটি কেউ সেট করেনি
প্রতি-অ্যাপ নীতি লেখা হয় কোনো এক্সিকিউটেবল বা প্যাকেজ পরিচয়ের বিরুদ্ধে, এবং প্রতিটি সংযোগ তৈরি হওয়ার মুহূর্তেই মূল্যায়ন করা হয়। ব্রাউজার, ডকুমেন্ট ভিউয়ার, মিডিয়া প্লেয়ার আর সিস্টেমের শেয়ার শিট—প্রত্যেকের নিজস্ব পরিচয় থাকে, আর প্রত্যেকে নিজের রায় পায়। একটি ডিপ লিংক তথ্য বহন করে, নীতি নয়।
এইজন্যই পর্যবেক্ষণটি খাপছাড়া মনে হয়: একই ক্লিক দুই দিকে রাউট হয়, নির্ভর করে কোন হ্যান্ডলার উত্তর দেয় তার উপর। টানেলের ভিতরের একটি মেইল ক্লায়েন্ট টানেলের বাইরে থাকা ব্রাউজারে লিংক খোলে, আর পৃষ্ঠাটি আপনার বাড়ির ঠিকানা থেকে লোড হয়। টানেলের বাইরের ব্রাউজার তার ভিতরে থাকা ভিউয়ারে একটি ডকুমেন্ট খোলে, আর ফাইলটি আসে এক্সিট দিয়ে। দুই ফলাফলের কোনোটিই ক্লায়েন্টের ত্রুটি নয়।
আগে থেকেই চলা হ্যান্ডলার পরিস্থিতি আরও খারাপ করে। ব্রাউজার যদি আগেই খোলা থাকে, লিংকটি একটি বিদ্যমান প্রক্রিয়ার কাছে বার্তা হয়ে যায়, আর সেই প্রক্রিয়া চালু হওয়ার সময় যে রাউটিং ছিল তা-ই ধরে রাখে। হ্যান্ডলার বন্ধ করে আবার খুললে ফলাফল বদলে যায়, তাই সমস্যাটি কখনো চাহিদা মতো পুনরুৎপাদন হয় না।
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
সংযোগটি আসলে কোন প্রক্রিয়া তৈরি করল
অনুমান করার বদলে গ্রহণকারী দিকটি মাপুন। টানেল চালু রাখুন, একটি নিরীহ লিংকে ক্লিক করুন, এবং নতুন প্রোগ্রামটি যে সকেটগুলো ধরে আছে তা দেখুন।
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
প্রথম কমান্ডটি লিনাক্সে প্রতিটি প্রতিষ্ঠিত সকেটের পেছনের প্রক্রিয়ার নাম দেয়, আর দ্বিতীয়টি উইন্ডোজে মালিকানা প্রক্রিয়া শনাক্তকারী সমাধান করে একই কাজ করে। প্রক্রিয়ার নামটি আপনার নীতির নামগুলোর সঙ্গে মেলান। যদি নামটি ব্রাউজার হয় এবং ব্রাউজার বর্জিত হয়, তবে ক্লিকটি ত্রুটিতে নয়, নকশা অনুযায়ীই টানেলের বাইরে গেছে। নীতির নিয়মকে জীবন্ত সকেটের সঙ্গে মেলানোই পুরো পদ্ধতি।
হ্যান্ডলার আগে থেকেই চলা অবস্থায়, তারপর তা বন্ধ অবস্থায় পরীক্ষাটি পুনরাবৃত্তি করুন। দুই ফলাফল আলাদা হতে পারে, এবং সেই পার্থক্যই টানেল থেকে পালানো লিংক নিয়ে বেশিরভাগ মাঝে মাঝে আসা অভিযোগ ব্যাখ্যা করে।
কভারেজ কর্মপ্রবাহের একটি বৈশিষ্ট্য
কোনো কাজ যদি শুরু থেকে শেষ পর্যন্ত টানেলের ভিতরে থাকতে হয়, তবে তার পৌঁছানো যায় এমন প্রতিটি উপাদানকে নীতির ভিতরে থাকতে হবে: লঞ্চার, হ্যান্ডলার, ভিউয়ার, এবং প্লাটফর্ম তাদের মাঝখানে যে মধ্যস্থতাকারী বসায়, সেটিও। চওড়া কভারেজই প্রায়ই সৎ উত্তর, আর প্রতিটি শেয়ার লক্ষ্য নিরীক্ষা করার চেয়ে এটি সস্তা।
একটি অ্যাপ ঠিক করতে সিস্টেমের মধ্যস্থতাকারী বর্জন করা সাধারণ ভুল। মধ্যস্থতাকারীরা ভাগাভাগি হয়, তাই বর্জনটি একই পথ ব্যবহার করা অন্য প্রতিটি অ্যাপের সঙ্গেও যায়, সাধারণত কেউ সপ্তাহ কয়েক পরে কোনো রিপোর্ট না আসা পর্যন্ত তা খেয়াল করে না। উপাদানটি বর্জন করার আগে পড়ুন আর কী তার উপর নির্ভর করে।
পরিচয়কে রাউটিং থেকে আলাদাও রাখুন। একটি লিংক সেশন টোকেন বা অ্যাকাউন্ট শনাক্তকারী বহন করতে পারে, অনুরোধটি কোন এক্সিট পায় তার নির্বিশেষে। সঠিকভাবে রাউট করা ক্লিকও গন্তব্যকে ঠিক বলতে পারে কে এটি অনুসরণ করেছে।
কর্মপ্রবাহ নথিভুক্ত করুন, প্রথম চেকবক্সটি নয়। যখন একটি কাজ চারটি প্রোগ্রাম জুড়ে ছড়ায়, তখন চারটি প্রোগ্রামওয়ালা চিত্রটিই বলে দেয় ট্রাফিক কোথায় যাবে, আর একক-অ্যাপ সেটিং তার মাত্র একটি সারি।