VPN-এ সংযোগ দেওয়ার পর স্থানীয় IP ঠিকানার দ্বন্দ্ব সমাধান

এই প্রতিবেদনগুলোর প্রতিটি একই রকম শোনায় এবং ভিন্ন কিছু বোঝায়: ল্যাপটপ ঠিকানার দ্বন্দ্বের অভিযোগ করে, কিন্তু শুধু মাঝে মাঝে, এবং বেশিরভাগ সময় VPN চালু থাকলে। তিনটি আলাদা ত্রুটি সেই বার্তাটি তৈরি করে: আপনার নিজের লিংকে সত্যিকারের নকল, এমন ওভারল্যাপ যেখানে দূরবর্তী নেটওয়ার্ক আপনার LAN রেঞ্জ ব্যবহার করে এবং কিছুই নকল নয়, এবং এমন টানেল যা একটি ঠিকানা দুই পিয়ারকে দিয়েছে। প্রতিটি ক্ষেত্রে মেরামত আলাদা, আর ভুলটি উপসর্গ সরানোর বদলে তাকে সরিয়ে নেয়। তাই কিছু সম্পাদনার আগে নির্ধারণ করুন আপনার কোন কেসটি।

একটি ত্রুটি বার্তা ভাগ করা তিনটি সমস্যা

নকল মানে একই সেগমেন্টে দুটি মেশিন একটি ঠিকানার দাবি করে। কার্নেল এটি লক্ষ করে কারণ তার নিজের প্রোবের উত্তর আসে ভিন্ন MAC থেকে, এবং এরপর কী হয় তা স্ট্যাকের উপর নির্ভর করে: Linux এটি লগ করে, Windows ইন্টারফেস নিষ্ক্রিয় করে এবং System লগে এন্ট্রি লেখে, আর DHCP ক্লায়েন্ট অফারটি প্রত্যাখ্যান করতে পারে।

ওভারল্যাপ কোনো ঠিকানা নকল করে না। আপনার LAN হলো 192.168.1.0/24, অফিস নেটওয়ার্কও 192.168.1.0/24, এবং এখন অফিসের রুট এমন ঠিকানার দিকে যায় যেগুলো আপনার প্রিন্টার ও আপনার NAS-ও। ARP অর্থে কোনো দ্বন্দ্ব নেই; প্যাকেটটি কেবল দুটি নেটওয়ার্কের একটিতে ভুল ডিভাইসে যায়।

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

পরীক্ষা 1: নকলটি কি আপনার নিজের সেগমেন্টে?

আপনার মেশিনে আসলে কী আছে তা তালিকাভুক্ত করে শুরু করুন, আপনি কী কনফিগার করেছিলেন মনে আছে তা নয়। VPN অ্যাডাপ্টারের ঠিকানা টানেলের জন্য ব্যক্তিগত এবং ওয়েবসাইটগুলো যে ঠিকানা দেখে তার সমান নয়, তাই একটি ভাগ করা পাবলিক এক্সিট দ্বন্দ্ব নয়।

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windows-এ একই তথ্য আসে ipconfig /all এবং Get-NetIPAddress থেকে, আর প্রতিবেশী ক্যাশে থাকে arp -a-এ। যদি বিতর্কিত ঠিকানাটি ফিজিক্যাল অ্যাডাপ্টারে থাকে এবং VPN না চালিয়েও অভিযোগ দেখা দেয়, তবে VPN দর্শকমাত্র এবং আপনার এর সমস্যা খোঁজা বন্ধ করা উচিত।

অনুমান না করে নকল প্রমাণ করতে, এমন ডিভাইস থেকে ঠিকানাটি যাচাই করুন যেটি এটি ধরে না। arping -D শূন্য সোর্স ঠিকানা দিয়ে প্রোব পাঠায়, তাই অপ্রত্যাশিত MAC থেকে উত্তর প্রমাণ করে যে অন্য একটি হোস্ট ইতিমধ্যে ওই ঠিকানার উত্তর দিচ্ছে।

