হোম রাউটারের পিছনে PPTP সার্ভার: আগে 1723 ও GRE ঠিক করুন
হোম রাউটারের পিছনে PPTP চালান: TCP 1723, IP প্রোটোকল 47, পাসথ্রু চেকবক্স ও MTU-এর হিসাব, আর কখন L2TP বা OpenVPN ভালো সমঝোতা।
হোম রাউটারের পিছনে PPTP দুইটি সম্পর্কহীন কারণে ব্যর্থ হয়, আর এগুলো গুলিয়ে ফেললে একটি সন্ধ্যা নষ্ট হয়। একটি ব্যর্থতা ফরওয়ার্ডিংয়ের ফাঁক: রাউটার TCP 1723 পার করে এবং IP প্রোটোকল 47 ফেলে দেয়, তাই ক্লায়েন্ট 619 ত্রুটিতে আটকে থাকে। অন্যটি আকারের সমস্যা: টানেল ওঠে, প্রমাণীকরণ শেষ হয়, তারপর একটি পূর্ণ আকারের প্যাকেট পার হতে হলে জমে যায়। এদের মধ্যে কোনটি আপনার আছে তা বের করাই প্রথম প্রকৃত ধাপ; বাকিটা আপনার রাউটার কী প্রকাশ করতে পারে তা তুলনা করে, কোন ব্র্যান্ড ভালো তা নয়।
দুই পরিবহন, আর তার মধ্যে একটিরই পোর্ট আছে
PPTP দুই পরিবহনে ভাগ হয়: TCP 1723-এ একটি নিয়ন্ত্রণ সংযোগ, আর উন্নত GRE-তে মোড়া PPP ফ্রেম, যা IP প্রোটোকল 47। GRE-এর কোনো পোর্ট নম্বর নেই, তাই 1723 পোর্ট ফরওয়ার্ড হিসাবে লেখা নিয়ম এটি ঢাকতে পারে না, ওয়েব ইন্টারফেস ক্ষেত্রটিকে যেভাবেই নাম দিক না কেন। ভোক্তা রাউটার সাধারণত প্রোটোকল নিয়মের বদলে PPTP পাসথ্রু নামের একটি চেকবক্স দেয়, আর সেই চেকবক্স দুইটি কাজ করে: এটি ফায়ারওয়ালের ভেতর দিয়ে প্রোটোকল 47 যেতে দেয় এবং NAT-কে GRE প্রবাহ অনুসরণ করতে শিখায়। লিনাক্স রাউটারে ওই কাজগুলো আলাদা মডিউল ও আলাদা নিয়ম, তাই অর্ধেক কনফিগার করা পাসথ্রুও কাজ করা নিয়ন্ত্রণ চ্যানেল দেয়। কিছু বদলানোর আগে কোন অর্ধেক উপস্থিত আছে তা জেনে নিন।
সার্ভারের নিজের ফায়ারওয়ালকেও রাউটারের ঠিকানা থেকে প্রোটোকল 47 অনুমোদন করতে হবে। যে হোস্ট ফায়ারওয়াল কেবল 1723/tcp গ্রহণ করে, সে LAN-এর ভেতর থেকেই 619 ত্রুটি পুনরুৎপাদন করে, ফলে ভাঙা ফরওয়ার্ড আর ভাঙা হোস্ট নিয়ম একই রকম দেখায়।
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'মডিউলগুলো না থাকলে sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre দিয়ে লোড করুন এবং লোড স্থায়ী করুন, কারণ যে রিবুট হেল্পারটি ভুলে যায় তা কাজ করা টানেলকে আবার 619 ত্রুটিতে ফিরিয়ে দেয়। ফরওয়ার্ড নিয়মের কেবল সার্ভারের ঠিকানার দিকে প্রোটোকল 47 গ্রহণ করা দরকার, পুরো LAN নয়। RFC 2637 সংজ্ঞা নিয়ন্ত্রণ ও তথ্য পথ আলাদা করে, তাই কোনো একক পোর্ট ফরওয়ার্ড স্ক্রিন PPTP-কে সম্পূর্ণ বর্ণনা করে না।
পাসথ্রু চেকবক্স নাকি স্পষ্ট প্রোটোকল নিয়ম
যে পাসথ্রু চেকবক্স কেবল ফায়ারওয়াল খোলে, তা কল শনাক্তকারী পুনর্লিখন করা ALG-দের চেয়ে সঠিকের কাছাকাছি। ফায়ারওয়ালের অর্ধেকটি পূর্বানুমেয়, কারণ প্রোটোকল 47 হয় গ্রহীত হয় নয় বাদ পড়ে, আর কাউন্টার বলে দয় কোনটি। পুনর্লিখনের অর্ধেকটাই প্রস্তুতকারকদের পার্থক্যের জায়গা, কারণ PPTP-র কল শনাক্তকারী প্রতিটি টানেলের জন্য আলাদা এবং যে NAT সেগুলো সম্পাদনা করে তাকে তার স্পর্শ করা প্রতিটি কল অনুসরণ করতে হয়। যখন একটি ক্লায়েন্ট সংযোগ করে আর দুইটি করে না, ALG-ই প্রথম সন্দেহভাজন।
1723-এর জন্য একটি গন্তব্য NAT নিয়ম-এরও মালিকানা সমস্যা আছে। যদি পুরোনো নিয়ম এখনো 1723 পাঠায় এমন হোস্টে যা সার্ভার চালানো বন্ধ করেছে, প্যাকেট বন্ধ পোর্টে পড়ে এবং রাউটারের নিজের PPTP সেবা উত্তর দেওয়া বন্ধ করে, যা ফায়ারওয়াল ব্যর্থতার মতো পড়া যায় কিন্তু আসলে পুরোনো লক্ষ্য। দ্বিতীয়টি যোগ করার আগে নিয়ম ও তার গন্তব্য পড়ুন। যে রাউটার নিজেই PPTP শেষ করে, সেখানে WAN নিয়মটি অন্তর্নির্মিত সেবার সাথে প্রতিযোগিতা করে, তাই 1723 ও প্রোটোকল 47-এর জন্য একজন মালিক বাছুন।
একই NAT-এর পিছনে দুই ক্লায়েন্ট সেই ক্ষেত্র যা সাধারণ ফরওয়ার্ডকে চতুর ফরওয়ার্ড থেকে আলাদা করে। কল শনাক্তকারী পুনর্লিখন না করে প্রোটোকল 47 ফরওয়ার্ড করা সাধারণত সেগুলো ঠিক করার চেষ্টা করা হেল্পারের চেয়ে ভালো আচরণ করে।
রাউটারকে দোষ দেওয়ার আগে টানেলের মাপ নিন
PPTP ব্যবহারয়োগ্য পেলোড সংকুচিত করে, আর এই সংকোচন রহস্য নয়, পাটিগণিত। প্রতিটি টানেল প্যাকেট একটি বাইরের IP হেডার, একটি উন্নত GRE হেডার, একটি PPP হেডার এবং এনক্রিপশন থাকলে একটি MPPE হেডার বহন করে। যখন পথটি ফলাফল ফ্রেম বহন করতে পারে না, ছোট প্যাকেট পার হয়, লগইন শেষ হয়, আর ফাইল স্থানান্তর বা TLS হ্যান্ডশেক প্রথমবার পূর্ণ আকারের প্যাকেট পাঠালেই সেশন থেমে যায়।
অনুমান না করে সংখ্যাটি বের করুন। উন্নত GRE-তে 8 বাইট লাগে, PPP-তে 4, MPPE-তে 4, আর বাইরের IP হেডারে 20, তাই টানেল যেকোনো পেলোডের আগেই 36 বাইট খায়। যে PPPoE WAN 1492-এ শেষ হয়, সেখানে সবচেয়ে বড় যে PPP MTU বসে তা হলো 1492 বিয়োগ 36, অর্থাৎ 1456। PPP অপশনে mtu ও mru ওই মানে সেট করুন এবং অবিভাজনকারী পিং দিয়ে আবার পরীক্ষা করুন।
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpdপিং পথ মাপে, টানেল নয়: 1464 বাইট পেলোড যোগ 28 বাইট IP ও ICMP হেডার ঠিক 1492 বাইটের একটি ফ্রেম ভরে। সেই পিং ব্যর্থ হলে সংখ্যাটি কমাতে থাকুন যতক্ষণ না তা পার হয়, তারপর ফলাফল থেকে 36 বিয়োগ করুন। পথের সীমার উপরে সেট করা টানেল MTU আকারের কোনো উল্লেখ নেই এমন লগ লাইন ছাড়াই জমে যাওয়া তৈরি করে।
একই রাউটারে PPTP, L2TP/IPsec বা OpenVPN
একই রাউটার তিনটি সাধারণ টানেলের যেকোনটি বহন করতে পারে, আর পার্থক্য হলো তাকে কী প্রকাশ করতে হয়। PPTP-র দুইটি ভিন্ন স্তরে দুইটি নিয়ম প্রয়োজন। IPsec-এর উপরে L2TP-র কী বিনিময়ের জন্য UDP 500 ও 4500 প্রয়োজন এবং NAT-T এহার্জন করে না বহন করলে পেলোডের জন্য প্রোটোকল 50 প্রয়োজন। OpenVPN-এর একটি UDP পোর্ট প্রয়োজন এবং কোনো হেল্পারই নাই।
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
L2TP কলামটি স্বয়ংক্রিয়ভাবে GRE-ই বন্ধুবত্শীল নয়। ESP হলো IP প্রোটোকল 50 এবং এরও পোর্ট নেই, তাই যে রাউটার প্রোটোকল 47 নিয়ে হিমশিম খায় সে একই কারণে প্রোটোকল 50 নিয়েও খাতে পারে। NAT-T আছে ESP-কে UDP 4500-এর ভেতরে মুড়তে, আর দুই প্রান্তই এটি সমর্থন করলে প্রোটোকল 50 নিয়মটি অপ্রয়োজনীয় হয়ে যায়। এটি প্রান্তগুলোর বৈশিষ্ট্য, রাউটারের PPTP চেকবক্সের নয়। দুইটির জন্যই নিয়ম লেখার আগে ক্লায়েন্ট আসলে কোন এনক্যাপসুলেশন নিয়ে সমঝোতা করেছে তা নিশ্চিত করুন।
OpenVPN হলো রাউটারের দিকে সবচেয়ে কম চলমান অংশের বিকল্প। একটি UDP পোর্ট, একটি ফরওয়ার্ড, কোনো সংযোগ-অনুসরণ হেল্পার নেই এবং কল শনাক্তকারীর কোনো পুনর্লিখন নেই। সমঝোতা হলো অন্তর্নির্মিত ডায়ালারের বদলে ইনস্টল করতে হয় এমন ক্লায়েন্ট, আর প্রায়ই এটিই PPTP আলোচনায় টিকে থাকার একমাত্র কারণ।
কী সারাবেন আর কী বদলাবেন
ফরওয়ার্ড ও MTU ঠিক করলে আপনি কাজ করা একটি টানেল পান, রাখার মতো একটি নয়। PPTP-র MSCHAPv2 প্রমাণীকরণ বছর বছর আক্রমণযোগ্য, আর কাজ করা টানেল এমন প্রমাণপত্র বহন করে যা অফলাইনে উদ্ধার করা যায়। দূরের ডিভাইস L2TP/IPsec বা OpenVPN চালাতে পারলে সারাইকে তারিখ দেওয়া অস্থায়ী ব্যবস্থা হিসাবে ধরুন।
সিদ্ধান্ত নির্ভর করে দূর প্রান্ত কী সমর্থন করে আর ব্যবস্থাটি কতদিন টিকতে হবে তার উপর। যে পুরোনো যন্ত্র কেবল PPTP বোঝে সে সারাই পায়; ক্লায়েন্ট ইনস্টল করতে পারে এমন সবকিছুই স্থানান্তরিত হয়।
টিকিট বন্ধ করার আগে নিশ্চিত করুন যে ক্লায়েন্ট লগইন নয়, বড় স্থানান্তর টিকে যায়, এবং রিবুটের পরেও রাউটার তার প্রোটোকল 47 নিয়ম ধরে রাখে। যে টানেল একটি ফাইল কপি পার হয়ে পরের ফার্মওয়্যার হালনাগাদের পর মরে যায়, সেটি কদোনোই শেষ হয়নি।