iPhone VPN DNS: সেটিংটি কার মালিকানায় তা ঠিক করে কোথায় প্রযোজ্য হবে

একটি iPhone-এর Wi-Fi সেটিংসে ব্যক্তিগত রিজলভার ঠিকানা লিখুন, আর তা কাজ করবে যতক্ষণ ফোনটি সেই নেটওয়ার্ক ছাড়বে না — ঠিক তখনই VPN-এর নিয়ন্ত্রণ নেওয়ার কথা। এটাই মোবাইল DNS-এর প্রথম ফাঁদ: যে জায়গায় আপনি সেটিংটি দিয়েছেন সেটিই তার পরিধি নির্ধারণ করে, আর সেই পরিধি বেশিরভাগ মানুষের ধারণার চেয়ে সংকীর্ণ। কিছু সম্পাদনার আগে ডিপ্লয়মেন্ট সম্পর্কে তিনটি প্রশ্নের উত্তর দিন, কারণ উত্তরগুলোই ঠিক করে দেয় আপনার কোন নিয়ন্ত্রণে হাত দেওয়া উচিত। ক্রমটিকে সেটিংসের খোঁজ নয়, বরং একটি ডিজাইন পর্যালোচনা হিসেবে দেখুন।

রিজলভার ঠিকানা লেখার আগে তিনটি প্রশ্ন

প্রথমত, কোন নামগুলোর সত্যিই বিশেষ ব্যবস্থাপনা দরকার? corp.example-এর মতো ব্যক্তিগত জোন একটি নেমস্পেস, একক হোস্ট নয়, আর উত্তরটি একটি ডোমেইন হওয়া উচিত, একটি রেকর্ড নয়। দ্বিতীয়ত, কোন রিজলভার এর জন্য প্রামাণ্য, এবং সেই সেবাটির মালিক কে? তৃতীয়ত, কোন পথ সেই রিজলভারকে ফোন থেকে পৌঁছানোর উপযোগী করে: টানেল, রাউটেড Wi-Fi নেটওয়ার্ক, নাকি সম্পূর্ণ ভিন্ন কিছু?

এই তিনটির কোনোটির মালিক না থাকলে থামুন। নেমস্পেস, প্রামাণ্য উৎস ও পৌঁছানোর পথ ছাড়া করা DNS পরিবর্তন একটি অনুমান, যা অফিসের তুলনায় সেলুলারে ভিন্নভাবে ব্যর্থ হবে।

Wi-Fi-এর DNS এন্ট্রি সেই Wi-Fi নেটওয়ার্কেরই

iOS-এ ম্যানুয়াল DNS কনফিগারেশন নেটওয়ার্কভিত্তিক সংরক্ষিত হয়। ফোনটি সেই SSID-এর সাথে যুক্ত থাকাকালীন তা প্রযোজ্য হয় এবং না থাকলে প্রযোজ্য হওয়া বন্ধ করে, অর্থাৎ তা সেলুলার ট্রাফিক নিয়ন্ত্রণ করতে বা VPN ক্লায়েন্ট কী করে তা বর্ণনা করতে পারে না। সেলুলারে ব্যর্থ হওয়া একটি অ্যাপ ঠিক করতে এটি সম্পাদনা করা এমন একটি সেটিং পরিবর্তন, যা ব্যর্থ পথটি কখনো পড়ে না।

এতে নেটওয়ার্কভিত্তিক DNS অকেজো হয় না। হোম ল্যাব বা একক অফিস SSID-এর জন্য অভ্যন্তরীণ রিজলভারে পৌঁছানোর সবচেয়ে সহজ উপায় এটি, আর এটি তার সীমা সম্পর্কে সৎ।

VPN-এর DNS ব্যবস্থা প্রোটোকল ও ক্লায়েন্ট অনুসরণ করে

