Docker-এ PPTP প্রমাণীকরণ হয় কিন্তু কোনো ট্রাফিক বহন করে না

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

পাঁচটি পরীক্ষা, যে ক্রমে সবচেয়ে বেশি সময় বাঁচে।

পরীক্ষা 1: নিয়ন্ত্রণ চ্যানেলকে পেলোড থেকে আলাদা করুন

PPTP TCP 1723-এর মাধ্যমে প্রমাণীকরণ করে এবং তারপর PPP পেলোড GRE-এর ভিতরে বহন করে, IP প্রোটোকল 47। GRE কোনো TCP বা UDP নয়, তাই নিয়ন্ত্রণ পোর্ট ফরওয়ার্ড করা প্রতিটি নিয়ম এ সম্পর্কে কিছুই বলে না। যে NAT বা ফায়ারওয়াল 1723 পাস করে সে প্রোটোকল 47 কোনো অভিযোগ ছাড়াই ফেলে দিতে পারে, আর সেশনটি অর্ধ-নির্মিত অবস্থায় থাকে যা সফলতার মতো দেখায়।

যদি লগইন কাজ করে আর কোনো প্যাকেট ফিরে না আসে, আগে GRE ধরে নিন, পরে তা প্রমাণ করুন।

পরীক্ষা 2: হোস্ট কার্নেলে হেল্পার নিশ্চিত করুন

সংযোগ ট্র্যাকিং কোনো হেল্পার ছাড়া TCP নিয়ন্ত্রণ সংযোগকে GRE প্রবাহের সঙ্গে যুক্ত করতে পারে না। মডিউলটি nf_conntrack_pptp, এটি হোস্ট কার্নেলে থাকে, আর কন্টেইনার ইমেজের ভিতরে এটি লোড করলে কিছুই হয় না কারণ মডিউলগুলো পুরো হোস্টে প্রযোজ্য। Docker হোস্টে lsmod | grep nf_conntrack_pptp হলো পরীক্ষা। যদি এটি না থাকে, modprobe nf_conntrack_pptp চলমান কার্নেলের জন্য এটি লোড করে এবং পরের বুট সম্পর্কে কিছুই বলে না, তাই এটিও হোস্ট কনফিগারেশনে যোগ করুন।

রিবুটে হারিয়ে যাওয়া মডিউল পরের মাসে একই টিকিট হয়ে দাঁড়ায়।

পরীক্ষা 3: যে কার্নেল নীতি এটিকে বন্ধ করে তা পড়ুন

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

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

পরীক্ষা 4: কন্টেইনারের পথটি আলাদাভাবে দেখুন

লোড করা হেল্পার কোনো রুট তৈরি করে না। কন্টেইনারের PPTP সার্ভারের পথ দরকার, আর হোস্ট ফরওয়ার্ডিংকে দুই দিকেই GRE অনুমোদন করতে হবে: iptables -L FORWARD -v -n দেখায় প্রোটোকল 47 গ্রহণ করা হয় কি না এবং কাউন্টার নড়ে কি না। Docker masquerade নিয়ম TCP আর UDP অনুবাদ করে, প্রোটোকল 47 নয়, তাই ব্রিজড কন্টেইনারের স্পষ্ট forward অনুমোদন এবং কিছু হোস্টে নিজস্ব অনুবাদ নিয়ম লাগতে পারে। এটিও নিশ্চিত করুন যে কন্টেইনারে তার ইমেজ যে PPP ডিভাইস সমর্থন আশা করে তা আছে।

নিয়মের লেখা নয়, কাউন্টার পড়ুন। যে নিয়ম আছে কিন্তু কিছুর সঙ্গে মেলে না, সেটি সাজসজ্জা।

পরীক্ষা 5: GRE ট্র্যাক হচ্ছে কি না প্রমাণ করুন, তারপর PPTP নিয়ে সিদ্ধান্ত নিন

ক্লায়েন্ট চালু থাকা অবস্থায় ট্র্যাকিং টেবিল পড়ুন। একটি প্রতিষ্ঠিত PPTP নিয়ন্ত্রণ এন্ট্রি সঙ্গে সম্পর্কিত GRE এন্ট্রি মানে হেল্পার প্রবাহগুলো যুক্ত করছে আর বাকি ত্রুটি অন্যত্র। GRE এন্ট্রি ছাড়া নিয়ন্ত্রণ এন্ট্রি মানে পেলোড ফেলা হচ্ছে বা ট্র্যাক হচ্ছে না, যা আপনাকে পরীক্ষা 2 ও 3-এ ফিরিয়ে নেয়।

PPTP নিজেই পুরনো আর MS-CHAPv2 দুর্বল। সার্ভার যদি L2TP/IPsec, IKEv2 বা WireGuard-ও দেয়, তবে তাদের একটিতে যাওয়া এই পুরো শ্রেণির সমস্যা সরিয়ে দেয়।

যেখানে PPTP থাকতেই হবে, সেখানে কন্টেইনারের ভিতরে নয়, হোস্টে ক্লায়েন্ট চালানো NAT আর ফিল্টারিংয়ের একটি স্তর সরিয়ে দেয়, যা প্রায়ই সস্তা সিদ্ধান্ত।