আপনি ভাবেন VPN সার্ভার প্যাকেট থেকে আপনার ল্যাপটপের ঠিকানা পড়ে তা লগে লিখে রাখে। আসলে সে যা পড়ে তা হলো শেষ NAT হপ বাইরের হেডারে যা বসিয়েছে, আর টিথার করা ফোনে এটি প্রায়ই শত শত অন্য গ্রাহকের সঙ্গে ভাগ করা একটি ঠিকানা। আপনার মেশিনের নিজের 192.168.x.x কখনও সেই হেডারে ইন্টারনেট পার করে না, আর টানেলের ঠিকানা সার্ভার দেয় সংযোগ প্রতিষ্ঠার পরেই। তাই সার্ভার লগ আর ল্যাপটপের ip addr যখন মেলে না, তখন কোনোটিই ভুল নয়; তারা একই সেশনের আলাদা স্তর বর্ণনা করে।

তিনটি ঠিকানা, আর লগে আছে কেবল একটি

বিভ্রান্তি আসে তিনটি ঠিকানাকে একটিতে নামিয়ে আনার ফলে। প্রতিটির মালিক আলাদা, প্রতিটি আলাদা হেডারে থাকে এবং আলাদা পথে সার্ভারে পৌঁছায়।

AddressWho assigns itWhere it sitsVisible to the VPN server
Device address, e.g. 192.168.1.24Your router via DHCPOuter header, before translationNo, rewritten in place
Translated address and portRouter, ISP CGNAT, or bothOuter header, after translationYes, this is the tuple it logs
Tunnel address, e.g. 10.8.0.6The VPN server itselfInner header, after decapsulationYes, but it chose it

সংযোগের সময় কেবল মাঝের সারিটিই অজানা। সার্ভার এটি তার পিয়ার টেবিল, স্টেটাস ফাইল বা ফ্লো লগে লেখে ডেমন অনুযায়ী: WireGuard এটিকে এন্ডপয়েন্ট বলে, OpenVPN স্টেটাস ফাইল এটিকে Real Address নাম দেয়, আর strongSwan এটিকে IKE_SA-এর রিমোট হোস্ট হিসেবে জানায়। ভিন্ন উৎস থেকে প্যাকেট এলে সেই মান রিফ্রেশ হয়, তাই কেউ কিছু রিস্টার্ট না করেও এটি বদলে যায়।

নিচের সারিটি মানুষ ভুল করে পরিচয়ের দাবি হিসেবে পড়ে। এটি সার্ভার কনফিগারেশনের একটি স্লট চিহ্নিত করে, কোনো ব্যক্তি নয়, কারণ সার্ভার নিজের পুল থেকেই এটি বেছে নিয়েছে। দুই ব্যবহারকারী আলাদা দিনে একই টানেল ঠিকানা পেতে পারেন, আর একজন দুই ডিভাইস থেকে এমন দুটি ঠিকানা রাখতে পারেন।

টানেল চালু থাকা অবস্থায় লগ করা টাপল কেন বদলায়

ঠিকানা অনুবাদ একটি টাইমারযুক্ত টেবিল, স্থায়ী বাঁধন নয়। হোম রাউটার শেষ প্যাকেটের পর কিছুক্ষণ তার UDP ম্যাপিং ধরে রাখে, ক্যারিয়ার গেটওয়ে নিজের সূচি অনুযায়ী পোর্ট পুনর্ব্যবহার করে, আর Wi-Fi থেকে LTE-তে যাওয়া ফোন সম্পূর্ণ ভিন্ন উৎস নিয়ে ফিরে আসে। এখানে Linux conntrack-এর ডিফল্ট মান ভালো মাপকাঠি: nf_conntrack_udp_timeout হলো 30 সেকেন্ড আর স্ট্রিমিং ভ্যারিয়েন্ট 120, তাই ব্যবহারকারী টের পাওয়ার অনেক আগেই শান্ত টানেল তার ম্যাপিং হারাতে পারে।

