অ্যাপল VPN প্রোফাইলের Proxy ক্ষেত্রটি আসলে কী করে
প্রক্সি ক্ষেত্র পূরণ করলে VPN কখনো HTTP হয়ে যায় না। এখানে দুটি সংযোগ জড়িত, আর ক্ষেত্রটি তাদের একটিতেই পৌঁছায়।
অ্যাপল VPN কনফিগারেশনের Proxy ক্ষেত্র পূরণ করলে মনে হয় এটি টানেলটিকে একটি ওয়েব পোর্ট দিয়ে ঘুরিয়ে নেবে। কিন্তু তা করে না। ক্ষেত্রটি এমন ট্র্যাফিকের জন্য অ্যাপ্লিকেশন-স্তরের একটি মধ্যস্থতাকারী বেছে নেয় যা একটি উপযুক্ত অ্যাপ সেখানে পাঠাতে চায়। আর VPN ক্লায়েন্টের নিজের গেটওয়ের সঙ্গে সংযোগ নিয়ন্ত্রিত হয় আপনি যে প্রোটোকল, লিসেনার ও ট্রান্সপোর্ট কনফিগার করেছেন তা দিয়ে, এবং এগুলো আলাদা সিদ্ধান্ত।
দুটি সংযোগ, দুজন মালিক
এমন যেকোনো ব্যবস্থায় ক্লায়েন্ট-থেকে-গেটওয়ে সংযোগ এবং অ্যাপ্লিকেশন-থেকে-গন্তব্য সংযোগ থাকে। Proxy অংশটি দ্বিতীয়টির কথা বলে, যদিও এটি প্রথমটির মতো একই প্রোফাইলে বসে আছে।
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
অ্যাপলের প্রক্সি সেটিংসের রেফারেন্সে HTTP, HTTPS, SOCKS এবং স্বয়ংক্রিয় প্রক্সি কনফিগারেশন তালিকাভুক্ত করা হয়েছে, যা অ্যাপ্লিকেশন প্রক্সি বিকল্পের বর্ণনা। ওই কোনো এন্ট্রিই বলে না কীভাবে একটি IPsec বা WireGuard প্যাকেট গেটওয়েতে পৌঁছায়।
এই বিষয়টি নিষ্পত্তি করার একটি দ্রুত পরীক্ষা আছে। VPN ক্লায়েন্ট তার লগে যে পোর্ট ও প্রোটোকল জানায় তা বলুন। যদি সেই লাইনটি এখনও UDP 500 বা UDP 51820 বলে, তবে প্রক্সি ক্ষেত্রটি সেটিতে কিছুই বদলায়নি।
কখন ক্ষেত্রটি সঠিক হাতিয়ার
সত্যিই এমন একটি ক্ষেত্রে আছে যেখানে প্রক্সি টানেলের সামনে বসে, তবে এটি প্রোফাইল ক্ষেত্র নয়, ক্লায়েন্টের বৈশিষ্ট্য. OpenVPN-এর ম্যানুয়ালে HTTP CONNECT প্রক্সির মাধ্যমে বহন করা TCP সংযোগের জন্য --http-proxy নথিভুক্ত আছে। এটি ব্যবহারে দরকার মিলে যাওয়া ক্লায়েন্ট অপশন, ওইভাবে পৌঁছানো যায় এমন গেটওয়ে, এবং যে প্রক্সি ব্যবহৃত পোর্টে CONNECT অনুমোদন করে।
আপনার ক্লায়েন্ট যদি ওই অপশন দেয় এবং নেটওয়ার্ক পোর্টে CONNECT অনুমোদন করে, তবে এটি কাজ করতে পারে। ক্লায়েন্ট যদি তা না দেয়, তবে সিস্টেম প্রক্সি পূরণ করলে টানেলে কোনো প্রভাবই পড়ে না।
কখন এটি কিছুই বদলায় না
প্রক্সি ক্ষেত্র পূরণ করার কারণে একটি IKEv2 বা IPsec প্রোফাইল HTTP টানেলে পরিণত হয় না। WireGuard-ও হয় না, যার কনফিগারেশন ফরম্যাটে প্রক্সির কোনো ধারণা নেই। গেটওয়ে পোর্ট বদলালে এর প্রোটোকলও বদলায় না। আর সাধারণ HTTPS-এ সাড়া দেওয়া একটি এন্ডপয়েন্ট স্বয়ংক্রিয়ভাবে VPN লিসেনার নয়।
একই ফাঁদে পড়েন যারা পুরোনো iPad গাইড থেকে PPTP যুগের প্রোফাইল কপি করেন। অপশনগুলো ইন্টারফেসে এখনও আছে; কিন্তু তাদের পেছনের পরিষেবা আর ওই প্রোটোকল বলে না।
কোন স্তর ঠিক করবেন তা ঠিক করা
কিছু বদলানোর আগে জিজ্ঞাসা করুন কোন স্তর ব্যর্থ হয়েছে। ক্লায়েন্ট যদি সেশন প্রতিষ্ঠা করতে না পারে, তবে সমস্যা ট্রান্সপোর্টে এবং প্রক্সি ক্ষেত্রটি অপ্রাসঙ্গিক। টানেল চালু কিন্তু একটি অ্যাপ তার সার্ভারে পৌঁছাতে পারছে না, তবে অ্যাপ্লিকেশন প্রক্সি দেখা উচিত। টানেল চালু এবং প্রতিটি অ্যাপ ব্যর্থ হলে টানেলের ভেতরের রাউটিং ও DNS সন্দেহভাজন।
প্রথম ক্ষেত্রে অপারেটরকে জিজ্ঞাসা করুন কোন অনুমোদিত বিকল্প ট্রান্সপোর্ট বা নেটওয়ার্ক তারা সমর্থন করেন। TCP 443-এর উপর OpenVPN আছে কারণ কিছু নেটওয়ার্ক কেবল সেটিই অনুমোদন করে, আর এটি এখনও দরকার যে সার্ভার সেটির জন্য শুনছে।
অবরুদ্ধ UDP পোর্টকে তাৎক্ষণিক উদ্ভাবনের অনুমতি ভাববেন না। হ্যান্ডশেক মিলিয়ে নেওয়ার জন্য গেটওয়ে সার্টিফিকেট বা পরিচয় যাচাই বন্ধ না করে তা অটুট রাখুন।
দুটি স্তর একবারে একটি করে যাচাই করুন
প্রথমে টানেল নিশ্চিত করুন: ক্লায়েন্টের স্টেটাস পেজে প্রতিষ্ঠিত সেশন এবং শূন্য নয় এমন বাইট সংখ্যা দেখুন। তারপর প্রক্সি সেটিং সরাসরি পড়ুন, কার্যকর কনফিগারেশনের জন্য scutil --proxy এবং সংরক্ষিত মানের জন্য networksetup -getwebproxy Wi-Fi দিয়ে। তারপর একটি অ্যাপ পরীক্ষা করুন যা সিস্টেম প্রক্সি মানে এবং একটি যা তা উপেক্ষা করে, কারণ অনেক নেটিভ অ্যাপ এটি উপেক্ষা করে।
তিনটি ফলাফল, তিনটি ভিন্ন সমাধান।
দুটি স্তরই সফলতা জানালে এবং অ্যাপটি তবুও ব্যর্থ হলে স্প্লিট টানেলিং, DNS এবং অ্যাপের নিজস্ব নেটওয়ার্ক সেটিংস দেখুন। এটি তৃতীয় স্তর, এবং সেটিও প্রক্সি ক্ষেত্র নয়।