pptpd-এ GRE লেখার ব্যর্থতা পাসওয়ার্ডের সমস্যা নয়

লগে GRE লেখার ব্যর্থতা, আর প্রথম প্রবৃত্তি হলো ব্যবহারকারীর পাসওয়ার্ড রিসেট করা। এই প্রবৃত্তি প্রায় সবসময়ই ভুল। এই বার্তাগুলো ক্রেডেনশিয়াল যাচাই নয়, ডেটা পথ বর্ণনা করে: ক্লায়েন্ট হয়তো সফলভাবে প্রমাণীকরণ করেছে এবং তারপর নেটওয়ার্কে নিবন্ধনের ধাপে আটকে গেছে। দুটি আলাদা বার্তা দুটি আলাদা ত্রুটি নির্দেশ করে, এবং কোনোটিই নতুন পাসওয়ার্ডে সমাধান হয় না।

দুটি বার্তা, দুটি আলাদা ত্রুটি

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

লেখার ব্যর্থতা সাধারণত মানে সেশন এমন কিছু নিয়ে সমঝোতা করেছে যা কার্নেল বা ক্লায়েন্ট ব্যবহার করতে পারে না। কন্ট্রোল চ্যানেল সম্পন্ন হয়েছে, এবং সেই বিনিময়ে সম্মত অপশনগুলো প্রান্তবিন্দুগুলো আসলে যা করতে পারে তার সঙ্গে মেলে না। এটি কনফিগারেশন অমিল, প্রমাণীকরণের ঘটনা নয়।

কিছু পরিবর্তনের আগে দেখুন দুটির মধ্যে কোনটি দেখা যাচ্ছে। তারা আপনাকে আলাদা স্তরে পাঠায়, আর তাদের একই উপসর্গ হিসেবে দেখা হলো একই সার্ভারকে অসম্পর্কিত কারণে দুবার প্যাচ করার কারণ। লগ লাইনই একমাত্র বিনামূল্যে ডায়াগনস্টিক যা আপনি পান।

প্রোটোকল 47 পোর্ট 47 নয়

PPTP কল সেটআপ করতে TCP 1723 এবং পেলোড বহন করতে GRE ব্যবহার করে। GRE হলো IP প্রোটোকল 47, পোর্ট নম্বর নয়, তাই যে ফায়ারওয়াল নিয়ম পোর্ট 47 খোলে তা কার্যকর কিছু অনুমোদন করে না।

পথের রাউটারের PPTP passthrough বৈশিষ্ট্য বা স্পষ্ট GRE অনুমোদন দরকার। তা ছাড়া TCP হ্যান্ডশেক সম্পন্ন হয় এবং টানেল কখনো প্যাকেট বহন করে না, যা ঠিক উপরের পড়ার ব্যর্থতা তৈরি করে। ফায়ারওয়ালে পোর্ট 47 নিয়ম এই প্রোটোকলে সবচেয়ে বেশি নষ্ট হওয়া বিকেল।

কোন পক্ষ ট্রাফিক ফেলে দিচ্ছে তা অনুমান না করে সার্ভারে একসঙ্গে দুই দিক দেখুন: tcpdump -ni any port 1723 or proto gre।

যদি 1723 কল সেটআপ দেখায় আর GRE নীরব থাকে, ব্লকটি হোস্টের উপরে। যদি GRE আসে আর ডেমন তখনও ব্যর্থ হয়, সমস্যা স্থানীয় এবং অপশনগুলোই পরের দেখার জায়গা।

যেখানে হোস্ট সত্যিই ফরওয়ার্ড করে সেখানে GRE অনুমোদন করুন

