OpenVPN ও HTTPS 443 পোর্টে: লিসেনার কার?
TCP ও UDP 443 আলাদা সকেট। একটি TCP লিসেনার ভাগ করতে মালিক লাগে, আর OpenVPN-এর পোর্ট শেয়ারিং একটি সংকীর্ণ ব্যবস্থা, প্রক্সি কৌশল নয়।
দুটি সার্ভিস কখনও প্রতিযোগিতা না করেই 443 পোর্টে উত্তর দিতে পারে, কারণ লিসেনার শুধু নম্বরে নয়, ট্রান্সপোর্ট, ঠিকানা ও পোর্ট একসাথে দিয়ে নির্ধারিত হয়। একই মেশিনে একটি ওয়েব সার্ভার ও OpenVPN রাখুন, আর প্রথমে যেটির উত্তর দরকার সেটি হলো প্রতিটি প্রসেস কার্নেলের কাছে কোন সকেট চায়। কনফিগারেশন সম্পাদনার আগে সেই তালিকা লিখে রাখুন, তাহলে বেশিরভাগ অ্যাড্রেস-ইন-ইউজ ত্রুটি নিজেই ব্যাখ্যা হয়ে যাবে। তালিকার পরের সবকিছুই UDP লিসেনার, ভাগ করা TCP সকেট, বা প্রোটোকল অনুযায়ী রুট করা ফ্রন্ট এন্ডের মধ্যে একটি পছন্দ।
প্রতিটি প্রসেস যে সকেট চায় সেখান থেকেই শুরু করুন
বাইন্ড ওই ত্রয়ীর উপর সফল বা ব্যর্থ হয়, তাই দুটি ডেমন কেবল তখনই সংঘর্ষে আসে যখন তিনটি অংশই মিলে যায়। এজন্যই TCP 443-এ একটি ওয়েবসাইট UDP 443-এ OpenVPN লিসেনারের সাথে অনির্দিষ্টকাল সহাবস্থান করে, আর এজন্যই তাদের একটিকে একই হোস্টের দ্বিতীয় স্থানীয় ঠিকানায় সরালেও বিতর্ক শেষ হয়। জীবন্ত লিসেনারগুলো পড়ুন, যে ফাইলগুলো তাদের তৈরি করার কথা ছিল সেগুলো নয়, কারণ পুরোনো include বা ভুলে যাওয়া unit ফাইল আপনার মনে থাকা সম্পাদনার চেয়ে বেশি দিন টেকে।
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root হিসেবে ss -lntup চালান এবং 443 উল্লেখ করা প্রতিটি সারি পড়ুন, IPv6 এন্ট্রিসহ। সাধারণত একটি wildcard v6 লিসেনার v4 ট্রাফিকও গ্রহণ করে, আর এভাবেই ভুলে যাওয়া লিসেনারটি আপনার দায়ী মনে করা ফাইল বদলানোর পরেও পোর্ট দখলে রাখে। প্রসেসের নাম অবাক করলে কিছু স্পর্শ করার আগে ss -lntup 'sport = :443' দিয়ে আউটপুট সংকুচিত করুন।
নেটওয়ার্ক অনুমতি দিলে টানেল UDP-তে সরান
একটি UDP লিসেনার সংঘর্ষ সম্পূর্ণ এড়িয়ে যায় এবং সাধারণত সবচেয়ে ছোট সমাধান, কারণ কোনো সকেট ভাগ হয় না এবং পথে অতিরিক্ত কোনো পণ্য যোগ হয় না। তবে এটি বিনামূল্যে নয়। কিছু ক্লায়েন্ট নেটওয়ার্ক reset না পাঠিয়েই UDP 443 ফেলে দেয়, তাই টানেল বাইন্ডে ব্যর্থ হওয়ার বদলে প্রতিষ্ঠিত হওয়াই থেমে যায়, আর ব্যবহারকারী পড়ার মতো কোনো ত্রুটি ছাড়াই VPN বন্ধ বলে জানায়। UDP লিসেনার ওয়েব স্তরের রিস্টার্টও টিকে থাকে, যা ঘন ঘন সাইট পুনরায় স্থাপন করা মেশিনে গুরুত্বপূর্ণ। ব্যবহারকারীরা যে নেটওয়ার্কে বসে সেখান থেকেই পরীক্ষা করুন, কারণ সার্ভারে শেল কেবল প্রমাণ করে সার্ভার নিজেকে পৌঁছাতে পারে।
সার্ভার কনফিগারেশন ও ক্লায়েন্ট প্রোফাইলে ট্রান্সপোর্ট একসাথে বদলান। যে প্রোফাইল এখনও TCP চায় সেটি শুধু UDP লিসেনারের বিপরীতে পুনঃসংযোগের চক্রে ঘুরবে, আর দুটি ফাইল মিলিয়ে না দেখা পর্যন্ত তা নেটওয়ার্কের ত্রুটির মতো দেখায়।
VPN প্রসেসকে TCP 443-এর মালিক হতে দিন, বাকিটা ফরওয়ার্ড করুন
TCP সার্ভার মোডে Community OpenVPN আগত সংযোগের প্রথম বাইট পড়ে এবং নিজের প্রোটোকল নয় এমন সবকিছু HTTPS ব্যাকএন্ডে ফরওয়ার্ড করে, port-share নির্দেশিকাটি এজন্যই। ব্যাকএন্ড হলো TLS চালু থাকা একটি সাধারণ ওয়েব সার্ভার, যা ওই নির্দেশিকায় URL দিয়ে নয়, হোস্ট ও পোর্ট দিয়ে নামকৃত।
port-share 10.0.0.5 8080
যে মেশিনে সাইটের দ্বিতীয় একটি ব্যক্তিগত ঠিকানা আছে, সেখানে ওই লাইনটি নন-VPN ট্রাফিক 10.0.0.5:8080-এ পাঠায়, তাই HTTPS ভার্চুয়াল হোস্ট সেখানেই বাইন্ড থাকতে হবে এবং ফায়ারওয়ালকে স্থানীয় হপ অনুমোদন করতে হবে। ওয়েব সার্ভারকে নিজেই TLS সমাপ্ত করতে হবে, কারণ আগত বাইটগুলো ব্রাউজারের মূল হ্যান্ডশেক এবং মাঝখানে কিছুই সেগুলো ডিক্রিপ্ট করেনি। নির্দেশিকাটি সাধারণ HTTP লিসেনারের দিকে তাক করালে ব্রাউজার অবৈধ-পদ্ধতি ত্রুটি পায়, যা ভুল জায়গায় বসানো ব্যাকএন্ড নয়, ভাঙা সাইটের মতো পড়ায়। নির্দেশিকাটি কেবল TCP সার্ভার মোডেই আছে, আর UDP লিসেনারের পরীক্ষা করার মতো কোনো স্ট্রিম নেই।
VPN প্রসেস প্রতিটি সংযোগ গ্রহণ করে, তাই ওয়েব অ্যাপ্লিকেশন ফরওয়ার্ড করা অনুরোধটি দর্শকের কাছ থেকে নয়, হোস্টের নিজের একটি ঠিকানা থেকে আসতে দেখে। প্রকৃত ক্লায়েন্ট ঠিকানা দরকার এমন সবকিছু ব্যাকএন্ডে PROXY প্রোটোকল সমর্থন বা তা যোগ করা ফ্রন্ট এন্ডের উপর নির্ভর করে। ব্যাকএন্ডকে অন্য স্থানীয় ঠিকানায় সরালে দর্শকের ঠিকানা ফিরে আসে না; কেবল সাইট হোস্টের কোন ঠিকানাটি রেকর্ড করে তা বদলায়। বিশ্লেষণ প্রতিবেদন প্রশ্ন তোলার আগেই এই সীমাবদ্ধতা স্থাপনার নোটে লিখে রাখুন।
রিভার্স প্রক্সি ভুল হাতিয়ার; লেয়ার-ফোর রাউটার নয়
একটি HTTP রিভার্স প্রক্সি অনুরোধ পড়ার জন্য TLS সমাপ্ত করে, অর্থাৎ এটি OpenVPN স্ট্রিম অক্ষত অবস্থায় পার করতে পারে না। SNI বা প্রথম-প্যাকেট পরীক্ষা দিয়ে ফরওয়ার্ড করা লেয়ার-ফোর রাউটার দুটিরই সামনে থাকতে পারে, শর্ত হলো VPN যে সেশনের উপর নির্ভর করে তা এটি শেষ করবে না। দুটি ডিভাইস ডায়াগ্রামে একই রকম দেখায় আর সকেটে সম্পূর্ণ ভিন্ন আচরণ করে।
বাণিজ্যিক Access Server নিজস্ব পোর্ট-শেয়ারিং সেটিংস নিয়ে আসে, আর সেগুলো কমিউনিটি নির্দেশিকার সাথে এক-এক মেলে না। অন্য একটির জন্য লেখা গাইড মানিয়ে নেওয়ার আগে পণ্য ও সংস্করণ চিহ্নিত করুন। নীরবে উপেক্ষিত কপি করা সেটিং সেটিং না থাকার চেয়েও খারাপ, কারণ পরে লিসেনার তালিকা এখনও বিশ্বাসযোগ্য দেখায়।
ওয়েবসাইট ও টানেলকে দুটি আলাদা পথ হিসেবে পরীক্ষা করুন
সাইট লোড করুন ও টানেল সংযুক্ত করুন, তারপর আবার লিসেনার তালিকা পড়ে দেখুন এখন 443-এর মালিক কোন প্রসেস। লোড হওয়া পৃষ্ঠা VPN সম্পর্কে কিছু প্রমাণ করে না, আর সংযুক্ত হওয়া টানেল সাইট সম্পর্কে কিছু প্রমাণ করে না, যদিও দুটোই একই নম্বর ব্যবহার করে। নিচের তিনটি কমান্ড যথাক্রমে ভাগ করা সকেট, ওয়েব পথ ও VPN সার্ভিস পরীক্ষা করে।
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
একই মুহূর্তের জন্য ব্যাকএন্ড অ্যাক্সেস লগের ক্লায়েন্ট ঠিকানা ও VPN লগের ঠিকানা মিলিয়ে দেখুন। সাইট প্রতিটি দর্শককে হোস্ট নিজেই হিসেবে রেকর্ড করলে ফরওয়ার্ডিং কাজ করে, ঠিকানা হ্যান্ডলিং করে না। দুটি লগই নীরব থাকলে ফ্রন্ট এন্ড কখনও সংযোগটি হস্তান্তর করেনি। যেভাবেই হোক, লিসেনার তালিকাই ঠিক করে কে সকেট গ্রহণ করে, আর আরেকটি ফাইল বদলানোর আগে সেটাই নিশ্চিত করার বিষয়।
এই লিসেনার ম্যাপটি কনফিগারেশনের পাশে রেখে দিন, যাতে 443 স্পর্শ করা পরের ব্যক্তি জানেন কোন প্রসেস গ্রহণ করে এবং অন্য প্রোটোকল কোথায় গেছে। সম্পাদনা কী করার কথা ছিল তা বিশ্বাস না করে পরিবর্তনের পরে মালিকানা নিশ্চিত করুন।