sudo arping -D -I eth0 -c 3 192.168.1.50

তারপর নিজে অন্য ঠিকানা বাছাই না করে নেটওয়ার্ক প্রশাসকের মাধ্যমে মালিককে খুঁজুন। কেবল কারও নোটে থাকা স্ট্যাটিক বরাদ্দ, নির্দিষ্ট ঠিকানার প্রিন্টার এবং DHCP সার্ভারের রিজার্ভেশনই সাধারণ অপরাধী, আর বন্ধ থাকা ডিভাইসও তার লিজ ধরে রাখে।

পরীক্ষা 2: দুটি নেটওয়ার্ক কি ওভারল্যাপ করে?

টানেল আপনাকে যে প্রিফিক্স দেয় তা আপনার ইন্টারফেসের প্রিফিক্সের সঙ্গে তুলনা করুন। যদি দূরবর্তী রেঞ্জ আপনার LAN-এর সমান হয় বা তা ধারণ করে, তবে সমস্যাটি ওভারল্যাপ, আর সূত্র হলো VPN ছাড়া পৌঁছানো যায় এমন হোস্ট অন্ধকার হয়ে যাওয়া, বা আপনার নিজের প্রিন্টার অফিস ঠিকানায় উত্তর দেওয়া।

ip route get 192.168.1.10
ip -br addr show

রুট লুকআপ আপনাকে বলে কার্নেল কোন ইন্টারফেস ব্যবহার করবে, আর সেই উত্তরই পুরো নির্ণয়। যদি এটি আপনার স্থানীয় প্রিন্টারের ঠিকানার জন্য টানেল বলে, তবে আপনার ওভারল্যাপ আছে এবং লিজ নবায়নের কোনো পরিমাণই তা বদলাবে না।

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

অফিস নেটওয়ার্ক পুনঃনম্বরকরণ খুব কমই আপনার সিদ্ধান্ত। সংঘর্ষ এড়াতে নিজের LAN পুনঃনম্বরকরণ প্রিন্টার, ক্যামেরা ও স্ট্যাটিক হোস্ট জড়িত হলে বেশিরভাগ মানুষের প্রত্যাশার চেয়ে বড় পরিবর্তন।

পরীক্ষা 3: টানেল কি একটি ঠিকানা দুইবার দিয়েছে?

WireGuard-এর কোনো ঠিকানা পুল নেই। প্রতিটি পিয়ার চিহ্নিত হয় তার পাবলিক কী এবং AllowedIPs-এর প্রিফিক্স দিয়ে, তাই নকল দেখা যায় যখন একই টানেল ঠিকানা দুটি পিয়ার এন্ট্রিতে লেখা হয় বা একই কী জোড়া দুটি মেশিনে ইনস্টল হয়।

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

ট্র্যাফিক কাউন্টার এখানে উপকারী কলাম: যে পিয়ার সাম্প্রতিক হ্যান্ডশেক দেখায় কিন্তু কোনো স্থানান্তর নয়, সে হয় ভুল ঠিকানার, নয় অন্য একটি এন্ট্রির দ্বারা ছায়াবৃত যা একই প্রিফিক্স দাবি করে। একটি প্রিফিক্স ঠিক একটি পিয়ারে রাখুন এবং প্রতিটি ডিভাইসকে তার নিজের কী জোড়া দিন।

OpenVPN-এর একটি পুল আছে, আর সাধারণ সংঘর্ষ হলো একটি ভাগ করা ক্লায়েন্ট প্রোফাইল যাতে নির্দিষ্ট --ifconfig লাইন দ্বিতীয় মেশিনে কপি করা হয়েছে। তখন দুই ক্লায়েন্টই একই টানেল ঠিকানা চায়, এবং সার্ভার যে সেশনটি আগে প্রক্রিয়া করে সেটিই গ্রহণ করে। --duplicate-cn সহ পুল নিঃশেষ হওয়া একই রকম ফল দেয় যখন একটি সার্টিফিকেটের কয়েকটি সেশন একটি এন্ট্রির জন্য প্রতিযোগিতা করে।