টানেল টিকে থাকে কারণ প্রোটোকল ঠিকানার নয়, পিয়ারের প্রমাণীকরণ করে। হ্যান্ডশেকের পর WireGuard স্টেটলেস, তাই প্রমাণিত যেকোনো প্যাকেট সংরক্ষিত এন্ডপয়েন্ট আপডেট করে এবং পরের প্যাকেটেই রিবাইন্ড সেরে যায়; persistent-keepalive = 25 ঠিক এ কারণেই আছে, নিষ্ক্রিয় অবস্থায় ম্যাপিং গরম রাখতে। OpenVPN-এর --float একই কাজ করে, প্রমাণিত ক্লায়েন্টকে নতুন ঠিকানা ও পোর্ট থেকে আবার শুরু করতে দেয়। যেসব 2.4 ও 2.5 বিল্ডে float ডিফল্টে বন্ধ, সেখানে রিবাইন্ড সেশন রিসেট করে আর ক্লায়েন্ট আবার সংযোগ করে।

IPsec এখানে আরও বেশি চলমান অংশ নিয়ে পৌঁছায়। IKEv2 NAT ডিটেকশন পেলোডে উৎস ও গন্তব্যের হ্যাশ তুলনা করে অনুবাদ লক্ষ্য করে, UDP 4500 এনক্যাপসুলেশনে যায় এবং keepalive অনুসরণ করে নতুন টাপলে পৌঁছায়। keepalive ব্লক হলে SA কাগজে চালু থাকে, অথচ এক দিকের ট্রাফিক নিঃশব্দে থেমে যায়।

সার্ভার কী আরোপ করতে পারে, আর কী পারে না

যে মিথটা খাটা দরকার তা হলো, অনুবাদ আপনাকে অপারেটরের থেকে লুকায়। এটি লেবেল বদলায়, পর্যবেক্ষণ নয়। ক্যারিয়ার NAT-এর পেছনের গেটওয়ে 100.64.0.0/10 স্পেস বা বহু গ্রাহকের ভাগ করা একটি পাবলিক ঠিকানা দেখে, তবুও ফ্লোকে একটি সার্টিফিকেট সাবজেক্ট, একটি WireGuard পাবলিক কী, বরাদ্দ করা টানেল ঠিকানা, বাইট কাউন্টার আর একটি সময়-জানালার সঙ্গে বাঁধতে পারে। এর কোনোটিরই আপনার LAN ঠিকানা লাগে না।

সীমাবদ্ধতাগুলোও উল্টো দিকেই চলে। লগে থাকা ভাগ করা ঠিকানা একটি গেটওয়ের দিকে ইঙ্গিত করে, পরিবারের নয়; একই অনূদিত ঠিকানা থেকে আলাদা পোর্টে দুটি সেশন মানে দুটি আলাদা ডিভাইস; পোর্ট পুনর্ব্যবহৃত হলে দুই আলাদা দিনে একই ঠিকানা দুই সম্পর্কহীন গ্রাহক হতে পারে। যে সার্ভার কেবল পিয়ার কী লিখে রাখে সে অ্যাকাউন্ট ডেটাবেস ছাড়া কোনো কী-কে গ্রাহকের সঙ্গে মেলাতে পারে না, আর যে সার্ভার কেবল ঠিকানা লেখে সে একই রাউটারের পেছনের ল্যাপটপ আর ফোন আলাদা করতে পারে না।

অনুমান না করে দুই প্রান্ত মিলিয়ে দেখুন

কী ঘটেছে তা নিষ্পত্তি করতে একই সংযোগ দুই প্রান্তে একই মুহূর্তে ক্যাপচার করুন এবং ঠিকানা নয়, টাপল মিলিয়ে দেখুন। ক্লায়েন্টে, যেকোনো অনুবাদের আগে:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

