OpenVPN UDP-এর জন্য Nginx stream রিলে: কী বদলায়
UDP-এর জায়গা HTTP location-এ নয়। এটি stream স্তরে সরান, VPN-এর জন্য সেশনের সময়সীমা ঠিক করুন, এবং উৎস হিসেবে প্রক্সিকেই আশা করুন।
আপনার ক্লায়েন্ট UDP-তে সেট, Nginx সার্ভারে VPN পোর্টের দিকে নির্দেশ করা একটি location ব্লক আছে, কিন্তু কিছুই আসে না। এটি প্রত্যাশিত: HTTP location কোনো UDP ডেটাগ্রাম বহন করতে পারে না, সামনের অংশকে যাই নামেই ডাকা হোক। এর জন্য Nginx-এর একটি stream লিসেনার দরকার, এবং কনফিগারেশন সেখানে সরানোর পর সেশন টিকে থাকবে কি না তা ঠিক করে দ্বিতীয় কিছু বিবরণ।
ঠিকানার আগে আসে প্রক্সি স্তর
Nginx-এর stream মডিউল HTTP পার্স না করেই TCP ও UDP প্রক্সি করে। এর HTTP মডিউল একটি রিকোয়েস্ট লাইন, হেডার আর রেসপন্স আশা করে, যার কোনোটিই নেটিভ OpenVPN ডেটাগ্রামে থাকে না। তাই স্তর বাছাই করাই প্রথম সিদ্ধান্ত, এবং লিসেনার IPv4 না IPv6 তা নিয়ে এটি নির্ভর করে না।
TCP OpenVPN-এর সঙ্গে কাজ করে বলে মনে হয় এমন কনফিগারেশন UDP-র ক্ষেত্রে কিছুই বলে না। এখানে পরিবহন প্রোটোকলের অংশ, ডিপ্লয়মেন্টের কোনো খুঁটিনাটি নয়।
লিসেনার ও ব্যাকএন্ড
nginx -V 2>&1 | tr ' ' '\n' | grep stream
stream {
server {
listen [::]:1194 udp reuseport;
proxy_pass [2001:db8::20]:1194;
}
}
কিছু সম্পাদনার আগে নিশ্চিত হোন বিল্ডে stream মডিউল আছে; ডিস্ট্রিবিউশন প্যাকেজ এটি আলাদা মডিউলে ভাগ করতে পারে, আর মডিউল না থাকলে টানেল নয়, কনফিগারেশন ত্রুটি হয়। ব্লকটি মূল কনফিগারেশন কনটেক্সটে রাখুন, http-এর ভিতরে নয়, এবং ডকুমেন্টেশন ঠিকানাটি আসল ব্যাকএন্ড দিয়ে বদলান।
দুই রুট আর দুই ফায়ারওয়ালকেই ডেটাগ্রাম অনুমোদন করতে হবে: লিসেনার পর্যন্ত পথ এবং প্রক্সি থেকে ব্যাকএন্ড পর্যন্ত পথ। IPv6 লিসেনার IPv4 পথও তৈরি করে না, তাই কিছু ক্লায়েন্ট এখনো IPv4 ব্যবহার করলে সেই লিসেনার তার নিজস্ব পরীক্ষাসহ আলাদা এন্ট্রি। ব্যাকএন্ডের নিজের ফায়ারওয়াল প্রক্সির ঠিকানা থেকে যাচাই করুন, ল্যাপটপ থেকে নয়।
সেশন টাইমআউট আর রিকোয়েস্ট টাইমআউট এক নয়
stream প্রক্সি UDP সেশনের অবস্থা রাখে এবং নিজের টাইমআউট ও রেসপন্স সেটিং অনুযায়ী তা ফেলে দেয়। DNS রিলে থেকে কপি করা ছোট টাইমআউট ঘণ্টার পর ঘণ্টা ডেটাগ্রাম বিনিময়ের আশা করা VPN-এর জন্য খারাপ মানায়, আর ব্যর্থতাটা চুপচাপ মরে যাওয়া সংযোগ হিসেবে দেখা যায়, শুরু করতে অস্বীকার করা সংযোগ হিসেবে নয়।
ডিপ্লয়মেন্টের কার্যকর proxy_timeout এবং রেসপন্স-গণনার যেকোনো সেটিং পড়ুন, তারপর VPN আসলে যে keepalive আচরণ ব্যবহার করে তার সঙ্গে মিলিয়ে দেখুন। আলাদা মানুষ আলাদা ফাইলে লেখা দুটি সংখ্যা একটি সচল সিস্টেমের স্বাভাবিক অবস্থা। কখনো তুলনা না করা দুটি সংখ্যা একটি থেমে-থেমে চলা সিস্টেমের স্বাভাবিক অবস্থা। দুটোই সার্ভিস রেকর্ডে লিখুন, যাতে তুলনাটা একবারই হয়, দিনের আলোয়।
রিলে কী বদলায়, আর কী বদলায় না
stream প্রক্সি OpenVPN-এর TLS কন্ট্রোল চ্যানেল বন্ধ করে না বা সেটিকে HTTPS-এ বদলায় না। ব্যাকএন্ডই VPN সার্ভিস থাকে, আর সার্টিফিকেটের সম্পর্ক ক্লায়েন্ট ও সেই সার্ভিসের মধ্যেই থাকে। কাঙ্ক্ষিত ব্যাকএন্ড পরিচয় রক্ষা করা এখনো ক্লায়েন্ট ও সার্ভারের কাজ।
সাধারণ প্রক্সিং ব্যাকএন্ড যে উৎস ঠিকানা দেখে সেটিও বদলায়। লগে প্রক্সি দেখাবে, আর VPN সার্ভারে IP-ভিত্তিক যেকোনো অ্যাক্সেস নিয়ম ক্লায়েন্টের নয়, ওই ঠিকানার মূল্যায়ন করবে। স্বচ্ছ উৎস সংরক্ষণ আলাদা রাউটিং ও বিশেষাধিকার নকশা, লিসেনারে udp যোগ করলেই যা আসে তা নয়। ক্লায়েন্ট ঠিকানার ওপর নির্ভর করা কোনো নীতি লেখার আগেই এর পরিকল্পনা করুন।
পোর্ট থেকে নয়, ক্লায়েন্ট থেকে যাচাই করুন
UDP পোর্ট খোলা আছে—এই স্থানীয় পরীক্ষা প্রমাণ করে লিসেনার আছে। এটি প্রমাণ করে না যে কোনো ক্লায়েন্ট এর মধ্য দিয়ে প্রমাণীকরণ করতে পারে বা ট্রাফিক বিনিময় চালিয়ে যেতে পারে। অনুমোদিত ক্লায়েন্ট থেকে সত্যিকারের সংযোগ সম্পন্ন করুন, তারপর নিশ্চিত করুন সেশন যথেষ্ট সময় টিকে থাকে।
কেউ যখন বলেন Nginx UDP করতে পারে না কারণ এর বদলে একটি সরল রিলে টুল কাজ করেছে, দুটি তথ্য পরস্পর সম্পর্কহীন। টুলটি প্রমাণ করেছে ব্যাকএন্ড উত্তর দেয়; সামনের অংশ কী সমর্থন করে তা নিয়ে এটি কিছু বলেনি। দুটোই সত্যি হতে পারে, এবং এদের একটিই এই ডিপ্লয়মেন্টের কনফিগারেশন।