VPN ঠিকানা বনাম LAN DHCP লিজ: টানেল IP কে দেয়?
আপনার VPN ক্লায়েন্ট এমন ঠিকানা দেখায় যা LAN লিজ ফাইলে কখনও আসে না। প্রকৃত বরাদ্দকারী খুঁজতে ক্লায়েন্ট, IKEv2 পেলোড ও গেটওয়ে পুল পড়ুন।
ক্লায়েন্ট সংযোগ করুন এবং Wi-Fi আইকনের বদলে অ্যাডাপ্টরটি দেখুন। যেমন 10.80.0.14 ধরনের ঠিকানা একটি টানেলে থাকতে পারে, অথচ অফিস LAN-এর কোনো DHCP সার্ভার সেই লিজ কখনও নথিভুক্ত করেনি। কোন প্রক্রিয়া নম্বরটি বেছেছে, সেটাই ঠিক করে সমস্যা অনুসন্ধান কোথা থেকে শুরু হবে।
ক্লায়েন্টে সবকিছু একই দেখায়: একটি IPv4 ঠিকানা, একটি মাস্ক, মাঝে মাঝে একটি ডিফল্ট গেটওয়ে। পার্থক্য বোঝা যায় তখনই, যখন আপনি জিজ্ঞাসা করেন ওই ঠিকানার জন্য কে উত্তর দেয় এবং কে তার রেকর্ড রাখে।
ক্লায়েন্টের দিক থেকে টানেল ঠিকানা পড়ুন
পুরো ব্লকটি পড়লে Windows পার্থক্যটি দেখায়, প্রথম লাইনটি নয়। ipconfig /all অ্যাডাপ্টরের বিবরণ, ভৌত ঠিকানা এবং একটি DHCP লাইন ছাপে। PPP বা IKEv2 ডায়াল-আপ অ্যাডাপ্টর সাধারণত DHCP নিষ্ক্রিয় বলে জানায়, কারণ সংযোগটি LAN সার্ভার থেকে লিজ নেওয়ার বদলে ডায়াল-আপের সময়ই তার ঠিকানা নিয়ে দরকষাকষি করেছে। DHCP চালু থাকা টানেল অ্যাডাপ্টর অস্বাভাবিক এবং আলাদাভাবে তদন্তের যোগ্য।
Linux একই তথ্য দুটি সরঞ্জামে ভাগ করে। ip -4 addr show dev tun0 ঠিকানা ও প্রিফিক্সের দৈর্ঘ্য দেয়। nmcli -f IP4 connection show work প্রকাশ করে মানটি সংযোগ প্রোফাইল থেকে, লিঙ্কে DHCP বিনিময় থেকে, না ঠেলে দেওয়া কনফিগারেশন থেকে এসেছে। WireGuard সবচেয়ে পরিষ্কার উদাহরণ, কারণ ইন্টারফেস দেখা গেলে wg-quick কনফিগ ফাইলের Address লাইনটি প্রয়োগ করে, আর সংযোগের সময় কোনো পিয়ার কিছু বরাদ্দ করে না।
প্রিফিক্সও কিছু বলে। /32, বা 255.255.255.255 মাস্ক, বোঝায় গেটওয়ে একটি হোস্ট ঠিকানায় রুট করতে চায়, আর চওড়া মাস্ক টানেলের পেছনে কোথাও একটি অন-লিঙ্ক সাবনেটের ইঙ্গিত দেয়।
IKEv2 কনফিগারেশন পেলোড কী বহন করে
এই কাজের জন্য IKEv2-এর নিজস্ব ব্যবস্থা আছে। RFC 7296, অনুচ্ছেদ 3.15.1-এ বর্ণিত কনফিগারেশন পেলোড INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS এবং তাদের IPv6 সমতুল্য বৈশিষ্ট্য বহন করে। পছন্দ না থাকলে ক্লায়েন্ট শূন্য দৈর্ঘ্যের মানসহ বৈশিষ্ট্য পাঠায়, আর উত্তরদাতা যে মান ব্যবহার করতে চায় তা ফেরত দেয়। ওই বিনিময় ইতিমধ্যে এনক্রিপ্টেড IKE_AUTH-এর ভেতরে চলে, তাই কোনো DHCP সম্প্রচার কখনও টানেল পার হয় না।
দুটি পরিণতি আসে। প্রথমত, ঠিকানাটি বেছে নেয় উত্তরদাতা বা সে যে অনুমোদন ব্যাকএন্ডের সঙ্গে পরামর্শ করে, তাই পুলটি গেটওয়েতে, RADIUS উত্তরে বা পরিচয় প্রদানকারীর ম্যাপিংয়ে থাকতে পারে। দ্বিতীয়ত, DNS বৈশিষ্ট্যটি ঠিকানা বৈশিষ্ট্য থেকে আলাদা। 10.80.0.14 পেলে কোন রিজলভার ফিরেছে বা আদৌ ফিরেছে কি না, তা কিছুই বোঝা যায় না।
নেটমাস্ক বৈশিষ্ট্যটি বাস্তবে ঐচ্ছিক। অনেক স্থাপনা কেবল একটি ঠিকানা ফেরত দেয় এবং ক্লায়েন্টকে হোস্ট রুট বসাতে দেয়, তাই একই পুল এক ক্লায়েন্টে /32 এবং অন্যটিতে /24 দেখাতে পারে।
যেখানে LAN DHCP স্কোপ ও VPN পুল সংঘর্ষে পড়ে
সমস্যা শুরু হয় যখন দুই বরাদ্দকারীই একই রেঞ্জের দিকে তাক করে। 10.20.30.0/24 নেটওয়ার্কের DHCP সার্ভার 10.20.30.128/25 নেটওয়ার্কের জন্য তৈরি VPN পুল সম্পর্কে কিছুই জানে না, তাই গেটওয়ে একই ঠিকানা দূরবর্তী ক্লায়েন্টকে দেওয়ার সময় ওই সার্ভারকে প্রিন্টারকে 10.20.30.140 লিজ দিতে কিছুই বাধা দেয় না। সংঘর্ষ দিনের পর দিন নীরব থাকে, পরে মাঝে মাঝে ডুপ্লিকেট হিসেবে প্রকাশ পায়।
রাউটেড সাইট-টু-সাইট নকশা গঠনগতভাবেই সংঘর্ষ এড়ায়। শাখার হোস্ট স্থানীয় DHCP সার্ভার যে ঠিকানা দিয়েছে তা ধরে রাখে। দুই গেটওয়ের টানেল ইন্টারফেস নিজেদের লিঙ্ক ঠিকানা বহন করে, আর প্যাকেট কীভাবে যাবে তা রাউটিং টেবিল ঠিক করে। রিমোট-অ্যাক্সেস ক্লায়েন্টের ঠিকানা তৃতীয় শ্রেণি এবং গেটওয়ের লিঙ্ক ঠিকানার সঙ্গে মেশানো উচিত নয়।
টানেলকে LAN-এ ব্রিজ করলে সেই বিচ্ছিন্নতা দূর হয়। নকশার সত্যিই একটি ব্রডকাস্ট ডোমেইন দরকার হলে, VPN এন্ডপয়েন্টকে নিজে ঠিকানা জারি করার বদলে রিলে বা যৌথ কর্তৃত্বপূর্ণ উৎসের মাধ্যমে DHCP সার্ভারের মতো একই বরাদ্দ সিদ্ধান্তে অংশ নিতে হবে।
ঠিকানার মালিকানা কোন প্রক্রিয়ার, তা যাচাই করুন
স্কোপ বদলানোর আগে মালিকানা প্রমাণ করুন। ক্লায়েন্টে ঠিকানা ও প্রিফিক্স লিখে নিন। LAN-এ লিজ ডেটাবেসে খুঁজুন। গেটওয়েতে যে পুলগুলো দেওয়ার জন্য কনফিগার করা আছে তা তালিকাভুক্ত করুন। লিজ ফাইলে পাওয়া ঠিকানা DHCP সার্ভারের, অর্থাৎ টানেলটি ব্রিজড বা রিলে করা; কেবল গেটওয়ে পুলে পাওয়া ঠিকানা টানেল এন্ডপয়েন্টের।
# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0
# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases
# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools
উত্তর পরিষ্কার হলে চারটি জিনিস লিখুন: কোন উপাদান ক্লায়েন্ট ঠিকানা বরাদ্দ করে, তার জন্য কোন রেঞ্জ সংরক্ষিত, ফেরত ট্রাফিক কীভাবে ওই রেঞ্জে পৌঁছায় এবং কোন সম্পদ তা গ্রহণ করে। এই চারটি এন্ট্রি ভার্চুয়াল অ্যাডাপ্টরের একটি লাইনকে পরিচালনগত তথ্যে বদলে দেয়।
সেখানে থেকেই DNS বৈশিষ্ট্যের জন্যও পরীক্ষাটি আবার করুন। যে পুল ঠিকানা দেয় কিন্তু রিজলভার দেয় না, তা ক্লায়েন্টকে তার স্থানীয় DNS-এ রেখে যায়, আর এটি এমন পুলের চেয়ে ভিন্ন ব্যর্থতা যা LAN ইতিমধ্যে ব্যবহার করে এমন ঠিকানা দেয়।