stunnel-এর পেছনে OpenVPN: port 1194 নয়, মোড়কটি ফরওয়ার্ড করুন
দুটি লিসেনার, তিনটি পোর্ট। ফরওয়ার্ড কোথায় পৌঁছায়, মোড়ক কোথায় বাঁধা পড়ে, কোথায় সংযোগ করে, স্থানীয় পরীক্ষা কী বাদ দিয়েছে এবং দুই পরিচয় যাচাই করুন।
TLS মোড়ককে OpenVPN-এর সামনে রাখুন এবং ডিপ্লয়মেন্ট একটি দ্বিতীয় লিসেনার পায়, যার মধ্যে কেবল একটিকেই কখনও ইন্টারনেটের মুখোমুখি হওয়া উচিত। যখন টানেল একই মেশিন থেকে কাজ করে কিন্তু বাইরে থেকে ব্যর্থ হয়, তখন ফরওয়ার্ড সাধারণত দুটির মধ্যে ভুলটির দিকে লক্ষ্য করে থাকে। যা মিলতে হবে তা একটি শৃঙ্খল: পাবলিক নিয়ম মোড়কে পৌঁছায়, আর মোড়কের নিজস্ব ব্যাকএন্ড সংযোগ আসল VPN সকেটে পৌঁছায়। চারটি ধাপ এই শৃঙ্খল বহন করে, এবং তাদের যেকোনো একটি তদন্ত আগেভাগেই শেষ করতে পারে।
দুটি সকেট, দুই মালিক, একটি পাবলিক
মোড়ক বাইরের সংযোগের জন্য TLS সমাপ্ত করে এবং ডিক্রিপ্ট করা বাইট স্ট্রিম একটি সাধারণ OpenVPN TCP লিসেনারের কাছে পাঠায়। এগুলি আলাদা কনফিগারেশন ফাইলযুক্ত আলাদা সকেট, তাই একটি সম্পাদনা করলে অন্যটি অক্ষত ও আপাতদৃষ্টিতে সুস্থ থাকে। এর অর্থ এটাও যে একটি অন্যটি ছাড়া পরিবর্তিত হলে দুটি আলাদা হয়ে যেতে পারে।
তাই মেশিনটির নিজের থেকে কাজ করা পাবলিক পথ সম্পর্কে খুব কমই প্রমাণ করে। নেটিভ পোর্টে সরাসরি সংযোগ মোড়কটি বাদ দেয়, মোড়কের LAN ঠিকানায় সংযোগ অনুবাদ বাদ দেয়, আর কেবল সম্পূর্ণ ক্লায়েন্ট-পার্শ্ব ব্যবস্থাই বাইরের ব্যবহারকারী যা করেন তা অনুশীলন করে। নামগুলিও সাবধানে পড়তে হবে, কারণ localhost বলতে সেই নির্দিষ্ট কম্পোনেন্ট চালানো হোস্টকে বোঝায়, আপনি যে হোস্টে লেখালেখি করছেন তাকে নয়। এই পার্থক্যটি আপনার নোটে রাখুন, কারণ যে ধাপটি ঢেকে রেখেছে তা ছাড়া রেকর্ড করা পরীক্ষা দুই ভিন্ন জিনিসের তুলনা করতে আহ্বান করে।
ফরওয়ার্ড আসলে কোথায় পৌঁছায়
শৃঙ্খলটিকে তিনটি পোর্ট নম্বরের বদলে চারটি ধাপ হিসেবে ধরে রাখা সহজ, কারণ একই নম্বর দুই প্রান্তে ভিন্ন কিছু বোঝাতে পারে। টেবিলটি সারি ধরে পড়ুন: প্রতিটি সারি এমন একটি সকেট যা একটি সংযোগ গ্রহণ করে তারপর পরেরটি খুলতে হবে। যখন একটি সারি ভুল সহযোগীর দিকে লক্ষ্য করে, শেষ কলামের লক্ষণটিই ব্যবহারকারী রিপোর্ট করেন।
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
মোড়কের বদলে নেটিভ VPN পোর্টকে লক্ষ্য করা নিয়ম TLS সমাপ্তি সম্পূর্ণ বাদ দেয়, যা এই ভুলের সবচেয়ে সাধারণ রূপ: ক্লায়েন্ট এমন লিসেনারের সঙ্গে হ্যান্ডশেক খোলে যে OpenVPN ফ্রেমিং আশা করে, তাই সংযোগ খুলে গিয়ে আটকে যেতে পারে। স্মৃতির বদলে মোড়কের কনফিগারেশন ফাইলের সঙ্গে অনূদিত পোর্টটি নিশ্চিত করুন, কারণ ওই ফাইলটি পরেরবার সম্পাদনা করা ব্যক্তি ভিন্ন নম্বর বেছে নিতে পারেন। নিচের দুটি কমান্ড ওই প্রশ্নের দুই দিক একসঙ্গে দেখায়।
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'যে বাইন্ড ঠিকানা আপনাকে প্রত্যাখ্যান করে
127.0.0.1-এ বাঁধা accept লাইন কেবল হোস্টকেই উত্তর দেয়, তাই LAN ঠিকানায় আসা ফরওয়ার্ড সংযোগ করতে পারে না এবং ক্লায়েন্ট এমন প্রত্যাখ্যান দেখে যা প্যাকেট-ফিল্টার সমস্যার মতো শোনায়। ফায়ারওয়াল স্পর্শ করার আগে সকেটটি দেখুন, কারণ সকেটই সস্তা উত্তর। হয় মোড়কটিকে ফরওয়ার্ড যে ইন্টারফেস লক্ষ্য করে সেখানে বাঁধুন, নয়তো এটিকে loopback-এ রেখে দিন এবং ফরওয়ার্ড যেন সত্যিই কাজ করে এমন কিছুর মাধ্যমে loopback-এ পৌঁছায় তা করুন। এগুলি দুটি নকশা, এবং প্রত্যেকটির নিজস্ব নিয়ম দরকার।
এগুলিকে মেশানোই হলো একটি কার্যকর মোড়ক কীভাবে বাইরে থেকে অগম্য হয়ে পড়ে, অথচ প্রতিটি ফাইল সঠিক দেখায়। নিচের পরীক্ষাটি একটি কমান্ড, এবং এটি এমন প্রশ্নের উত্তর দেয় যা ফায়ারওয়াল নিয়মের পর্যালোচনা দিতে পারে না। যদি আউটপুট loopback ঠিকানা দেখায় অথচ ফরওয়ার্ড LAN ঠিকানাকে লক্ষ্য করে, তবে সমাধান accept লাইনে, প্যাকেট ফিল্টারে নয়।
ss -lntp '( sport = :8443 )'স্থানীয় পরীক্ষা আসলে কী প্রমাণ করল
যে ধাপটি ঢেকে রেখেছে তা ছাড়া রেকর্ড করা সফলতা অন্য ধাপ সম্পর্কে প্রমাণ নয়। পরীক্ষাটি কোন ঠিকানা ব্যবহার করেছে এবং কোন প্রক্রিয়া উত্তর দিয়েছে তা লিখে রাখুন। তারপর একই Wi-Fi-এর ফোন থেকে নয়, নেটওয়ার্কের বাইরে থেকে পুনরাবৃত্তি করুন, কারণ হেয়ারপিন আচরণ রাউটারভেদে ভিন্ন হয় এবং LAN কখনও না ছেড়ে যাওয়া সংযোগ ফরওয়ার্ড সম্পূর্ণ জড়িত না হয়েও একজন ক্লায়েন্টকে সন্তুষ্ট করতে পারে। কেবল দ্বিতীয় চেষ্টাটিই অপরিচিত ব্যক্তির নেওয়া পথটি পরীক্ষা করে।
চেষ্টা ব্যর্থ হলে, একটি সংযোগকে দুই লগজুড়ে অনুসরণ করুন: মোড়কের গৃহীত ও সংযুক্ত লাইন, তারপর VPN ডেমনের নিজস্ব সেশন লগ। যে প্রথম সীমানা কিছুই রেকর্ড করে না, পরের পরিবর্তন সেখানেই হওয়া উচিত। OpenVPN যখন পিয়ার অপশন তুলনা করতে শুরু করে, তখন ওই বার্তাগুলোকে সেই বাস্তবায়নের নিয়মে বিচার করুন। link-mtu অসঙ্গতির সতর্কতা স্বয়ংক্রিয়ভাবে মারাত্মক নয়, link-mtu-কে 1500-এ পিন করা ফ্র্যাগমেন্টেশন থেমেছে তা প্রমাণ করে না, এবং সাইফার আলোচনা রাউটারের ফরওয়ার্ডের নয়, ভেতরের OpenVPN কনফিগারেশনের।
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerএই প্রোবগুলি ব্যাকএন্ড সকেট ও মোড়ক লগ ঢেকে রাখে, যা প্রত্যাখ্যাত ব্যাকএন্ডকে প্রত্যাখ্যাত হ্যান্ডশেক থেকে আলাদা করে। এগুলি পরে নয়, একটি চেষ্টা চলাকালীন চালান। একই চেষ্টার টাইমস্ট্যাম্পই তুলনাকে বিশ্বাসযোগ্য করে।
দুটি পরিচয়, দুটি ব্যর্থতার ক্রম
বাইরের সার্টিফিকেট মোড়কের এবং ভেতরের পরিচয় OpenVPN-এর, এবং এগুলি ভিন্ন কর্তৃপক্ষ থেকে আসতে পারে। পথকে সুস্থ দেখাতে যেকোনো একটি পরীক্ষা নিষ্ক্রিয় করা বাস্তব সুরক্ষার বদলে নিছক দৃশ্যমান ফলাফল কেনে। উভয় যাচাই রাখুন এবং ক্রম অনুসারে ডিবাগ করুন, কারণ বার্তাগুলোর ক্রম স্তরটির নাম বলে: মোড়ক সার্টিফিকেটের সমস্যা যেকোনো VPN অপশন আলোচনার আগেই দেখা যায়, আর ভেতরের পরিচয়ের ব্যর্থতা কেবল স্ট্রিম প্রতিষ্ঠিত হওয়ার পরেই দেখা যায়।
stunnel ম্যানুয়াল accept, connect এবং ক্লায়েন্ট মোড সুনির্দিষ্টভাবে সংজ্ঞায়িত করে, এবং ওই বিভাগগুলি অনুমানের চেয়ে দ্রুত সকেটের প্রশ্নের উত্তর দেয়। আপনি যদি এখনও বুঝতে না পারেন কোন স্তর উত্তর দিয়েছে, নিচের কমান্ড দিয়ে পাবলিক পোর্ট যে সার্টিফিকেট উপস্থাপন করে তা পড়ুন। আউটপুটে মোড়কের সার্টিফিকেট থাকা মানে ফরওয়ার্ড মোড়কে পৌঁছেছে, আর নীরবতা বা প্রোটোকল ত্রুটি মানে পৌঁছায়নি। এই একক পার্থক্যই এখানকার অন্য যেকোনো পরীক্ষার চেয়ে বেশি সময় বাঁচায়।
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer