L2TP, GRE নাকি IPsec: সেশন কোন স্তর বহন করবে?

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

প্রোটোকল তালিকা থেকে নয়, সেশন থেকে শুরু করুন

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

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

প্রতিটি স্তরকে ঠিক একটি কাজ দিন

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

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

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

কনফিগারেশনের আগে প্যাকেট-পথ লিখুন

একটি প্যাকেট নিন এবং যোগ হওয়া প্রতিটি হেডার যোগ হওয়ার ক্রমে তালিকাভুক্ত করুন, যে ডিভাইস যোগ করে তার নাম বলুন। ডায়াল-ইন ব্যবহারকারীর জন্য সাধারণত PPP, L2TP-এর ভেতরে এবং তা IPsec-এর ভেতরে; সাইট ওভারলের জন্য ভেতরের IP প্যাকেট GRE-এর ভেতরে এবং GRE, IPsec-এর ভেতরে। যদি দুটি ডিভাইস একই হেডার যোগ করে, তবে লুপ বা দ্বিগুণ টানেল আছে, এবং কোনো নীতি-সম্পাদনা তা সারাবে না।

একই তালিকা MTU ঠিক করে, কারণ ব্যবহারযোগ্য ভেতরের আকার হলো মাপা পাথ-MTU থেকে এইমাত্র গণনা করা হেডার বাদ দিয়ে যা থাকে, আর কিছু নয়। ফোরাম পোস্ট থেকে সংখ্যা কপি করবেন না: বাইরের IP, UDP ও ESP-এর ওভারহেড যোগ করুন, তারপর GRE বা L2TP, তারপর যেখানে প্রযোজ্য PPP, এবং আপনি সত্যিই যে পাথ-MTU মেপেছেন তা থেকে বিয়োগ করুন। যে লক্ষণ কেবল বড় স্থানান্তরে দেখা যায়, বা যে সেশন প্রতিষ্ঠিত হয়ে প্রথম বড় প্রতিক্রিয়ায় মারা যায়, তা সাধারণত এই যোগটি আন্দাজে করার দিকেই ফিরে যায়।

প্রতিটি স্তর আলাদাভাবে, বাইরে থেকে ভেতরে পরীক্ষা করুন

পরীক্ষাগুলো ক্রমে চালান এবং প্রথম ব্যর্থটিতে থামুন। প্রতিটি লাইন ভিন্ন প্রশ্নের উত্তর দেয়, তাই ব্যর্থতা টানেল খারাপ বলে জানানোর বদলে ওয়ার্কশিটের একটি কলামের দিকে ইশারা করে।

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco বক্সে সমতুল্যটি ভূমিকা-নির্ভর, এবং সঠিক সিনট্যাক্স প্ল্যাটফর্ম ও রিলিজের ওপর নির্ভর করে: IPsec পিয়ারদের জন্য show crypto session, GRE বা টানেল ইন্টারফেসের জন্য ইন্টারফেস কাউন্টার, এবং ডায়াল-ইন ভূমিকার জন্য VPDN বা PPP যাচাই। PPP শেষ করে এমন কমান্ড-সেট GRE সমর্থন সম্পর্কে কিছুই প্রমাণ করে না, এবং কাজ করা GRE ইন্টারফেস PPP সেবা সম্পর্কে কিছুই প্রমাণ করে না, তাই ডায়াগ্রামের ভূমিকা নয়, আপনি বাস্তবে যে ভূমিকা কনফিগার করেছেন তা যাচাই করুন।

প্রতিটি আউটপুট তার সম্পর্কিত ওয়ার্কশিট লাইনের পাশে লিখে রাখুন। ত্রুটি সক্রিয় থাকাকালীন নেওয়া নোট পরে স্মৃতি থেকে আবার আঁকা টপোলজির চেয়ে বেশি মূল্যবান।

টিয়ারডাউনের ক্রম সাজান, তারপর আবার যাচাই করুন

টিয়ারডাউন উল্টো ক্রমে একটি কারণে চলে: সুরক্ষিত ট্রাফিক IPsec নীতি থেকে বের করুন, যে এনক্যাপসুলেশনের জন্য নীতিটি লেখা তার অপসারণের আগে, নাহলে নীতি এমন একটি ইন্টারফেসের দিকে ইশারা করে থাকে যা আর নেই এবং পরের কনফিগারেশন লোড এমন জায়গায় ব্যর্থ হয় যা সম্পর্কহীন দেখায়। Linux-এ এর অর্থ হলো টানেল ইন্টারফেসের আগে state ও policy এন্ট্রি মোছা; রাউটারে টানেলের আগে crypto map বা profile এন্ট্রি সরানো।

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

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