PPTP সংযোগ হয় তারপর Linux NAT-এর পিছনে আটকে যায়: GRE হেল্পার

কেউ 1723 ফরোয়ার্ড করে, ক্লায়েন্ট সার্ভারে পৌঁছায়, প্রমাণীকরণ শুরু হয়, তারপর কোনো ত্রুটি ছাড়াই সবকিছু থেমে যায়। স্বাভাবিক সিদ্ধান্ত হলো ভুল পাসওয়ার্ড, তাই পাসওয়ার্ড তিনবার নতুন করে লেখা হয়। ফরোয়ার্ড ঠিক ছিল এবং শংসাপত্রও ঠিক ছিল। যা ভেঙেছে তা হলো এমন একটি দ্বিতীয় প্রোটোকল যা ফরোয়ার্ড কখনো ঢাকেনি, এবং একটি কার্নেল ডিফল্ট যা চুপচাপ এতে সাহায্য করা বন্ধ করে দিয়েছে।

ফরোয়ার্ড কখনোই সমস্যা ছিল না

পোর্ট-ফরোয়ার্ড নিয়ম TCP বা UDP ট্রাফিক বর্ণনা করে। এটি এমন পেলোড বর্ণনা করতে পারে না যা সেশনের মাঝপথে অন্য IP প্রোটোকলে চলে যায়, আর PPTP ঠিক তাই করে।

তাই সংযোগ আটকে যাওয়ার মুহূর্ত পর্যন্ত সুস্থ দেখায়। পোর্ট নিয়ম যে অংশ নিয়ন্ত্রণ করতে পারে সেটি সফল হয়েছে, আর যে অংশ নিয়ন্ত্রণ করতে পারে না সেটিই ব্যর্থ অংশ।

নিয়ন্ত্রণের জন্য TCP, ডেটার জন্য GRE

কলটি TCP 1723-এর ওপর নেগোশিয়েট হয়। এটি চালু হলে পেলোড GRE-তে চলে যায়, IP প্রোটোকল 47, যা আদৌ কোনো পোর্ট নম্বর বহন করে না। পোর্টভিত্তিক নিয়মের মেলানোর কিছু থাকে না।

GRE যা বহন করে তা হলো তার হেডারে একটি কল শনাক্তকারী, আর NAT অনুবাদককে সেই ক্ষেত্রটি দুই দিকেই সামঞ্জস্যপূর্ণভাবে পুনর্লিখন করতে হয়, নইলে সেশনের দুই অর্ধেক একে অপরের সঙ্গে মিলতে থাকে না। এক দিক পুনর্লিখিত আর অন্যটি না হলে এমন সেশন তৈরি হয় যা প্রমাণীকরণ করে তারপর প্রতিটি ডেটা প্যাকেট বাতিল করে। উপসর্গের চেহারা ঠিক এটাই: সাফল্য, তারপর নীরবতা।

PPTP ছাড়া খালি GRE-তে এমন পুনর্লিখনের দরকার নেই, তাই সাধারণ GRE টানেল এমন রাউটারের মধ্য দিয়ে কাজ করতে পারে যা একই পথে PPTP ক্লায়েন্টের জন্য ব্যর্থ হয়।

চারটি মডিউল আর একটি sysctl যা সেগুলো বন্ধ করেছিল

দুটি মডিউল ফ্রেমিং সামলায়, nf_conntrack_proto_gre এবং nf_nat_proto_gre। আরও দুটি কল শনাক্তকারী সামলায়, nf_conntrack_pptp এবং nf_nat_pptp। শেষেরটি লোড করলে নির্ভরতার মাধ্যমে বাকিগুলোও আসে, তাই মডিউল তালিকায় চারটিই দেখানো উচিত।

পুরোনো নির্দেশনা 2.6 যুগের ip_ প্রিফিক্স ব্যবহার করে। ওই কমান্ডগুলো কিছু না লোড করেও চলছে বলে মনে হতে পারে, তাই এক্সিট স্ট্যাটাসের বদলে লোড হওয়া তালিকা দেখুন।

শুধু লোড করা আর যথেষ্ট নয়। Linux 4.7 থেকে net.netfilter.nf_conntrack_helper sysctl-এর ডিফল্ট 0, যা নতুন ফ্লোর জন্য স্বয়ংক্রিয় হেল্পার অ্যাসাইনমেন্ট বন্ধ করে দেয়। একটি রাউটারে সব মডিউল থাকতে পারে এবং তবুও কিছুই অনুবাদ না করতে পারে। আবার মডিউল তালিকা দেখার আগে কার্যকর মানটি যাচাই করুন।

হয় স্বয়ংক্রিয় অ্যাসাইনমেন্ট আবার বৈশ্বিকভাবে চালু করুন, নয়তো যে ফ্লোগুলোর এটি দরকার সেগুলোতে হেল্পার যুক্ত করুন এবং বাকি সবকিছু অক্ষত রাখুন:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

দ্বিতীয় বিকল্পটিই পছন্দনীয়। এটি পুরো রাউটারজুড়ে স্বয়ংক্রিয় অ্যাসাইনমেন্ট আবার চালু করার বদলে আচরণটিকে PPTP ট্রাফিকে সীমাবদ্ধ করে।

পোর্টহীন প্রোটোকল খোলা

1723 অনুমোদনকারী ফায়ারওয়াল নিয়ম 47 নম্বর প্রোটোকল সম্পর্কে কিছুই বলে না। firewalld-এ ক্লায়েন্টের দিকে থাকা জোনে প্রোটোকলটি অনুমোদন করুন। সাধারণ iptables-এ ইনপুট চেইনে gre প্রোটোকল গ্রহণ করুন।

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

সংযোগের পরে আকারের সীমা

GRE একটি হেডার যোগ করে, আর ভেতরের PPP আরও যোগ করে, তাই কাজ করা লিংক 1500-এর অনেক নিচে MTU জানায়। ছোট উত্তর লোড হয় আর বড়গুলো আটকে যায়, যা প্রথম সমস্যা সমাধানের মুহূর্তেই দেখা যাওয়া দ্বিতীয়, অসংশ্লিষ্ট সমস্যার মতো মনে হয়।

ক্লায়েন্টের PPP অ্যাডাপ্টারে MTU পড়ুন এবং রাউটারের নিজের হিসাবের সঙ্গে মিলিয়ে নিন কিছু কাজ না করা পর্যন্ত সংখ্যা কমানোর বদলে। পূর্ণ আকারের প্যাকেট বেরিয়ে কিছু ফিরে না এলে তা অনুবাদের দিকে নয়, ওই সীমার দিকে ইঙ্গিত করে।

পথ মেরামত করলে ব্যবহারকারী কাজে ফেরেন, আর এতে PPTP ভালো পছন্দ হয়ে যায় না। MS-CHAPv2 ও RC4 বহুদিন আগেই বাতিল হয়েছে, তাই মডিউল লোড করাকে সাময়িক সমাধান ধরে নিন এবং রক্ষণাবেক্ষণকৃত প্রোটোকলে যাওয়ার পরিকল্পনা করুন।