কেন Access Server ক্লায়েন্টরা LAN থেকে পৌঁছানো যায় না

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

সার্ভিস যে সোর্স ঠিকানা দেখে সেটি পড়ুন

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

একটাই পুল ধরে নেবেন না। একটি সার্ভারে ডাইনামিক রেঞ্জের সঙ্গে প্রতি-ব্যবহারকারীর স্ট্যাটিক ম্যাপিং থাকতে পারে, এবং স্ট্যাটিক ঠিকানা ডাইনামিক প্রিফিক্সের সম্পূর্ণ বাইরে থাকতে পারে। আপনি যদি কেবল স্মরণে থাকা রেঞ্জটাই রাউট করেন, তবে নির্দিষ্ট ঠিকানার ব্যবহারকারীরা ভাঙা থাকে আর বাকিরা সমস্যাটি সমাধান হয়েছে বলে জানায়।

যেখানে উত্তরের ভাগ্য নির্ধারিত হয় সেখানে রাউট যোগ করুন

রাউটটি সেই গেটওয়েতে যেতে হবে যা অভ্যন্তরীণ সার্ভিস আগেই ব্যবহার করে, সার্ভিসে নয়, যদি না সার্ভিস নিজেই তার ট্রাফিক রাউট করে। এটি Access Server-এর প্রাপ্য প্রাইভেট ঠিকানার দিকে নির্দেশ করুন, যা ক্লায়েন্টের ধরে রাখা টানেল ঠিকানা থেকে আলাদা মান।

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

ফরওয়ার্ডিং ও ফিল্টারকে রাউটের সঙ্গে একমত হতে হবে

রাউটিং পথের কেবল অর্ধেক। সার্ভারকে টানেল ও প্রাইভেট ইন্টারফেসের মধ্যে ফরওয়ার্ড করার অনুমতি দিতে হবে, যার মানে লিনাক্সে net.ipv4.ip_forward এবং এমন ফরওয়ার্ড চেইন যা ইন্টারফেস জোড়াকে অনুমতি দেয়, আর শক্তিশালী হোস্টে সাধারণত প্রতিটি দিকের জন্য আলাদা স্পষ্ট নিয়ম।

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

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

অসামঞ্জস্যপূর্ণ ফিরতি পথ একই সমস্যার নিঃশব্দ সংস্করণ। যদি পুলে দুটি রাউট পৌঁছায় এবং উত্তরটি এমন ইন্টারফেস দিয়ে বেরোয় যা অনুরোধ আসার ইন্টারফেস থেকে আলাদা, তবে কঠোর রিভার্স-পাথ ফিল্টারিং সেটি ফেলে দেয় এবং প্রবাহ কেবল কিছু ক্লায়েন্টের জন্য ব্যর্থ হয়।

রাউটেড বা মাস্কারেড: সচেতনভাবে বাছুন

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

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

ক্লায়েন্টের পেছনের সাবনেট আলাদা কাজ

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

দিকও একটি নীতি প্রশ্ন। ক্লায়েন্টকে অভ্যন্তরীণ সার্ভিসে সংযোগ খোলার অনুমতি স্বয়ংক্রিয়ভাবে অভ্যন্তরীণ হোস্টকে ওই ক্লায়েন্টে সংযোগ খোলার অনুমতি দেয় না। পথটি ভাঙা বলে সিদ্ধান্তে পৌঁছানোর আগে সার্ভারের অ্যাক্সেস নীতি ও ক্লায়েন্টের হোস্ট ফায়ারওয়াল দেখুন।

এক প্রবাহ ও এক ক্যাপচার দিয়ে যাচাই করুন

সাধারণ রিচেবিলিটি পরীক্ষার বদলে একটি সংযোগ দিয়ে পথটি প্রমাণ করুন। দুই প্রান্তে একই প্রবাহ দেখুন: সার্ভিসে আসা অনুরোধ আর তা থেকে বেরোনো উত্তর।

tcpdump -ni any host 10.90.0.25 and port 443

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

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