StrongSwan যে DNS ঠিকানায় Mac পৌঁছাতে পারে না তা পাঠায়

সবকিছু কাজ করে যতক্ষণ না কেউ একটি MacBook খোলে। টানেল প্রতিষ্ঠিত হয়, অভ্যন্তরীণ হোস্ট ঠিকানা দিয়ে উত্তর দেয়, আর নাম রেজলিউশন মরে যায়। iPhone-এ একই প্রোফাইল একইভাবে আচরণ করে, অথচ Windows ও Linux ক্লায়েন্ট ঠিক আছে। সাধারণত পুশ করা DNS অ্যাট্রিবিউটই দোষী: সার্ভার তার নিজের সার্বজনীন ইন্টারফেস ঠিকানা বিতরণ করে, আর Apple-এর IKEv2 ক্লায়েন্ট টানেলের ভেতর দিয়ে সেখানে কোয়েরি পাঠায় না। রিজলভারটিকে পুলের ভেতরে সরান, আর ক্লায়েন্ট স্পর্শ না করেই উপসর্গটি মিলিয়ে যাবে।

উপসর্গটি পুশ করা ঠিকানার দিকেই ইঙ্গিত করে

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

সার্বজনীন ঠিকানাটি স্বাভাবিক পছন্দ কারণ প্রশাসক এটি আগেই জানেন। এটি একমাত্র ঠিকানা যা টানেলের নিজস্ব প্রিফিক্সের বাইরে থাকার নিশ্চয়তা দেয়, আর ঠিক এই বৈশিষ্ট্যই Apple ক্লায়েন্টগুলো ভেঙে দেয়।

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

লিজ রেঞ্জ থেকে রিজলভারটি কেটে নিন

টানেলকে এমন একটি ঠিকানা পরিকল্পনা দিন যেখানে রিজলভার পুলের নিজস্ব সাবনেটের সদস্য, তারপর সেই ঠিকানাটি সংরক্ষিত রাখুন যাতে কোনো ক্লায়েন্টকে কখনও তা লিজ দেওয়া না হয়। এই উদাহরণে পুল 10.180.7.0/24, সার্ভার 10.180.7.1 ধরে রাখে, আর লিজ শুরু 10.180.7.2 থেকে।

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

পুল প্রিফিক্স ও রিজলভার একই সাবনেট ভাগ করে, তাই যে রুট ইতিমধ্যে টানেল ট্রাফিক বহন করে সেটিই কোয়েরিও বহন করে। এই এক বৈশিষ্ট্যই সংশোধনটিকে ক্লায়েন্টজুড়ে বহনযোগ্য করে তোলে। swanctl কনফিগারেশনে একই দুটি তথ্য ipsec.conf সিনট্যাক্সের বদলে পুল সংজ্ঞা ও সংযোগে DNS সেটিং হিসেবে দেখা যায়।

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

রিজলভার বাইন্ড করুন এবং পোর্ট 53 বন্ধ করুন

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

এরপর ফায়ারওয়াল নিয়মকে রিজলভারের নিজস্ব অ্যাক্সেস কন্ট্রোলের সাথে মিলতে হবে। পুল থেকে পোর্ট 53 গ্রহণ করুন এবং বাকি সব জায়গা থেকে তা বর্জন করুন, কিন্তু আগে চেইনের ক্রম পরীক্ষা করুন।

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ক্লায়েন্ট আসলে কী পেয়েছে তা যাচাই করুন

আগে সার্ভারের দৃষ্টিভঙ্গি দেখুন, তারপর ক্লায়েন্টের, কারণ দুটি তথ্যপূর্ণভাবে মেলে না। পুল তালিকা দেখায় কোন ঠিকানা লিজ দেওয়া হয়েছে, আর সিকিউরিটি অ্যাসোসিয়েশন তালিকা দেখায় সংযোগটি প্রত্যাশিত পরিচয়সহ ওপরে আছে কি না।

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

সরাসরি কোয়েরি প্রমাণ করে রিজলভার পুল ঠিকানায় এমন এক হোস্ট থেকে উত্তর দেয় যা সেখানে পৌঁছাতে পারে। এটি প্রমাণ করে না যে Mac ওই সার্ভারকেই বেছে নিয়েছে। macOS-এ scutil --dns প্রতি স্কোপড সেবার রিজলভার তালিকা করে এবং সারসংক্ষেপ প্যানেলের চেয়ে বেশি তথ্য দেয়; Windows-এ Get-DnsClientServerAddress দেখায় টানেল অ্যাডাপ্টার পুশ করা মান গ্রহণ করেছে কি না।

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