Windows VPN-এ ইন্টারনেট নেই? দোষী ঠিকানা পুল

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

পরিবর্তন করার আগে লিজটি পড়ুন

ক্লায়েন্টে ipconfig /all চালান এবং এন্ট্রিগুলোর মধ্যে VPN অ্যাডাপ্টারটি খুঁজুন। এটি যে ঠিকানা, ডিফল্ট গেটওয়ে ও DNS সার্ভার দেখায় সেগুলোই আপনার দরকারি তথ্য, এবং প্রশাসক যা বিতরণ করা হয়েছে বলে ধরে নেন তার থেকে এগুলো প্রায়ই আলাদা।

তিনটি ধরন তিনটি ত্রুটির সঙ্গে মেলে। 169.254.0.0/16-এ ঠিকানা মানে ক্লায়েন্ট কিছুই পায়নি এবং নিজেকে লিংক-লোকাল ঠিকানা দিয়েছে। যুক্তিসঙ্গত ঠিকানা অথচ গেটওয়ে নেই মানে পুলটি ক্লায়েন্টকে ডিফল্ট রুট দেওয়ার অপশন ছাড়াই পরিবেশন করা হয়েছে। সম্পূর্ণ লিজ তবুও কোথাও না পৌঁছালে তা সার্ভারের দিকে ফরওয়ার্ডিং বা অনুবাদে ইঙ্গিত করে।

সার্ভার স্পর্শ করার আগে মানগুলো লিখে রাখুন। পরের ধাপে সেগুলো সার্ভার যে পরিসর বিতরণ করছে বলে মনে করে তার সঙ্গে তুলনা করা হবে, আর স্মৃতির ওপর ভরসা লিজের বিকল্প নয়।

কেন স্বয়ংক্রিয় বরাদ্দ গেটওয়ে ছাড়া রেখে দিতে পারে

Incoming Connections এন্ট্রির নিজস্ব IPv4 বৈশিষ্ট্য আছে, যা ভৌত অ্যাডাপ্টার থেকে আলাদা। সেখানকার ডিফল্ট ঠিকানাগুলো স্বয়ংক্রিয়ভাবে বরাদ্দ করার প্রস্তাব দেয়, যা ঠিকানা, মাস্ক, গেটওয়ে ও DNS যোগাতে সংযোগের অন্তর্নির্মিত বরাদ্দকারীর ওপর নির্ভর করে।

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

এই কারণেই নির্দিষ্ট একটি পরিসরে গেলে এ ধরনের এত রিপোর্ট ঠিক হয়ে যায়। যে সেবা চলছে নাও হতে পারে তাকে লিজ বানাতে বলা বন্ধ করে আপনি নিজেই লিজ ঘোষণা করতে শুরু করেন।

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

সার্ভার যে পরিসর রাউট করতে পারে তা স্পষ্টভাবে নির্ধারণ করুন

সার্ভার যে সাবনেটে পৌঁছাতে পারে তার ভেতরে, LAN রাউটার যে পরিসর বিতরণ করে তার বাইরে এবং নেটওয়ার্কের অন্য যেকোনো পুলের বাইরে ছোট একটি ব্লক বেছে নিন। সার্ভার যদি 172.20.10.0/24-এ থাকে এবং রাউটার 172.20.10.1 ধরে রাখে, তাহলে ওই সাবনেটের উপরের দিকে একটা ছোট ব্লক, যেমন 172.20.10.201 থেকে 172.20.10.209, রাউটার যে বিতরণ ইতিমধ্যে সামলায় তা থেকে টানেল লিজগুলো দূরে রাখে।

এটি Incoming Connection-এর IPv4 বৈশিষ্ট্যে লিখুন, ক্লায়েন্ট আবার সংযোগ করুন, এবং অন্য কিছু বদলানোর আগে অ্যাডাপ্টারটি আবার পড়ুন। দ্বিতীয় পাঠই আপনাকে বলে দেয় পুলটাই দোষ ছিল, নাকি কেবল কয়েকটি ত্রুটির একটি।

এই কমান্ডগুলো চূড়ান্ত কনফিগারেশন এবং ক্লায়েন্টের এখনকার রুটগুলো দেখায়:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

ঠিকানা মানেই ইন্টারনেটের পথ নয়

লিজ পেলেই কেবল প্যাকেট ক্লায়েন্ট থেকে সার্ভারে যায়। ইন্টারনেট অ্যাক্সেসের জন্য সার্ভারকে সেই প্যাকেট ফরওয়ার্ড করতে হবে এবং নিজের আপলিংকের দিকে অনুবাদ করতে হবে, আর সেটি আলাদা কনফিগারেশন যার নিজস্ব ব্যর্থতার ধরন আছে।

Internet Connection Sharing হলো শর্টকাট। এটি ইন্টারনেটমুখী অ্যাডাপ্টারকে একটি যৌথ গেটওয়েতে পরিণত করে এবং নিজের ঠিকানাকরণ চালায়, যা ওই অ্যাডাপ্টারের ঠিকানা আবার লিখে দিতে পারে এবং বিদ্যমান NAT নিয়মকে এমন মানের দিকে নির্দেশিত রেখে যেতে পারে যা আর নেই। চালু করার আগে মূল সেটিংস লিখে রাখুন।

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

আগে বাইরের পথ বাদ দিন

টানেল যদি কখনোই তৈরি না হয় তবে কোনো পুলই সাহায্য করতে পারে না। পথে কী চলবে তা প্রোটোকলই ঠিক করে: PPTP চায় TCP 1723 ও GRE, যা পোর্ট নয় বরং IP প্রোটোকল 47; L2TP/IPsec চায় UDP 1701 সহ 500 ও 4500; SSTP চায় TCP 443।

যে রাউটার পোর্ট ফরওয়ার্ড করে কিন্তু প্রোটোকল করে না, সেটি এমন সংযোগের চেষ্টা তৈরি করে যা কখনো প্রমাণীকরণে পৌঁছায় না। এটি টানেল তৈরি হয়ে তারপর কোথাও না পৌঁছানোর চেয়ে আলাদা ব্যর্থতা, আর দুটোকে একসঙ্গে ডিবাগ করা উচিত নয়।

একই LAN থেকে এবং দূরবর্তী নেটওয়ার্ক থেকে পরীক্ষা করুন। LAN থেকে চেষ্টা কাজ করলে আর দূরবর্তীটি কখনো প্রমাণীকরণে না পৌঁছালে সমস্যা বাইরের পথে। দুটোই প্রমাণীকৃত হলে এবং কেবল দূরবর্তী ক্লায়েন্টের ইন্টারনেট না থাকলে পুল ও নির্গমনে ফিরে যান।