VPN এবং হোম LAN একই সাবনেট ব্যবহার করে: আগে রুটটি দেখুন
দুটি অ্যাডাপ্টারই 192.168.1.0/24 দাবি করে এবং একটি রুট জিতে যায়। নম্বর বদলানো বা DNS-কে দোষ দেওয়ার আগে অ্যাডাপ্টার তালিকা, জেতা রুট ও ফেরার পথ দেখুন।
আপনি অফিস VPN-এ যুক্ত হন, ট্রের আইকন সবুজ হয়, ইন্ট্রানেট লোড হয়, আর দুই মিটার দূরের প্রিন্টার উত্তর দেওয়া বন্ধ করে দেয়। সকালে যে শেয়ারটি কাজ করছিল, সেটিই একই মেশিনে টাইম আউট হয়, অথচ কোনো লগে প্রিন্টারের কথা নেই। প্রথম প্রতিক্রিয়া DNS, কারণ যে নাম রিজলভ হয় না তা অস্তিত্বহীন নামের মতো দেখায়, কিন্তু সমস্যা ঠিকানায়: দুটি অ্যাডাপ্টার এখন 192.168.1.0/24 দাবি করছে এবং এই প্রিফিক্সে কেবল একটি রুটই জিততে পারে। এই ক্রমে এগোন, আর কিছু বদলানোর আগেই দেখতে পাবেন কোন অ্যাডাপ্টার সেটি নিয়েছে।
উপসর্গ থেকে শুরু করুন, টানেল থেকে নয়
ইঙ্গিতটি পরিধিতে। ইন্ট্রানেট কাজ করলে আর প্রতিটি স্থানীয় ডিভাইস ব্যর্থ হলে, টানেল সুস্থ এবং স্থানীয় পথ নয়। স্থানীয় ডিভাইস কাজ করলে আর ইন্ট্রানেট ব্যর্থ হলে, উল্টোটা। একটি হোস্ট ছাড়া সবকিছু কাজ করলে, আপনি এমন একটি ঠিকানার দিকে তাকিয়ে আছেন যা দুই পাশেই আছে।
কোনো সেটিংয়ে হাত দেওয়ার আগে একটি স্থানীয় আর একটি দূরবর্তী ঠিকানা লিখে রাখুন। “প্রিন্টার” পরীক্ষাযোগ্য নয়; 192.168.1.40 পরীক্ষাযোগ্য। এই এক ধাপই এই সমস্যায় সবচেয়ে সাধারণ নষ্ট ঘণ্টাটি ঠেকায়, আর সেটি হলো রাউটিং সিদ্ধান্তের জন্য DNS সেটিং পুনর্লিখন।
ধাপ 1: প্রিফিক্স দাবি করা দুটি অ্যাডাপ্টারই দেখুন
নেটওয়ার্ক সংযোগ (ncpa.cpl) খুলে দুটি অ্যাডাপ্টার পাশাপাশি পড়ুন। Ethernet অ্যাডাপ্টার 192.168.1.50/24 দেখায়, গেটওয়ে 192.168.1.1। VPN অ্যাডাপ্টার দেখায় 192.168.1.201/24, যা সার্ভার পাঠিয়েছে। দুটিই বৈধ, দুটিই মনে করে প্রিফিক্সটি on-link, আর স্ট্যাক এর জন্য একটিই রুট রাখবে।
Get-NetIPAddress -AddressFamily IPv4 ঠিকানাগুলো তালিকাভুক্ত করে, আর Get-NetIPInterface | Sort-Object InterfaceMetric দেখায় স্ট্যাক কোন ক্রমে সেগুলো ব্যবহার করবে। ওই মেট্রিক কলামটাই সেই সিদ্ধান্ত যা আপনি পড়তে যাচ্ছেন, তাই মনে রাখার চেষ্টা না করে সংখ্যাগুলো লিখে রাখুন।
সস্তায় DNS তত্ত্বটি ভুল প্রমাণ করুন: Resolve-DnsName printer.office.lan গতকাল যে ঠিকানা দিয়েছিল আজও তাই দেয়। নামটি রিজলভ হয়েছিল; প্যাকেটটি তখন ভুল অ্যাডাপ্টার দিয়ে বেরিয়ে গেছে। এখানে দুই মিনিট রিজলভার সেটিংসে একটি বিকেল বাঁচায়।
ধাপ 2: যে রুটটি আসলে জিতেছে তা পড়ুন
Find-NetRoute -RemoteIPAddress 192.168.1.40 সেই ঠিকানার জন্য স্ট্যাক যে ইন্টারফেস, পরবর্তী হপ ও সোর্স ব্যবহার করবে তা দেখায়। এই আউটপুটকে ইঙ্গিত নয়, উত্তর হিসেবেই ধরুন। কোন এন্ট্রি হেরেছে আর কতটায়, তা দেখতে চাইলে route print -4 পুরো টেবিল দেয়।
নির্দিষ্টতা অভিপ্রায়কে হারায়। পাঠানো 192.168.0.0/25 স্থানীয় 192.168.0.0/24-কে হারায়, কারণ প্রিফিক্সটি দীর্ঘতর, তাই 192.168.0.0 থেকে 192.168.0.127 টানেল দিয়ে বেরোয় আর ওপরের অর্ধেক স্থানীয় থাকে। কোনো ত্রুটি বার্তা ছাড়া অর্ধেক LAN উধাও হয়ে যাওয়া ওই টেবিলের জন্য সঠিক আচরণ।
tracert -d 192.168.1.40 টেবিলের বাইরে থেকে এটি নিশ্চিত করে: যদি প্রথম হপ আপনার নিজের রাউটারের বদলে টানেল ঠিকানা হয়, তবে রুটই পুরো গল্প। Linux-এ একই প্রশ্ন ip route get 192.168.1.40, যা এক লাইনে সোর্স ঠিকানা ও ডিভাইস দেখায়। উত্তর যখন tun0 বলে, ব্রাউজারের দিকে তাকানো বন্ধ করুন।
ধাপ 3: ক্লায়েন্টকে দোষ দেওয়ার আগে ফেরার পথ দেখুন
সামনের দিকের সঠিক রুটও ব্যর্থ হয় যদি দূরের পাশ উত্তর দিতে না পারে। টানেল দিয়ে কোনো ক্লায়েন্ট LAN-এ পৌঁছালে, সেই LAN-এর গেটওয়েকে জানতে হবে টানেল পুল কোথায় থাকে: ওই রাউটারে ip route add 10.8.0.0/24 via 192.168.1.12, এবং সার্ভার থেকে push “route 192.168.1.0 255.255.255.0” যাতে ক্লায়েন্টরা বিপরীত পথ জানে।
প্রথম এন্ট্রি না থাকলে উত্তরটি লক্ষ্য থেকে তার ডিফল্ট গেটওয়ের দিকে বেরিয়ে যায়, যা একটি প্রাইভেট ঠিকানা ISP-র কাছে পাঠিয়ে ফেলে দেয়। উপসর্গটি একমুখী এবং সহজে ভুল পড়া যায়: অনুরোধ tun0-এ দেখা যায়, উত্তর কখনোই নয়।
VPN হোস্টে masquerade নিয়ম ওই স্ট্যাটিক রুটের প্রয়োজন মেটায়: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. এটি আসল সোর্স ঠিকানাও লুকায়, ফলে পরের প্রতিটি লগ-প্রশ্ন কঠিন হয়। ভুল ডিফল্ট গেটওয়ে থাকা লক্ষ্য হোস্ট একই নীরবতা তৈরি করে: সেরা ক্ষেত্রে ICMP রিডাইরেক্ট, স্বাভাবিক ক্ষেত্রে ব্ল্যাক হোল, তাই ক্যাপচার দুই প্রান্তেই নেওয়া উচিত।
ধাপ 4: এমন মেরামত বেছে নিন যা নিয়ে আপনি চলতে পারবেন
এর জন্য পাঁচটি মেরামত ব্যবহার হয়, আর তারা পরস্পর বিনিময়যোগ্য নয়। কোন কমান্ডটি সংক্ষিপ্ততম তার ভিত্তিতে নয়, বরং একই সময়ে কী পৌঁছনোযোগ্য থাকতে হবে তার ভিত্তিতে বেছে নিন।
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
মেট্রিক সবচেয়ে সস্তা বিকল্প এবং মানুষ প্রথমেই যেটির দিকে হাত বাড়ায়। পরিবর্তনটি ইন্টারফেসে প্রযোজ্য, তাই টানেল চালু থাকা অবস্থায় কাজ করে, আর এর জায়গা ক্লায়েন্টের পাশে স্ক্রিপ্টে, আপনি যে শেল ভুলে যাবেন সেখানে নয়। এটি দুই নেটওয়ার্কে একই ঠিকানায় একসাথে প্রবেশাধিকার দিতে পারে না, এবং এই সীমাবদ্ধতাই বাকি সবাইকে টেবিলের নিচে পাঠায়।
হোম LAN নম্বর বদলানো 10.10.0.0/24-এ সবচেয়ে পরিচ্ছন্ন সমাধান: একটি DHCP লিজ নবায়ন এবং পুরোনো রেঞ্জ উল্লেখ করা রিজার্ভেশন, প্রিন্টার কিউ ও হার্ডকোডেড ঠিকানা। অফিসের পাশের নম্বর বদলানো সাধারণত আপনার সিদ্ধান্ত নয়। IPv6 দুই নেটওয়ার্কেই থাকলে সংঘাতটি পুরোপুরি সরিয়ে দেয়, মনে রাখার মতো কিছুর বদলে fd00::/8 থেকে অনন্য লোকাল প্রিফিক্স ব্যবহার করে, তবে অ্যাপ্লিকেশনটি TCP-তে পরীক্ষা করুন, ping-এ নয়, কারণ ICMP কাজ করতে পারে অথচ সার্ভিস নাও পারে।
OpenVPN-এর নিজস্ব অনুবাদ অপশনই শেষ উপায়, যা সার্ভার থেকে ক্লায়েন্ট-নির্দিষ্ট ডিরেক্টরি এন্ট্রিতে পাঠানো হয়। অপশনের নামের পরে চারটি প্যারামিটার নেয় — দিক, নেটওয়ার্ক, নেটমাস্ক ও উপনাম — আর উপনামটি ঐচ্ছিক নয়: push "route 192.168.2.0 255.255.255.0" এবং push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0"। নেটওয়ার্ক ও নেটমাস্ক হলো ক্লায়েন্ট যে রেঞ্জ দেখে (192.168.2.0/24), উপনাম হলো সার্ভার পাশে আসল অফিস রেঞ্জ (192.168.1.0/24), আর পাঠানো রুটটিই সেই দৃশ্যমান রেঞ্জকে পৌঁছনোযোগ্য করে। তখন অফিসটি ওই ক্লায়েন্টের কাছে 192.168.2.x-এর অধীনে দেখা যায়। প্রোফাইলে ম্যাপিংটি নথিভুক্ত করুন, নইলে পরের ব্যক্তি এটিকে রাউটিং ত্রুটি হিসেবে ডিবাগ করবে।
একটি মাত্র সার্ভিস প্রকাশ করা হলো অনুবাদের সংকীর্ণ সংস্করণ, আর এর OpenVPN-এর অপশন একেবারেই দরকার নেই। VPN হোস্টে একটি DNAT নিয়ম একটি পোর্ট পুনঃপ্রকাশ করে, তাই LAN তার ঠিকানা ধরে রাখে এবং যে হোস্ট ঠিকানা সে আগেই জানে সেখানেই সার্ভিসে পৌঁছায়। খরচটি স্বাভাবিক: সার্ভিসটি VPN হোস্টকে সোর্স হিসেবে দেখে, তাই ক্লায়েন্টভিত্তিক লগ ও রিভার্স লুকআপ অর্থহীন হয়ে যায়। এটি একটি প্রিন্টার কিউ বা একটি অ্যাডমিন পেজ কভার করে, দুই পাশের হোস্টের পরস্পরে পৌঁছানো নয়।
যা এখনো কাজ করবে না, আর কী লিখে রাখবেন
ব্রডকাস্ট রাউটেড টানেল পার হয় না। DLNA, UPnP, NetBIOS ব্রাউজিং ও Wake-on-LAN এমন ব্রডকাস্ট বা মাল্টিকাস্টের ওপর নির্ভর করে যা tun ডিভাইস বহন করে না, তাই কোনো রুট ডিসকভারি ঠিক করে না। dev tap দিয়ে ব্রিজিং সেগমেন্ট বাড়ায়, সঙ্গে DHCP ব্রডকাস্ট, ARP ও অন্যান্য ডিসকভারি প্যাকেটও; দূরবর্তী রাউটারের LAN পাশের ঠিকানার জন্য route 192.168.2.1 255.255.255.255-এর মতো ইউনিকাস্ট হোস্ট রুট বেছে নিন।
একই পথে দুটি রাউটারই 192.168.1.1 ব্যবহার করলে তারা একই ধরনের সমস্যা: স্থানীয় ঠিকানা সবসময় জেতে, তাই একটি LAN না সরানো পর্যন্ত দূরের রাউটারের পেজ পৌঁছনোযোগ্য থাকে না। দ্বিতীয় অ্যাডাপ্টার যোগ করলে দুই ক্ষেত্রেই কিছুই বদলায় না।
কিছু সম্পাদনার আগে প্রমাণ লিখে রাখুন: ip route get বা Find-NetRoute, প্রশ্নের ঠিকানায় ping -c 3, একটি traceroute, এবং ক্লায়েন্টে tcpdump -ni tun0 icmp, তারপর সার্ভারে রাউটিং টেবিল ও NAT কাউন্টার। যে ping এক দিকে কাজ করে আর অন্য দিকে মরে যায়, তা টানেল নয় বরং ফেরার পথের দিকে ইশারা করে, আর এই একটি পার্থক্যই ঠিক করে উপরের কোন মেরামত আপনার আসলে দরকার।