Apple VPN On Demand-এর ডোমেইন নিয়ম কীভাবে টানেল চালু করে
ডোমেইন নিয়ম কেবল ঠিক করে টানেল কখন খুলবে। connect-if-needed DNS প্রোব কীভাবে কাজ করে, রুটগুলো কেন এখনও ট্রাফিক বেছে নেয়, আর প্রোফাইল কীভাবে পরীক্ষা করবেন।
আপনি একটি অভ্যন্তরীণ নাম অনুরোধ করলে টানেল খোলে, আর পরের অ্যাপটিরও ঠিক ততটাই দরকার হলেও তা বন্ধ থাকে। এটি অ্যাপের বাগ নয়; এটি ডোমেইন নিয়মের গঠন। Apple-এর on-demand কনফিগারেশন সংযোগ তৈরির শর্ত বর্ণনা করে, আর সেই শর্তগুলোর ডোমেইন রূপ একটি প্যাকেটও নড়ার আগেই সিস্টেম রিজলভারকে একটি প্রশ্ন করে। দুটি প্রশ্ন নিয়মিত মিশে যায়: টানেল কখন উঠবে, এবং টানেল তৈরি হওয়ার পর কী বহন করে। প্রথমটি ট্রিগার, দ্বিতীয়টি রুট ও রিজলভার নীতি, আর একটি প্রোফাইল সাধারণত একই পেলোডে দুটোই সেট করে, তাই সঠিক ডোমেইন নিয়মেও আপনি ভুল নেটওয়ার্কে থাকতে পারেন।
ট্রিগার ও ট্রাফিক নির্বাচন আলাদা স্তরে থাকে
on-demand নিয়ম VPN পেলোডের on-demand অভিধানে থাকে: ক্রমবদ্ধ নিয়মের তালিকা, প্রতিটির একটি অ্যাকশন ও কিছু ম্যাচ শর্ত থাকে। সংযোগ পরিবর্তন হলে বা কিছু নেটওয়ার্কে পৌঁছাতে চাইলে সিস্টেম সেগুলো মূল্যায়ন করে, আর অ্যাকশন ঠিক করে টানেল তোলা হবে, মূল্যায়ন হবে, বিচ্ছিন্ন হবে নাকি উপেক্ষা করা হবে। এসবই প্ল্যাটফর্মের নেটওয়ার্কিং স্তরে ঘটে, আপনার অ্যাপের সকেট হওয়ার আগেই।
এর পরে যা ঘটে তা আলাদা কী-এর গ্রুপ: টানেলের IPv4 ও IPv6 সেটিংস, তার অন্তর্ভুক্ত ও বাদ দেওয়া রুট, DNS সার্ভার ঠিকানা, এবং iOS ও iPadOS-এ প্রতি-অ্যাপ ম্যাপিং যা ঠিক করে কোন অ্যাপগুলো আদৌ টানেল ব্যবহার করতে পারবে। একটি প্রোফাইল প্রশস্ত ট্রিগারের সঙ্গে সংকীর্ণ রুট, বা সংকীর্ণ ট্রিগারের সঙ্গে ডিফল্ট রুট জোড়া দিতে পারে। শুধু এক অর্ধেক পড়ুন, অন্য অর্ধেকটি ত্রুটির মতো দেখাবে।
আমার একটি ল্যাব প্রোফাইল আছে যা অভ্যন্তরীণ ডোমেইনের অধীনে কিছু অনুরোধ হলেই সংযোগ করে, কিন্তু টানেলে শুধু একটি /16 রুট করে। এটি তার পেলোড যা বলে ঠিক তাই করে, আর এটি এমন ধরনের প্রোফাইল যা টিকিট তৈরি করে: মানুষ ধরে নেয় সংযুক্ত টানেল মানে তাদের ট্রাফিক তার ভেতরে।
ডোমেইন নিয়ম আসলে রিজলভারকে কী জিজ্ঞাসা করে
নিয়মের ডোমেইন রূপ, যাকে প্রায়ই connect-if-needed বলা হয়, প্যাকেট পেলোড পরীক্ষা করে না বা URL দেখে না। একটি নাম রিজলভ হলে সিস্টেম সেটি নিয়মের ডোমেইনগুলোর সঙ্গে তুলনা করে এবং মিললে জিজ্ঞাসা করে টানেল যে DNS সার্ভার দেয় সেগুলোর মাধ্যমে নামটি রিজলভ করা যায় কি না। টানেলের রিজলভার উত্তর দিলে নামটি অভ্যন্তরীণ গণ্য হয় এবং সংযোগ শুরু হয়। স্থানীয় রিজলভার উত্তর দিলে নামটি বহিরাগত গণ্য হয় এবং কোনো টানেল দেখা যায় না। Apple-এর ডিপ্লয়মেন্ট ওভারভিউ এগুলোকে নেটওয়ার্ক শনাক্তকরণ ও তারপর সংযোগ মূল্যায়ন বলে বর্ণনা করে।
দুটি পরিণতি আসে। প্রোফাইলে টানেলের ভেতরে DNS সার্ভার উল্লেখ থাকতে হবে; টানেল রিজলভার ছাড়া ডোমেইন নিয়মের তুলনা করার কিছু থাকে না, তাই মূল্যায়ন আপনার প্রত্যাশিত মিল দিতে পারে না। আর লুকআপটি সিস্টেম রিজলভার পর্যন্ত পৌঁছাতে হবে। যে অ্যাপ বা ব্রাউজার নিজের এনক্রিপ্টেড DNS চালায়, যে এক্সটেনশন স্থানীয়ভাবে উত্তর দেয়, বা আক্ষরিক ঠিকানায় সংযোগ — এগুলো কখনোই সেই নাম রিজলিউশন তৈরি করে না যা নিয়মটি অপেক্ষা করছিল। আমার সবচেয়ে দীর্ঘ বিকেলগুলোর একটি শেষ হয়েছিল যখন দেখলাম টানেলের সামনের ক্লায়েন্টটি DNS over HTTPS ব্যবহার করছে।
ক্যাশিংও ট্রিগার সরিয়ে দেয়। ক্যাশে থাকা নামে সেই প্রোব ছাড়াই উত্তর দেওয়া হতে পারে যা টানেল চালু করত, তাই গতকাল যে নিয়ম কাজ করেছিল তা রিবুটের পরে, বা টানেল কিছুক্ষণ চালু থাকার পরে ব্যর্থ হয়। macOS-এ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder অবস্থা রিসেট করে; iOS-এ বিমান মোড চালু-বন্ধ করা বা ডিভাইস রিস্টার্ট করা তুলনীয় পরিচ্ছন্ন অবস্থা দেয়।
ম্যাচের পরিধি: নাম, অ্যাপ ও নেটওয়ার্ক
ডোমেইন ম্যাচিং কয়েক ধরনের একটি। একটি নিয়ম ইন্টারফেসের ধরন (Wi-Fi, সেলুলার, Ethernet) ও নির্দিষ্ট SSID-ও ম্যাচ করতে পারে, আর প্রতি-অ্যাপ বা Safari-ডোমেইন এন্ট্রি একটি টানেলকে একটি কর্মপ্রবাহে বেঁধে দেয়। এই বন্ধনই সেই অদ্ভুত অভিজ্ঞতা ব্যাখ্যা করে যেখানে শুধু একটি অ্যাপ বাকি সবকিছুর চেয়ে ভিন্নভাবে আচরণ করে: বাকি অ্যাপগুলো টানেলের পরিধির বাইরে, তাই টানেল আইকন সংযুক্ত বললেও তারা স্থানীয় পথই ব্যবহার করে।
ক্রম মানুষ যতটা ভাবে তার চেয়ে বেশি গুরুত্বপূর্ণ। নিয়মগুলো ক্রমান্বয়ে মূল্যায়িত হয় এবং প্রথম মিলে যাওয়াটিই অ্যাকশন দেয়, তাই সংকীর্ণ ডোমেইন নিয়মের উপরে রাখা যেকোনো Wi-Fi-তে সংযোগ করার প্রশস্ত নিয়ম নীরবে জিতে যাবে এবং ডোমেইন নিয়মকে অপরীক্ষণীয় করে তুলবে। ডোমেইন তালিকা পুনর্লিখনের আগে নিশ্চিত করুন আগের কোনো নিয়ম ইতিমধ্যে মেলেনি।
এজন্যই always-on শুধু কঠোরতর on-demand নিয়ম নয়। always-on প্রয়োগ একটি আলাদা ডিপ্লয়মেন্ট মোড যার নিজস্ব তদারকি ও ব্যবস্থাপনা প্রয়োজন; এটি নামের প্রতি প্রতিক্রিয়া না দেখিয়ে টানেল খোলা রাখে। আপনার যদি এমন টানেল দরকার যা কখনো পড়ে না, ডোমেইন নিয়ম ভুল হাতিয়ার।
ভাঙা নিয়মের মতো দেখতে ব্যর্থতার ধরন
ডোমেইন নিয়ম কাজ করছে না—এমন বেশিরভাগ প্রতিবেদন পাঁচটি জায়গার একটিতে পড়ে, আর তাদের মধ্যে কেবল শেষটিই নিয়মের লেখা।
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
ক্যাপটিভ পোর্টাল আলাদা লাইনের দাবিদার, কারণ হোটেল ও বিমানবন্দরের Wi-Fi ঠিক সেই লুকআপই আটকায় যার উপর নিয়ম নির্ভর করে। পোর্টাল ডিভাইসটিকে ঢুকতে না দেওয়া পর্যন্ত টানেলের DNS সার্ভার পৌঁছানোর বাইরে থাকে, প্রোব ব্যর্থ হয়, আর ব্যর্থতাটি ভুল বানানের ডোমেইনের মতো দেখায়। প্রমাণীকরণ আরেকটি নীরব ঘটনা: নিয়ম চালু হতে পারে, টানেল সংযোগ শুরু করতে পারে, আর সংযোগ মরে মেয়াদোত্তীর্ণ সার্টিফিকেটে বা অন্য ডিসপ্লেতে আসা প্রম্পটে।
IPv6 একটি রূপ তৈরি করে যা ভুল নির্ণয় করা সহজ। উভয় ঠিকানা পরিবার থাকা নামে আগে AAAA রেকর্ড থেকে উত্তর আসতে পারে, অথচ টানেলের রুট তালিকায় শুধু IPv4 থাকে। একটি ব্রাউজার সফল হয়, আরেকটি ব্যর্থ, আর ডোমেইন তালিকা সম্পূর্ণ নির্দোষ।
বাস্তব অনুরোধ দিয়ে, এই ক্রমে পরীক্ষা করুন
অনুমান করার আগে নীতি পড়ুন। macOS-এ sudo profiles show -type configuration VPN পেলোডসহ ইনস্টল করা প্রোফাইল ছাপে, scutil --nc list সার্ভিসের অবস্থা দেখায়, আর scutil --nc show <service> সিস্টেম যে on-demand অভিধান ব্যবহার করছে তা ছাপে। ম্যানেজড iPhone বা iPad-এ একই পেলোড ম্যানেজমেন্ট কনসোল বা MDM রিপোর্ট থেকে আসে। macOS-এ log stream --predicate 'subsystem == "com.apple.networkextension"' দিয়ে নেটওয়ার্কিং লগ পাওয়া যায়, আর ফোন সংযুক্ত থাকলে ডিভাইস কনসোলের মাধ্যমে।
তারপর এমন হোস্টনাম দিয়ে পরীক্ষা করুন যা সেশনে আগে জিজ্ঞাসা করা হয়নি। টানেলের DNS জোনে এমন নাম বাছুন যা আপনি জানেন অভ্যন্তরীণভাবে রিজলভ হয়, একবার অনুরোধ করুন, আর দেখুন টানেল আসে কি না। একই লুকআপ দুবার চালান: দ্বিতীয় প্রচেষ্টা ক্যাশ পথ ব্যবহার করে, আর দুটির পার্থক্যই বলে দেয় ট্রিগারটি রিজলিউশন নাকি রাউটিং।
টানেল ওঠার পর দুটি স্তর আলাদাভাবে যাচাই করুন। netstat -rn -f inet ও netstat -rn -f inet6 দেখায় প্রতিটি প্রিফিক্স কোথায় নির্দেশ করে, scutil --dns রিজলভারের ক্রম ও কোন ইন্টারফেস কোন রিজলভারের মালিক দেখায়, আর nettop -m route দেখায় কোন ইন্টারফেস বাইট বহন করেছে। টানেল চালু ও রিজলভার সঠিক হওয়া সত্ত্বেও সম্পদ ব্যর্থ হলে নিয়ম সম্পাদনা বন্ধ করুন; সার্ভার-সাইড অনুমোদন ও ফেরত রুট দেখুন।
যখন নিয়মটি অন্য কারও
সংযোগ বিচ্ছিন্ন করার পরও টানেল ফিরে এলে নিয়মটি সাধারণত অ্যাপের নয়, প্রোফাইলের: MDM-পুশ করা কনফিগারেশন, পড়ে থাকা ব্যক্তিগত প্রোফাইল, বা অন্য ক্লায়েন্টে ইনস্টল করা প্রোফাইল। sudo profiles show -type configuration এবং on-demand কী-গুলোর অনুসন্ধান তা সংকুচিত করবে, আর অপসারণের পথ প্রোফাইল, মেনু বারের টগল নয়। সার্ভিস এন্ট্রি বা অ্যাপ মুছে দিলে নিয়মটি থেকে যায়, আর পরের ইনস্টলেশন আবার তা উত্তরাধিকারে পায়।
একটি পরীক্ষাই মালিকানা ঠিক করে: বিচ্ছিন্ন করুন, অপেক্ষা করুন, আবার অভ্যন্তরীণ নামটি অনুরোধ করুন। টানেল ফিরে এলে ট্রিগারটি ডিজাইন অনুযায়ী কাজ করছে এবং খোলা প্রশ্ন হলো কে এটি পরিচালনা করে এবং সেই পরিধিই আপনি চান কি না।
এটিকে বাগ হিসেবে দায়ের করার আগে একই পাঁচটি যাচাই করুন: পেলোডে টানেল রিজলভার ঠিকানা আছে, নামটি ক্যাশ হয়নি, আগের কোনো নিয়ম মেলেনি, রুট তালিকা AAAA পথ ঢাকে, এবং অ্যাপটি টানেলের পরিধির ভেতরে। পাঁচটিই সত্য হলে নিয়মটি নিজের কাজ করছে এবং ত্রুটি পথের আরও সামনে।