PPTP/MS-CHAPv2 অবসর: একটি পুরনো VPN-এর জন্য রানবুক

মাসিক ঘুরিয়ে ভল্টে রাখা বিশ অক্ষরের পাসওয়ার্ড MS-CHAPv2 চালানো একটি PPTP সার্ভারকে আধুনিক VPN-এ পরিণত করে না। পাসওয়ার্ড হলো এমন এক বিনিময়ের ইনপুট, যার দুর্বলতা ওই বিনিময়ের ভেতরেই থাকে। এই রানবুক তার জন্য, যে ওই সার্ভার উত্তরাধিকারসূত্রে পেয়েছে এবং তার ওপর নির্ভরশীল সাইটটি কাটা না দিয়ে ব্যবহারকারীদের সরিয়ে নিতে হবে। ধাপগুলো ক্রমে সম্পন্ন করুন, কারণ প্রতিটি একটি রেকর্ড রেখে যায়, যা কেউ জিজ্ঞেস করলে দরকার হবে কেন অ্যাক্সেস হঠাৎ বদলে গেল।

কিছু স্পর্শ করার আগে স্ট্যাকটা লিখে রাখুন

PPTP শব্দটিতে তিনটি স্তর একসাথে মিলিয়ে যায়, আর প্রতিটি নিজের মতো ব্যর্থ হয়। টানেল হলো PPTP নিজেই, GRE যোগ TCP 1723। প্রমাণীকরণ হলো সার্ভার যে PPP পদ্ধতি দেয়, এখানে MS-CHAPv2। লিংক সুরক্ষা হলো MPPE, যার কী ওই প্রমাণীকরণ বিনিময় থেকে উদ্ভূত। তিনটিরই নাম রাখলে পরের কোনো সংশোধন ভুল স্তরে গিয়ে পড়ে না।

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

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

Windows-এর রিমোট অ্যাক্সেস রোলে একই ইনভেন্টরি দুটি কমান্ড থেকে আসে, আর দ্বিতীয়টি গুরুত্বপূর্ণ, কারণ একটি রোল একসাথে কয়েকটি পদ্ধতির বিজ্ঞাপন দিতে পারে, অথচ মাঠের ক্লায়েন্টরা কেবল সবচেয়ে দুর্বলটিতেই সমঝোতা করে।

Get-VpnAuthProtocol
netstat -ano | findstr :1723

আজ টানেলটি আসলে কী বহন করে তা ঠিক করুন

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

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

MPPE একই দুর্বলতা উত্তরাধিকারে পায়, কারণ তার কী ওই বিনিময় থেকেই আসে, আর এটি আপনাকে আধুনিক AEAD সাইফারের প্যাকেটভিত্তিক অখণ্ডতা ও পুনরাবৃত্তি-আচরণ দেয় না। যে সেশন পরিষ্কারভাবে প্রমাণিত হয়, সে কেবল কনফিগার করা যাচাইয়ের সঙ্গে সামঞ্জস্য প্রমাণ করেছে, তার বেশি নয়।

না ছোট দুপুরের বিরতি, না অল্প ব্যবহারকারীর সংখ্যা কোনো ক্রিপ্টোগ্রাফিক বৈশিষ্ট্যকে নীতিগত বৈশিষ্ট্যে বদলায়।

একটি রক্ষণাবেক্ষণ উইন্ডোর মধ্যেই মাইগ্রেশন চালান

প্রতিস্থাপনটি দাঁড় করান, একটি পাইলট দল দিয়ে প্রমাণ করুন, তারপর পুরনো লিসেনারটি নীরব ব্যাকআপ হিসেবে রেখে না দিয়ে বন্ধ করুন। যে ব্যাকআপে এখনো সবাই পৌঁছাতে পারে তা মাইগ্রেশন নয়, আর এটি দুর্বল বিনিময়টি ঠিক তাদের জন্যই খোলা রাখে যারা কখনো বদলানোর কষ্ট করে না।

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

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

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

প্রতিস্থাপনটি PPTP-র কাজগুলো করে কি না যাচাই করুন

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

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

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

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

রোলব্যাক, প্রত্যাহার এবং আপনি যে রেকর্ড রেখে যান

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

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

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