DD-WRT-এ PPTP ক্লায়েন্টরা একে অপরকে পায় না: পাঁচটি পরীক্ষা

দুটি ল্যাপটপ DD-WRT বক্সের PPTP সার্ভারে ডায়াল করে, প্রত্যেকে একটি ঠিকানা পায়, কিন্তু কেউই অন্যজনকে পিং করতে পারে না। শেয়ার করা ফোল্ডার কখনও দেখা যায় না এবং প্রথম যে ভাবনা আসে তা হল রাউটার যে 255.255.255.255 মাস্ক দিচ্ছে সেটি নিশ্চয়ই ভুল। এটি দোষ নয়, এবং এটি বদলালে একটি নতুন প্রতিবেশীও তৈরি হবে না। নিচের পাঁচটি পরীক্ষা ক্রমে করুন এবং যেটি প্রথমে ব্যর্থ হয় সেখানেই থামুন, কারণ প্রতিটির প্রতিকার আলাদা।

পরীক্ষা এক: /32 কোনো বাগ নয়

PPTP PPP বহন করে, আর একটি PPP লিঙ্ক ঠিক দুটি প্রান্তকে যুক্ত করে: আপনার ক্লায়েন্ট এবং সার্ভার। নেটমাস্ক বলে কোন ঠিকানাগুলো একটি স্থানীয় সেগমেন্ট ভাগ করে, আর এখানে কোনো সেগমেন্ট নেই, শুধু একটি তারের অপর প্রান্তে পিয়ার আছে। সব-এক-এর মাস্ক ঠিক সেটাই বলে, তাই DD-WRT এই লিঙ্ক ধরনের জন্য সঠিক মানই দিচ্ছে। ঠিকানাটি পিয়ার ঠিকানা, LAN-এর ইন্টারফেস ঠিকানা নয়।

255.255.255.0 মাস্কের জায়গা হল শত শত ডিভাইসের শেয়ার করা মাধ্যম, আর এটি PPP ইন্টারফেসে বসালে টানেলের অপর পাশটিও প্রতিবেশী হবে না।

পরীক্ষা দুই: PPTP সার্ভার পাতার মানগুলো পড়ুন

যে সেটিংসগুলো গুরুত্বপূর্ণ সেগুলো সবই Services, VPN, PPTP Server-এ আছে। সার্ভার চালু করুন, সার্ভার ঠিকানা রাউটারের LAN ঠিকানায় সেট করুন, এবং ক্লায়েন্ট রেঞ্জ DHCP পুলের বাইরে রাখুন যাতে ডায়াল-ইন ক্লায়েন্ট আর তারে যুক্ত মেশিন একই ঠিকানা না পায়। CHAP-Secrets-এর অধীনে প্রতিটি অ্যাকাউন্টের জন্য username * password * আকারে একটি লাইন যোগ করুন, নামের ভেতরে কোনো ফাঁকা জায়গা নয়। প্রয়োগ করুন, তারপর এমন প্রোফাইল দিয়ে সংযোগ করুন যেখানে রাউটার ও সেই অ্যাকাউন্টগুলোর একটি উল্লেখ থাকে।

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

পরীক্ষা তিন: দুই পিয়ারের মধ্যে রুট খুঁজুন

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

দুটি আলাদা ppp ইন্টারফেসে দুটি হোস্ট রুট—আরও এগোনোর আগে এটাই আপনার কাঙ্ক্ষিত আকৃতি।

পরীক্ষা চার: FORWARD চেইন দেখুন, INPUT নয়

ক্লায়েন্ট-থেকে-ক্লায়েন্ট ট্রাফিক স্থানীয়ভাবে গৃহীত হয় না, ফরওয়ার্ড হয়, তাই INPUT চেইন ভুল জায়গা। iptables -L FORWARD -v -n চালান এবং PPP ইন্টারফেসগুলো ধরা পড়ে এমন ড্রপ নিয়ম খুঁজুন, সাথে প্যাকেট কাউন্টার যা দেখায় চেইনে আদৌ কিছু পৌঁছায় কি না। টানেল ট্রাফিকের জন্য কোনো অ্যাকসেপ্ট নিয়ম ছাড়া ডিফল্ট ড্রপ নীতি ঠিক সেই উপসর্গই দেয় যা দিয়ে আপনি শুরু করেছিলেন: প্রতিটি ক্লায়েন্ট একা ঠিক, একসাথে তারা একে অপরের কাছে অদৃশ্য।

ছোট পিং কাজ করলে আর বড় স্থানান্তর আটকে গেলে, টানেল ব্লক হচ্ছে না, খণ্ডিত হচ্ছে। PPP-এর ওপর PPTP সাধারণত 1450-এর কাছাকাছি MTU ও MRU চায়, আর সেগুলো 1500-এ রেখে দিলে এমন লিঙ্ক পাবেন যা হ্যান্ডশেক পার করে কিন্তু আসল পেলোডে ব্যর্থ হয়।

পরীক্ষা পাঁচ: ইন্টারনেট অ্যাক্সেস কী করবে তা ঠিক করুন

যে ক্লায়েন্টরা অফিসের মধ্য দিয়ে ব্রাউজ করবে তাদের WAN ইন্টারফেসের দিকে সোর্স অনুবাদ দরকার। যে ক্লায়েন্টদের শুধু LAN-এ পৌঁছাতে হবে তাদের একটি রুট আর কিছুই না দরকার। এগুলো আলাদা নিয়ত, আলাদা নিয়মসমূহ, আর মাস্কের প্রশ্নটি এই দ্বিতীয় সিদ্ধান্তটিকে সম্পূর্ণ ঢেকে রাখে। একটি নিয়ম যোগ করার আগেই লিখে রাখুন কোন আচরণ চেয়েছিলেন, কারণ অফিস লাইন দিয়ে অপ্রত্যাশিতভাবে বেরিয়ে যাওয়া ক্লায়েন্ট লগে নয়, মিটিংয়ে প্রকাশ পায়।

শেষ একটি কথা, সমাধানের সাথে সম্পর্কহীন: PPTP অপ্রচলিত এবং এর প্রমাণীকরণ বছরের পর বছর ধরে ভাঙা। উপরের তালিকা তবুও ব্যাখ্যা করে PPP লিঙ্ক কী করে, আর পরে ক্লায়েন্টদের আধুনিক টানেলে সরালেও একই যুক্তি প্রযোজ্য।