নির্ধারিত ভার্চুয়াল IP-তে IKEv2 ক্লায়েন্টে পৌঁছানো

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

টানেল উৎস ঠিকানা ঠিক করে না

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

ক্লায়েন্টের দিকে রাউটিং প্রয়োজনীয়, যথেষ্ট নয়। নীতিকে আপনার প্রকৃত ব্যবহৃত উৎসটি গ্রহণ করতে হবে।

ইনস্টল করা নীতি পড়ুন, কনফিগ ফাইল নয়

সক্রিয় অ্যাসোসিয়েশন ও তার সিলেক্টর থেকে শুরু করুন, কারণ গতিশীল নির্ধারণ কার্নেলে যা ইনস্টল আছে তা বদলে দেয়।

ipsec statusall
ip xfrm policy

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

ক্লায়েন্টকে প্যাকেট যেখানে পৌঁছায় সেখানেই শুনতে হবে

নিখুঁত নীতিও একটি বন্ধ পোর্টে পৌঁছায় যখন সেবাটি কেবল লুপব্যাকে বাঁধা থাকে। শ্রোতাকে নির্ধারিত ঠিকানায় বা একটি ওয়াইল্ডকার্ড স্থানীয় ঠিকানায় থাকতে হবে।

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

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

ক্লায়েন্ট-থেকে-সার্ভার একটি কার্যকর অনুরোধ কখনও এই পথটি পরীক্ষা করে না। গেটওয়ে থেকে অনুরোধ তৈরি করুন এবং দুই প্রান্তই পর্যবেক্ষণ করুন।

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

কী পরিবর্তন বা পুনঃসংযোগের পরে পরীক্ষাটি পুনরাবৃত্তি করুন, কারণ VIP বদলাতে পারে। যে পথ কেবল পরবর্তী সেশন পর্যন্ত কাজ করে সেটি কার্যকর পথ নয়।