Windows-এ VPN লোকাল LAN আটকায়: রুট নাকি ক্লায়েন্ট নীতি?
Windows-এ লোকাল LAN অ্যাক্সেস দুটি ভিন্ন কারণে ভাঙে: অনুপস্থিত রুট, অথবা এমন গেটওয়ে নীতি যা সাবনেট বাদ দেয়। তিনটি পরীক্ষা বলে দেয় কোনটি।
আপনার নিজের ডেস্কে থাকা প্রিন্টার, NAS বা ডেভেলপমেন্ট বক্স কাজের VPN সংযুক্ত হওয়ার মুহূর্তেই সাড়া দেওয়া বন্ধ করে দেয়। কখনও একটি রুট কমান্ড কয়েক সেকেন্ডে ঠিক করে দেয়; কখনও একই রুট সঠিক থাকে আর প্যাকেট তবু মিলিয়ে যায়, যার মানে আপনি একই রকম উপসর্গযুক্ত ভিন্ন সমস্যা দেখছেন। সিদ্ধান্ত তিনটি প্রশ্নে নেমে আসে, আর ভুল ক্রমে প্রশ্ন করাই মানুষকে সারা সন্ধ্যা রুট মুছে আবার যোগ করার পেছনে ব্যয় করতে বাধ্য করে।
যেকোনো কমান্ডের আগে তিনটি প্রশ্ন
প্রথম: লোকাল প্রিফিক্সের জন্য কোনো এন্ট্রি আছে কি, এবং তা কি ভৌত অ্যাডাপ্টারের দিকে নির্দেশ করে? দ্বিতীয়: সংযোগের সময় ক্লায়েন্ট কি গেটওয়ে থেকে লোকাল-নেটওয়ার্ক অনুমতি বা নিষেধ পায়? তৃতীয়: আপনার কি শুধু LAN-এ আউটবাউন্ড অ্যাক্সেস দরকার, নাকি ইন্টারনেটের কিছুকেও আপনার মেশিনে চলা কোনো সেবায় পৌঁছাতে হবে?
প্রথম প্রশ্ন রাউটিং ত্রুটিকে ফিল্টারিং ত্রুটি থেকে আলাদা করে। দ্বিতীয়টি বলে রাউটিং সমাধান আদৌ কাজ করার অনুমতি পায় কি না। তৃতীয়টি মেরামত বদলে দেয়: রুট আউটবাউন্ড ট্রাফিক ঠিক করে, আর পৌঁছানো যায় না এমন ইনবাউন্ড সেবা সাধারণত লিসেনার বাইন্ডিং ও রিটার্ন-পাথ সমস্যা, যা রুট আরও খারাপ করে।
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
প্রশ্ন এক: রুট, ফিল্টার নাকি নাম
টেবিলে কিছু যোগ করার আগে টেবিলটি পড়ুন। ইন্টারফেস ইনডেক্স গুরুত্বপূর্ণ, কারণ নিচের প্রতিটি রুট কমান্ড তার সাথে বাঁধা:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric
সরাসরি সংযুক্ত সাবনেট সাধারণত টানেল চালু থাকলেও অন-লিঙ্ক রুট ধরে রাখে, তাই এন্ট্রি থাকতেই পারে এবং ট্রাফিক তবু ব্যর্থ হতে পারে। এই সমন্বয়ই রাউটিংয়ের পরে চলা ফিল্টারের স্বাক্ষর, এবং এটিই সেই ক্ষেত্র যেখানে আরও নির্দিষ্ট দ্বিতীয় রুট কিছুতেই কিছু বদলায় না।
ঠিকানা ও নাম আলাদাভাবে পরীক্ষা করুন। যদি ping 192.168.1.50 সাড়া দেয় আর net view 192.168.1.50 না দেয়, তবে রাউটিং টেবিল কখনওই সমস্যা ছিল না: টানেল রিজলভার বদলে দিয়েছে এবং লোকাল নাম আর রিজলভ হয় না। তার জন্য রুট যোগ করা বৃথা পরিশ্রম।
প্রশ্ন দুই: গেটওয়ে কি লোকাল LAN অ্যাক্সেসের অনুমতি দেয়?
বাণিজ্যিক ক্লায়েন্ট শুধু রুট ইনস্টল করে না। সংযোগের সময় সে একটি নীতি পায়, আর সেই নীতিতে স্পষ্ট লোকাল-নেটওয়ার্ক অনুমতি থাকতে পারে। Cisco IPsec স্থাপনায় গ্রুপ নীতিতে split-tunneling সেটিং ও আলাদা লোকাল LAN অ্যাক্সেস ফ্ল্যাগ থাকে; ক্লায়েন্টের চেকবক্সটি একটি অনুরোধ যা গেটওয়ে প্রত্যাখ্যান করতে পারে। AnyConnect-এ প্রোফাইল split অন্তর্ভুক্তি ও বাদ তালিকা এবং একই অনুমতি নিয়ন্ত্রণ করে। Windows RRAS-এ সমতুল্য হলো প্রোফাইলের ডিফল্ট গেটওয়ে অপশন এবং সার্ভার যে স্ট্যাটিক রুট দেয়।
ফ্ল্যাগ বন্ধ থাকলে নথিভুক্ত আচরণ হলো, ক্লায়েন্ট সরাসরি সংযুক্ত সাবনেটে ট্রাফিক আটকায় যদিও বৈধ, আরও নির্দিষ্ট রুট বিদ্যমান। এজন্য ক্লায়েন্টের মালিকানাধীন নয় এমন রুটও যোগ করার কয়েক সেকেন্ড পর মিলিয়ে যেতে পারে: ক্লায়েন্ট তাকে যে অবস্থা তৈরির নির্দেশ দেওয়া হয়েছে তা আবার তৈরি করছে, আপনার সাথে লড়ছে না।
ক্লায়েন্ট লগ সংযোগের সময় সিদ্ধান্তটি রেকর্ড করে, আর তা পড়া মেশিনে যেকোনো পরীক্ষার চেয়ে দ্রুত। লগ যদি বলে লোকাল অ্যাক্সেস আটকানো, থামুন: কোনো কমান্ড-লাইন সমাধান এতে টেকে না, আর বাকি পথগুলো হলো নীতি পরিবর্তন, টানেল দিয়ে রিসোর্সে পৌঁছানো, অথবা ক্লায়েন্টকে ভার্চুয়াল মেশিনে রাখা এবং হোস্টকে লোকাল নেটওয়ার্কে রেখে দেওয়া।
প্রশ্ন তিন: আপনার কোন দিকটি দরকার?
কাছাকাছি ডিভাইসে আউটবাউন্ড ট্রাফিক একটি রাউটিং প্রশ্ন। LAN প্রিফিক্সকে লোকাল গেটওয়ের দিকে নির্দেশ করুন এমন মেট্রিক দিয়ে যা টানেলের ডিফল্ট রুটকে হারিয়ে দিতে যথেষ্ট নিচু:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p
দ্বিতীয় রূপটি একটি ডিভাইস পিন করে, একটিই ঠিকানা যখন পুরো প্রয়োজন, তখন এটাই চান। netsh সমতুল্য একই সিদ্ধান্ত ইনডেক্সের বদলে ইন্টারফেস নামে রেকর্ড করে:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent
ঠিকানা ও মাস্ক না মিললে রুট কমান্ড প্যারামিটারটি ভুল দিয়ে ব্যর্থ হয়, যেমন /24 মাস্কসহ হোস্ট ঠিকানা। সাবনেট রুটের জন্য নেটওয়ার্ক ঠিকানা এবং একক হোস্টের জন্য হোস্ট মাস্ক ব্যবহার করুন।
ইনবাউন্ড ভিন্ন। একই মেশিনের VNC বা SSH সার্ভার পৌঁছানো যায় না যখন ইনকামিং সংযোগের উত্তর VPN গেটওয়ে দিয়ে বেরিয়ে আর ফেরে না। রুট স্পর্শ করার আগে দেখুন সেবাটি কী শোনে:
netstat -ano | findstr :5900
একটি নির্দিষ্ট ঠিকানায় বাঁধা লিসেনার অন্য ইন্টারফেসে সাড়া দেবে না। এটিকে সব ইন্টারফেসে বাঁধা একটি সচেতন সিদ্ধান্ত, যা আপনি যে নেটওয়ার্কে ভরসা করেন তার মধ্যে সীমিত ফায়ারওয়াল নিয়মের সাথে নেওয়া হয়। শুধু তারপরেই রুট মেরামত রিটার্ন পাথ ফিরিয়ে আনে।
যে সবচেয়ে ছোট পরিবর্তন মেলে তা প্রয়োগ করুন
আরেকটি সাধারণ পদক্ষেপ হলো IPv4 উন্নত বৈশিষ্ট্যে “রিমোট নেটওয়ার্কে ডিফল্ট গেটওয়ে ব্যবহার করুন” থেকে টিক তুলে নেওয়া। এটি ইন্টারনেট ট্রাফিক লোকাল রাখে, কিন্তু একসাথে দুটি কাজ করে: VPN আর ডিফল্ট পথ থাকে না, এবং ক্লায়েন্ট রিমোট নেটওয়ার্কের রুট পাওয়া বন্ধ করে, multicast সহ। টিক তুলে নিলে রিমোট LAN মিলিয়ে যায়, যদি না সার্ভার প্রতিটি ক্লায়েন্টের প্রয়োজনীয় নির্দিষ্ট রিমোট প্রিফিক্স পাঠায়।
এই অসমতা কাজের ক্রম নির্ধারণ করে। রিমোট দিক সম্পূর্ণ পৌঁছানোযোগ্য থাকতে হলে সার্ভার থেকে রিমোট সাবনেট পাঠান এবং লোকাল ডিফল্টকে যেতে দিন। সার্ভার বদলাতে না পারলে টানেল যে ঠিকানা দিয়েছে তার মধ্য দিয়ে রিমোট প্রিফিক্সে একটি স্থায়ী রুট যোগ করুন, এবং route print দিয়ে দেখুন প্রিফিক্স VPN ইন্টারফেসের দিকে এবং ডিফল্ট এখনও ভৌত গেটওয়ের দিকে নির্দেশ করে কি না।
তারপর নিশ্চিত করুন মেরামত পুনঃসংযোগে টিকে থাকে, কারণ অস্থায়ী রুট অ্যাডাপ্টারের সাথে মরে যায় এবং প্রতিটি সংযোগের পরে চলা স্ক্রিপ্টই তাদের সৎ জায়গা। একই সেশনে একটি লোকাল ডিভাইস ও একটি রিমোট রিসোর্স পরীক্ষা করুন, বিচ্ছিন্ন করুন, আবার সংযোগ করুন এবং আবার পরীক্ষা করুন। রুট ঠিক দেখালেও লোকাল ডিভাইস যদি এখনও ব্যর্থ হয়, প্রশ্ন দুই-এ ফিরুন: ক্লায়েন্ট ফিল্টার করছে, আর উত্তর হলো নীতি পরিবর্তন, দ্বিতীয় প্রতিদ্বন্দ্বী রুট নয়।