Linux-এ IPsec ছাড়া L2TP: xl2tpd, pppd ও NAT

সাধারণ L2TP হলো একটি খামের ভেতরের PPP, আর কিছুই নয়। এটি আপনার ফ্রেম বহন করে; সেগুলো এনক্রিপ্ট করে না এবং অপর প্রান্তে কে বসে আছে তা প্রমাণ করে না, তাই প্রায় প্রতিটি ডিপ্লয়মেন্ট এর নিচে IPsec বসিয়ে দেয়। খালি সংস্করণ চালানোর সৎ কারণ এখনো আছে: একটি ল্যাব বেঞ্চ, একটি মাইগ্রেশন ধাপ, বা এমন লিংক যা ইতিমধ্যেই অন্য একটি সুরক্ষিত পথের ভেতরে।

যদি এগিয়ে যান, সেই সতর্কতা ডিজাইন নোটে লিখে রাখুন এবং ওখানেই রাখুন। এরপর যা আসছে তা Debian ও RHEL-পরিবারের হোস্টে আমি যে পরিচালন পথ ব্যবহার করি: কোন ফাইল কী সামলায়, যে MTU ক্লাসিক আটকে যাওয়া ঠেকায়, এবং যে ফরওয়ার্ডিং নিয়ম টানেলটিকে অর্থবহ করে।

তিনটি ফাইল কাজ ভাগ করে নেয়

xl2tpd নিয়ন্ত্রণ সংযোগ শেষ করে প্রতিটি সেশন একটি PPP ডেমনে হস্তান্তর করে, তাই কনফিগারেশন দুইটি প্রোগ্রামে ছড়িয়ে থাকে যা কখনো একে অপরের ফাইল পড়ে না। শোনা অংশটি থাকে /etc/xl2tpd/xl2tpd.conf-এ, [lns default] সেকশনের ভেতরে, যা ঠিকানা পুলকে ip range দিয়ে, সার্ভারের প্রান্তকে local ip দিয়ে এবং PPP-তে হস্তান্তরকে pppoptfile দিয়ে নাম দেয়। require authentication = yes চালু করুন, length bit ও flow bit সক্রিয় রাখুন, এবং এমন পুল বাছুন যা হোস্টে অন্য কিছু ইতিমধ্যে ব্যবহার করছে না।

PPP নীতি যে ফাইলের নাম ওই অপশন বলে সেখানেই থাকে, সাধারণত /etc/ppp/options.xl2tpd: auth, pap, chap ও mschap-এর জন্য অস্বীকৃতি, require-mschap-v2, 1460-এর MTU ও MRU, এবং লিংক ওঠার পর ক্লায়েন্ট যে DNS ঠিকানায় পৌঁছাতে পারে। ক্রেডেনশিয়াল আবার তৃতীয় ফাইল, /etc/ppp/chap-secrets, যেখানে দ্বিতীয় ফিল্ডকে LNS সেকশনের নামের সঙ্গে মিলতে হয় এবং চতুর্থ ফিল্ড পুল থেকে নির্দিষ্ট একটি ঠিকানা পিন করতে পারে।

কেন টানেল সংযুক্ত হয়ে থেমে যায়

1500 বাইটের একটি Ethernet ফ্রেম এমন পথে আঁটে না যা ইতিমধ্যেই নিজের হেডারেই বাইট খরচ করে। বাইরের IPv4 হেডার 20, UDP 8, আর L2TP হেডার প্রায় 12 নেয়, ফলে PPP ও তার পেলোডের জন্য 1460 থাকে। PPP-তে ওই ছোট সংখ্যাটি ঘোষণা করাই বড় প্যাকেটকে খণ্ডিত হওয়া বা মাঝপথে নীরবে ফেলে দেওয়া থেকে আটকায়।

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

একটি পোর্ট দুইটি কথোপকথন বহন করে

UDP 1701 প্রোটোকলের দুই অর্ধেরই নিচে বসে, আর এই একটি সত্যই সেটআপের অন্য যেকোনো অংশের চেয়ে বেশি ফায়ারওয়াল নিয়ম ভাঙে। প্রথমে আসে একটি শুরু-নিয়ন্ত্রণ-সংযোগ অনুরোধ ও তার উত্তর; এরপরের সেশন অনুরোধ ও নিশ্চিতকরণ শনাক্তকারী জোড়ার বেশি কিছু প্রতিষ্ঠা করে না। এরপর PPP দায়িত্ব নেয়: লিংক নিয়ন্ত্রণ, তারপর প্রমাণীকরণ, তারপর ঠিকানা ঠিক করতে IP নিয়ন্ত্রণ প্রোটোকল। লগে প্রতিটি ধাপের নিজস্ব শব্দভাণ্ডার আছে, এবং কোনোটিই নিজেকে L2TP ব্যর্থতা বলে ঘোষণা করে না।

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