iOS-এ একটি প্যাকেট টানেল প্রোভাইডার Apple-এর DNS সেটিংস API-এর মাধ্যমে DNS কনফিগার করতে পারে, যা সংযোগের মালিক টানেলকে রিজলভার ঠিকানা ও ডোমেইন মেলানো প্রকাশ করে। নেটিভ IKEv2 কনফিগারেশন গেটওয়ে ঠেলে দিলে IKE কনফিগারেশন পেলোডের মাধ্যমে DNS পেতে পারে, তবে নির্দিষ্ট কোনো ক্লায়েন্ট যা পায় তা প্রয়োগ করে কি না সেটি বাস্তবায়নের খুঁটিনাটি, যা আপনাকে যাচাই করতে হবে। অ্যাপভিত্তিক ক্লায়েন্ট সম্পূর্ণ নিজস্ব রিজলিউশন পথ বাস্তবায়ন করতে পারে।

এগুলো ভিন্ন ইন্টিগ্রেশন পয়েন্ট, আর এগুলোর একটির ফল সব iPhone-এর জন্য নিয়ম হয়ে যায় না। সমর্থিত ব্যবস্থা হলো প্রোফাইল বা প্রোভাইডার ব্যবহৃত প্রোটোকলের জন্য যা নথিভুক্ত করে।

সুবিধা নয়, মালিকানা দেখে সিদ্ধান্ত নিন

ডিভাইসটি ব্যবস্থাপিত হলে প্রোফাইল মালিকের VPN কনফিগারেশনের সাথে DNS সেটিং সরবরাহ করা উচিত, যাতে পুনঃনিবন্ধন ব্যবহারকারী কিছু মনে না রেখেই তা পুনরুদ্ধার করে। প্রোভাইডার অ্যাপ টানেলের মালিক হলে তার সেটিংস স্ক্রিনই দেখার জায়গা, আর কী ভাগ করা যায় সে বিষয়ে তার ডকুমেন্টেশনই প্রামাণ্য। ফোনটি ব্যক্তিগত হলে এবং প্রয়োজন এক নেটওয়ার্কে একটি অভ্যন্তরীণ নাম হলে নেটওয়ার্কভিত্তিক সেটিংটিই সংগত।

সিদ্ধান্তের নিয়ম সংক্ষিপ্ত: সেটিংটি সেখানেই থাকে যেখানে সংযোগটি প্রভিশন করা হয়। অন্য যেকোনো জায়গায় তা স্থানীয় ব্যতিক্রম, যা পরবর্তী নেটওয়ার্ক পরিবর্তনে মুছে যাবে।

ফোনটি যে পথগুলো সত্যিই ব্যবহার করে সেগুলোতে যাচাই করুন

ব্যক্তিগত নামটি দরকার এমন অ্যাপ থেকে নতুন অনুরোধ পরীক্ষা করুন — অফিসের Wi-Fi-তে, সেলুলারে এবং তাদের মধ্যকার রূপান্তরজুড়ে। নিজস্ব রিজলভার ইন্টিগ্রেশন থাকা অ্যাপ সিস্টেমের চেয়ে ভিন্ন পথ নিতে পারে, তাই আকস্মিকভাবে কাজ করা ব্রাউজার ট্যাব নয়, প্রকৃত অ্যাপটিই পরীক্ষা করুন।

ব্যক্তিগত নামটি ব্যর্থ হলে সঠিক ত্রুটি ও প্রোফাইল অবস্থা সংরক্ষণ করুন। নামটির অস্তিত্ব নেই বলে উত্তর দেওয়া একটি পাবলিক রিজলভার ভুল প্রশ্নের সঠিক উত্তর দেয়, আর কোম্পানির রিজলভারের পাশে সেটি যোগ করা নেমস্পেস ডিজাইন নয়।

সবশেষে, যাচাইকৃত নীতিটি প্রভিশনিং উৎসের সাথে সংরক্ষণ করুন। পরবর্তী পুনঃসংযোগ বা নিবন্ধন একই নেম সার্ভিস পুনরুদ্ধার করা উচিত কারণ প্রোফাইল তা বলেছিল, এই কারণে নয় যে কেউ দুই বছর আগে একটি হটস্পটে করা সম্পাদনা মনে রেখেছে।