HTTP প্রক্সির মাধ্যমে OpenVPN: আগে CONNECT উত্তরটি পড়ুন
CONNECT প্রক্সি বাইট রিলে করে, তাই দুই প্রান্তেই TCP দরকার। সার্টিফিকেটকে দোষ দেওয়ার আগে 407, 403 ও 503 পড়ুন, আর সার্ভার যাচাই চালু রাখুন।
একটি VPN ক্লায়েন্টকে কর্পোরেট HTTP প্রক্সিতে নির্দেশ করুন, আর প্রথম কাজের তথ্য হলো প্রক্সি VPN-এর প্রোটোকল বলে না। এটি আপনার বলা ঠিকানায় একটি সাধারণ TCP সংযোগ খোলে এবং তারপর সরে যায়, আপনার ক্লায়েন্ট ও সার্ভারকে সেই স্ট্রিমের মধ্য দিয়ে নিজেদের বিনিময় চালাতে দেয়। ক্লায়েন্টের যা কিছু দরকার, পরিবহনের ধরন থেকে সার্ভারের শ্রোতা পর্যন্ত, সেই বিন্যাসের সঙ্গে মিলতে হবে। দুটি অমিল বেশিরভাগ ব্যর্থতার কারণ: CONNECT প্রক্সির দিকে লক্ষ্য করা UDP প্রোফাইল, এবং VPN ত্রুটি ভেবে ভুল বোঝা প্রক্সি উত্তর।
প্রক্সি কী বহন করে, আর কী করে না
প্রক্সি কেবল একটি পরিবহন ধাপ। এটি আপনার ব্রাউজার প্রক্সি হয়ে ওঠে না, টানেলের মধ্য দিয়ে আপনি যে সাইট দেখেন তা ক্যাশ করে না, এবং কেউ সচেতনভাবে পরিদর্শন কনফিগার না করলে ভেতরের ট্রাফিক দেখে না। এটি যে টানেল খোলে, তা নকশা অনুসারেই এর কাছে অস্বচ্ছ।
এর মানে এইও যে, যে সার্ভারের মিলে যাওয়া শ্রোতা নেই প্রক্সি তা ঠিক করতে পারে না। কোনো গন্তব্যে পৌঁছানোর অনুমতি আর সেই গন্তব্যে শোনা কোনো সেবা আলাদা দুটি তথ্য, এবং প্রথমটি কেবল প্রক্সি প্রশাসকের।
বাহককে দুই প্রান্তেই TCP হতে হবে
প্রচলিত CONNECT প্রক্সি কেবল বাইট স্ট্রিম রিলে করে , তাই ক্লায়েন্টকে স্ট্রিম পরিবহন ব্যবহার করতে হবে। ওই ক্ষেত্রে ক্লায়েন্ট ফ্র্যাগমেন্ট এমন দেখায়:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128সার্ভার পক্ষের remote লাইনে বলা পোর্টে একটি আসল TCP শ্রোতা দরকার। প্রোফাইলে proto udp কে proto tcp-client এ বদলালে এমন ক্লায়েন্ট তৈরি হয় যে স্ট্রিম প্রত্যাশা করে; এটি অপর প্রান্তে স্ট্রিম তৈরি করে না। একই সার্ভার ওই পোর্টে UDP-তেও উত্তর দিলে সেটি আলাদা শ্রোতা, একই শ্রোতার দ্বিতীয় মোড নয়।
যেখানে আলাদা TCP ইনস্ট্যান্স আছে, তার টানেল ডিভাইস, ঠিকানা পুল ও রাউটিং নিজস্ব সম্পদ। একটি কাজ করা কনফিগারেশন কপি করে পরিবহনের শব্দ বদলালে সেই সম্পদগুলো মূল ইনস্ট্যান্সের দিকেই থাকে, ফলে এমন সংযোগ তৈরি হয় যা প্রমাণীকরণ করে কিন্তু পরে কিছুই রাউট করে না।
VPN ফলাফলের আগে প্রক্সি উত্তর পড়ুন
ক্লায়েন্টের প্রথম বিনিময় হলো গন্তব্যের হোস্ট ও পোর্ট বলা একটি অনুরোধ লাইন। সেই লাইনের উত্তর আপনাকে বলে আদৌ কোনো বাইট স্ট্রিম আছে কি না, আর তা কোনো সার্টিফিকেট বা ক্রেডেনশিয়াল যাচাইয়ের আগেই আসে:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT-এ 200 শ্রেণির উত্তর মানে স্ট্রিম আছে। গেটওয়ে সার্টিফিকেট বিশ্বস্ত কি না, শেয়ার্ড কী মেলে কি না, বা ব্যবহারকারীর অ্যাকাউন্ট বৈধ কি না—এসবের কিছুই এটি বলে না। ওই যাচাইগুলো পরে, স্ট্রিমের ভেতরে ঘটে, আর সেগুলো HTTP স্ট্যাটাস লাইনের বদলে ক্লায়েন্টের নিজের বার্তা দিয়ে ব্যর্থ হয়। প্রথম OpenVPN ঘটনাটির জন্য প্রক্সি হ্যান্ডশেকের পরে ক্লায়েন্ট লগ পড়ুন, উইন্ডো বন্ধের আগের শেষ লাইনটি নয়।
প্রক্সি ক্রেডেনশিয়াল আর VPN ক্রেডেনশিয়াল প্রায়ই ভিন্ন দল রাখা ভিন্ন পরিচয়। 407 মানে VPN অ্যাকাউন্টের খারাপ পাসওয়ার্ড নয়, আর প্রত্যাখ্যাত সার্টিফিকেট মানে প্রক্সির অনুমতি সমস্যা নয়।
CONNECT কী প্রকাশ করে না
স্পষ্ট CONNECT টানেল মানে আটকানো নয়। প্রক্সি বাইট এগিয়ে পাঠায় এবং VPN-এর TLS সেশন শেষ করে না, তাই সার্ভার সার্টিফিকেটের প্রতি ক্লায়েন্টের যাচাই অর্থবহ থাকে এবং চালু থাকা উচিত। প্রক্সি পেরোতে যাচাই বন্ধ করা আপনার সমস্যার চেয়ে ভিন্ন সমস্যার সমাধান।
আলাদা ব্যবস্থাও আছে যেখানে কোনো প্রতিষ্ঠান সচেতনভাবে TLS শেষ করে পরিদর্শন করে। সেগুলোর নিজস্ব বিশ্বাস কনফিগারেশন ও নিজস্ব নীতি সিদ্ধান্ত দরকার, আর সাধারণ http-proxy লাইন যা চায় তা এগুলো নয়।
TCP-এর ভেতরে TCP-এর দাম
টানেল TCP-র উপর বহন করলে বাইরের স্ট্রিম ক্রমে সাজানো ও পুনঃপ্রেরিত থাকে, আর ভেতরের ট্রাফিকও সাধারণত TCP। দুটি পুনরুদ্ধার ব্যবস্থা সমন্বয় করে না, তাই একটি হারানো সেগমেন্ট ওই বাইরের স্ট্রিম ভাগ করা সবকিছুকে পুনঃপ্রেরণ পর্যন্ত থামিয়ে দিতে পারে। এটি সামঞ্জস্যের জন্য সত্যিকারের বিনিময়, বিনামূল্যের উন্নয়ন নয়।
নেটওয়ার্ক কোনো বিকল্প না রাখলে প্রক্সি পথ ব্যবহার করুন, আর নীতি অনুমতি দিলে সরাসরি UDP পথ পছন্দ করুন। যেভাবেই হোক, পরিবর্তনের পরে একই প্রক্সি, গন্তব্য ও প্রোফাইল পরবর্তী ধাপে পৌঁছায় কি না নিশ্চিত করুন; ওই ঠিকানায় পৃষ্ঠা লোড করা ব্রাউজার ভিন্ন প্রোটোকল চালায় এবং টানেল সম্পর্কে কিছুই প্রমাণ করে না।