টানেলকে কাজে লাগানো: ফরওয়ার্ডিং ও NAT

সেশন নিজে নিজে কেবল সার্ভার পর্যন্ত পৌঁছায়। ক্লায়েন্টের ইন্টারনেট অ্যাক্সেসের জন্য দরকার ফরওয়ার্ডিং, আপলিংকে পুলের জন্য NAT নিয়ম, এবং এমন DNS যা লিংক ওঠার পর ক্লায়েন্ট সত্যিই জিজ্ঞাসা করতে পারে। পুলটিকে LAN পরিসরের বাইরে থাকতেও হবে, নইলে ক্লায়েন্টদের উদ্দেশে পাঠানো উত্তর টানেলে ফেরত ঠেলার বদলে স্থানীয়ভাবে পৌঁছে দেওয়া হয়।

সার্ভারে sysctl -w net.ipv4.ip_forward=1 দিয়ে ফরওয়ার্ডিং চালু করুন, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE দিয়ে পুল অনুবাদ করুন, তারপর -i ppp0 -o eth0-এর জন্য FORWARD নিয়ম দিয়ে বাইরের টানেল ট্রাফিক এবং আয়না নিয়মের সঙ্গে -m state --state RELATED,ESTABLISHED দিয়ে ফেরত আসা ট্রাফিক গ্রহণ করুন। এই নিয়মগুলো রিবুটের পরেও রাখুন, কারণ সেগুলো ছাড়া ফিরে আসা সার্ভার দেখতে ঠিক ভাঙা L2TP কনফিগারেশনের মতোই লাগে।

সার্ভারের নিজের LAN-এ পৌঁছানো আলাদা কাজ: LAN রাউটারে পুলের জন্য ফেরত রুট যোগ করুন, অথবা সার্ভারে proxy ARP চালু করুন। LAN-এর ভেতরের কিছু যখন ক্লায়েন্টদের সরাসরি সম্বোধন করতে হবে, তখন তাদের NAT-এর পেছনে লুকানো কেবল পরে আরেকটি ডিবাগিং সেশন নির্ধারণ করে।

খালি স্ট্যাক কী করে না, এবং কীভাবে যাচাই করবেন

এই স্ট্যাকের কোনো অংশ PPP ফ্রেম এনক্রিপ্ট করে না, এবং এর ভেতরে কিছুই দূর প্রান্তকে আপনি সত্যিই যে সার্ভার বেছেছেন তা হিসেবে প্রমাণ করে না। MS-CHAPv2 কেবল নজর রাখা শ্রোতার থেকে ক্রেডেনশিয়াল বিনিময় রক্ষা করে, তবুও পথের মধ্যে অবস্থান করা আক্রমণকারী সেশনটিতে হস্তক্ষেপ করতে পারে। Windows-এর নেটিভ ক্লায়েন্ট L2TP কেবল IPsec-এর সঙ্গে দেয়, তাই Linux, রাউটার ফার্মওয়্যার ও তৃতীয় পক্ষের ক্লায়েন্টকে আপনার সমকক্ষ হিসেবে ধরে নিন। খালি কনফিগারেশনকে একটি নির্ণয়ের ধাপ হিসেবে দেখুন, কখনো থামার জায়গা হিসেবে নয়।

নির্দিষ্ট ক্রমে যাচাই করুন: xl2tpd -D সামনের দিকে চালান, PPP ধাপের জন্য জার্নাল দেখুন, দুই প্রান্তে ip addr থেকে বরাদ্দ ঠিকানা পড়ুন, তারপর সেশন ওঠার পর ডেটা প্রবাহিত হচ্ছে কি না নিশ্চিত করতে UDP 1701 ক্যাপচার করুন। চারটিই মিললে এবং ট্রাফিক এখনো ব্যর্থ হলে, দোষ রাউটিং, NAT বা MTU-তে, L2TP নিজে নয়।