GRE-এর জন্য ফরওয়ার্ড নিয়ম যোগ করা টানেল ট্রাফিক ফরওয়ার্ড করে এমন হোস্টে যুক্তিসঙ্গত পরীক্ষা, এবং এটি নীতি নয়। একটি প্রোটোকলের সবকিছু গ্রহণ করে এমন পরীক্ষামূলক নিয়ম ডায়াগনস্টিক, নকশা নয়। কিছু শেখার মতো যথেষ্ট সময় রাখুন, তারপর এটি সীমিত নিয়ম দিয়ে প্রতিস্থাপন করুন।

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

প্রতিটি রিবুটের পরে আবার চালানোর বদলে ডিস্ট্রিবিউশনের ফায়ারওয়াল সেবার মাধ্যমে নিয়মটি সংরক্ষণ করুন। nftables হোস্টে ইনপুট ও ফরওয়ার্ড দুই চেইনেই ip protocol gre মেলান।

নিশ্চিত করুন ppp_generic মডিউলও লোড হয়েছে, এবং দেখুন কানেকশন ট্র্যাকিং ফেরার দিকটি ফেলে দিচ্ছে কি না। দুটোই ফায়ারওয়াল সমস্যার মতো দেখানো ব্যর্থতা তৈরি করে, অথচ তা নয়। অনুপস্থিত কার্নেল মডিউল যাচাই না করা পর্যন্ত ঠিক ব্লক করা প্রোটোকলের মতো দেখায়।

আপনার কাছে যে ক্লায়েন্ট সত্যিই আছে তার সঙ্গে অপশন মিলান

অন্য প্রতিবেদনের সমাধান /etc/ppp/pptpd-options-এ, যেখানে রেসিপিটি PAP, CHAP ও MSCHAP প্রত্যাখ্যান করে, সংশ্লিষ্ট require লাইন মন্তব্য করে এবং স্টেটফুল MPPE রাখে। সেই রেসিপি এক ক্লায়েন্ট মিশ্রণের জন্য লেখা, এবং অন্ধভাবে কপি করলে সাধারণ ক্ষেত্রটি ভাঙে। প্রত্যাখ্যানের লাইনগুলো সুপারিশ নয়, বরং লেখকের কাছে কোন ক্লায়েন্ট ছিল তার বিবৃতি হিসেবে পড়ুন।

Windows ক্লায়েন্টের সাধারণত MS-CHAPv2 সহ MPPE-128 দরকার। এই চাহিদাগুলো রাখুন এবং শুধু সেই অপশনগুলো সরান যা ক্লায়েন্ট সত্যিই সমঝোতা করতে পারে না।

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

সংযোগ সফল করতে এনক্রিপশন বন্ধ করা হলো অবনমন, মেরামত নয়। এমন বৈচিত্র্য ল্যাব লিংকে পরীক্ষা করুন, তারপর সেবা প্রকৃত ক্লায়েন্টের সামনে যাওয়ার আগে এনক্রিপশন ফিরিয়ে দিন। অনিরাপদভাবে কাজ করা সংযোগ সৎভাবে ব্যর্থ হওয়া সংযোগের চেয়ে খারাপ।

ক্লায়েন্টের ত্রুটি নম্বর পড়ুন

ক্লায়েন্টের সংখ্যাসূচক কোড সার্ভার লগের চেয়ে দ্রুত ধাপটি সংকুচিত করে। অন্য কিছু পড়ার আগে এটি পড়ুন। 691 মানে ক্রেডেনশিয়াল প্রত্যাখ্যাত, 721 মানে সার্ভার কখনো উত্তর দেয়নি, আর 619 মানে সংযোগ কেটে গেছে। নম্বরসহ দুই মিনিট কনফিগারেশনে এক ঘণ্টা বাঁচায়।

কিছু সম্পাদনার আগে সেই কোড সার্ভার লগের সঙ্গে মিলিয়ে দেখুন, এবং প্রতিটি পরিবর্তনের পরে একই ক্লায়েন্ট দিয়ে আবার পরীক্ষা করুন। নইলে দ্বিতীয় ত্রুটি প্রথমটির পিছনে লুকায় আর সমাধান অকার্যকর দেখায়।

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