তারপর রাউটার বা CGNAT গেটওয়েতে অনুবাদ এন্ট্রিটি পড়ুন, আর শেষে সার্ভারে কী পৌঁছায় তা দেখুন:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

তিনটি ধরন বেশিরভাগ অমিল ব্যাখ্যা করে। সার্ভারের উৎস পোর্ট স্থানীয় পোর্ট থেকে আলাদা অথচ গন্তব্য মেলে: সাধারণ পোর্ট অনুবাদ। সার্ভারের উৎস ঠিকানা এমন ISP ব্লকের যেটি আপনার নয়: অন্তত একটি অতিরিক্ত NAT স্তর। নিষ্ক্রিয়তার পর প্যাকেট থেমে নতুন পোর্টে ফেরে: ম্যাপিংয়ের মেয়াদ শেষ, রাউটিং ত্রুটি নয়। টাইমস্ট্যাম্প এক-দুই সেকেন্ডের বেশি আলাদা হলে আপনি দুটি ভিন্ন চেষ্টা তুলনা করছেন।

কোথায় পার্থক্য জিনিস ভাঙে

সার্ভার ত্রুটির মতো দেখানো বিভ্রাট সাধারণত এখানেই শুরু হয়। আপনার বাড়ির ঠিকানায় পিন করা অ্যাক্সেস নিয়ম ISP লিজ বদলালে ব্যর্থ হয়। অনূদিত ঠিকানার সঙ্গে মেলে এমন fail2ban নিয়ম একসঙ্গে ওই গেটওয়ের পেছনের সব গ্রাহককে নিষিদ্ধ করে। নির্দিষ্ট রিমোট ঠিকানাযুক্ত সাইট-টু-সাইট পিয়ার মোবাইল লিংক বদলালে কী রিনিউ করা বন্ধ করে। টানেল প্রোটোকল ঠিকই ছিল; বাইরের টাপল নিয়ে অনুমানটি নয়।

একই বিভ্রান্তি সার্ভার প্রান্তেও দেখা যায়। VPN বক্স নিজেই NAT-এর পেছনে থাকলে পোর্ট ফরওয়ার্ড আর কাজ করা ফরওয়ার্ডিং পথ দরকার; strongSwan ফরওয়ার্ডিং গাইড IPsec-এর জন্য ওই ক্ষেত্রটি কভার করে। শুধু একটি প্রাইভেট ঠিকানায় পৌঁছানো সার্ভার তার ক্লায়েন্টদের দেওয়া অনূদিত টাপল কখনও দেখে না, আর এটি ক্লায়েন্টদের অনূদিত হওয়ার চেয়ে আলাদা সমস্যা।

এই চারটি পরীক্ষা ক্রমে করুন এবং প্রথম যেটি ব্যর্থ হয় সেখানেই থামুন:

  • একই সময়ে দুই প্রান্তে ক্যাপচার করুন; উৎস পোর্ট, গন্তব্য পোর্ট আর টাইমস্ট্যাম্প মেলে কি না নিশ্চিত করুন।
  • আপনি যে ঠিকানা প্রত্যাশা করেছিলেন তা নয়, সার্ভার এখন যে ঠিকানাটি ধরে আছে তা পিয়ার তালিকায় পড়ুন।
  • এন্ট্রি আর তার অবশিষ্ট আয়ু conntrack বা NAT টেবিলে দেখুন।
  • ক্লায়েন্টের টানেল ইন্টারফেস ঠিকানা LAN ঠিকানা নয়, সার্ভার যা বরাদ্দ করেছে তার সঙ্গে মেলে কি না নিশ্চিত করুন।

দুই ক্যাপচার টাপলে একমত হলে আর টানেল তবুও ব্যর্থ হলে, অনুবাদ আপনার সমস্যা নয়; হ্যান্ডশেক আর টানেলের ভেতরের রাউটিং টেবিলে যান।

সম্পর্কিত নিবন্ধ