এর জন্য ক্লায়েন্ট লগের বদলে সার্ভার লগ পড়ুন। সার্ভার জানে কোন সেশন কোন ঠিকানা দাবি করেছে, আর সেখানে পুনরাবৃত্ত ঠিকানাগুলো এমন সতর্কবার্তা হিসেবে দেখা যায় যা কখনো ক্লায়েন্টের কাছে পৌঁছায় না।

উৎসে মেরামত করুন, তারপর দুটি ডিভাইসই আবার যাচাই করুন

ক্রম গুরুত্বপূর্ণ। আগে LAN-এর নকল ঠিক করুন, কারণ যে ক্লায়েন্ট একটি ঠিকানা ধরে রাখতে পারে না সে টানেলও ধরে রাখতে পারে না। তারপর VPN পাশে প্রকিউরিং ঠিক করুন, কারণ পুল বরাদ্দে ক্লায়েন্ট-পাশের সম্পাদনা পরবর্তী সংযোগে বাতিল হয়ে যায়। শেষে নকল পরিচয় সামলান: WireGuard-এ আলাদা কী জোড়া, OpenVPN-এ আলাদা সার্টিফিকেট বা অন্তত আলাদা প্রোফাইল।

ক্লায়েন্টে যান্ত্রিক অংশটি সংক্ষিপ্ত। একটি DHCP লিজ ছেড়ে দিন ও নবায়ন করুন, বা রিজার্ভেশনের জন্য সার্ভারে ঠিকানা বদলানোর অনুরোধ করুন। মুক্ত দেখায় এমন কোনো এলোমেলো ঠিকানা টাইপ করবেন না।

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

তারপর এক পাশ থেকে নয়, দুই পাশ থেকেই যাচাই করুন। গেটওয়ে নিশ্চিত করুন, তারপর আপনার আসলে প্রয়োজনীয় সেবা, তারপর আবার সংযোগ করে পুনরাবৃত্তি করুন। যদি দুটি ডিভাইস জড়িত থাকে, দুটিই দেখুন: একটি ঠিকানা সরালে অন্যটি পুরোনো প্রতিবেশী এন্ট্রি বা পুরোনো লিজ নিয়ে থাকে যা পরে আবার দেখা দেয়।

পথে যা করা উচিত নয়

উপসর্গটি চুপ করাবেন না। নকল ঠিকানা শনাক্তকরণই আপনাকে ইতিমধ্যে ব্যবহৃত ঠিকানা নেওয়া থেকে থামায়, আর এটি নিষ্ক্রিয় করলে দৃশ্যমান দ্বন্দ্ব মাঝে মাঝে ঘটে যাওয়া প্যাকেট লসে পরিণত হয় যা খুঁজে বের করা অনেক কঠিন। একই কথা প্রযোজ্য অপ্রত্যাশিত হোস্টের সার্টিফিকেট সতর্কবার্তা গ্রহণের ক্ষেত্রে: এটি মোটেই ঠিকানার সমস্যা নয়, আর এটি এড়িয়ে যাওয়া ভিন্ন একটি ত্রুটি লুকায়।

পরিচালিত নেটওয়ার্কের ঠিকানাকরণও নিজে বদলাবেন না। মূল সেটিং রেকর্ড করুন, ঠিকানা কেন্দ্রীয়ভাবে বরাদ্দ হলে মালিককে জিজ্ঞাসা করুন, এবং পরিবর্তনটি ফেরানো যায় এমন ছোট রাখুন। RFC 5227 ঠিকানা-দ্বন্দ্ব শনাক্তকরণের নিয়ম ব্যাখ্যা করে সঠিক প্রোব কী প্রমাণ করে, যা দ্বন্দ্বকে সত্য বলা আগে জানা মূল্যবান।