কেন আপনার পাবলিক Linux সার্ভিস বরং VPN দিয়ে উত্তর দেয়

সকেটে কিছুই মনে রাখে না কোন ইন্টারফেস অনুরোধটি বহন করেছিল, তাই ফুল-টানেল VPN-এর ডিফল্ট রুট WAN-এ যাওয়ার কথা থাকা উত্তরটিকে ধরে ফেলতে পারে। সার্ভিসটি ইনবাউন্ড ইন্টারফেসকে উপেক্ষা করছে না; Linux স্থানীয়ভাবে তৈরি উত্তরকে গন্তব্য ও উৎস নীতির ভিত্তিতে রুট করে। উৎস-ভিত্তিক নিয়ম বরং কেবল সার্ভিসের উত্তরগুলিকে সম্পূর্ণ WAN টেবিল দিয়ে পাঠাতে পারে, সাধারণ আউটবাউন্ড টানেলেই রেখে দেয়। উত্তরটি ভুল পথে বেরিয়ে গেলেও পোর্ট খোলা থাকে, তাই উপসর্গটি একতরফা দেখায়।

ভুল ধারণা: উত্তরগুলি যে ইন্টারফেস দিয়ে এসেছিল সেটি অনুসরণ করে

eth0-এ আসা প্যাকেট eth0 দিয়েই যাবে — এটি যুক্তিসঙ্গত মনে হয়। স্টেটলেস প্যাকেট ফিল্টার এভাবেই লেখা যায়, এবং ইনবাউন্ড দিকে tcpdump অনুরোধটি ঠিক যেখানে প্রত্যাশিত সেখানেই দেখায়। হোস্ট নিজে যে ট্র্যাফিক তৈরি করে তার জন্য রাউটিং এভাবে কাজ করে না।

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

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

কার্নেল আসলে কী রুট করে: উৎস ঠিকানা

আপনার যে হাতলটি দরকার তা হলো সার্ভিস উত্তরগুলির জন্য যে স্থানীয় ঠিকানা ব্যবহার করে সেটি। উদাহরণস্বরূপ eth0 ঠিকানা 192.0.2.10/24 ও গেটওয়ে 192.0.2.1 থাকা হোস্টে সেই ঠিকানাটি ইন্টারফেসে উপস্থিত থাকে। ক্লাউড VM-এ পাবলিক ঠিকানাটি উজানে অনূদিত হয়ে গেস্টে অনুপস্থিত থাকতে পারে, তাই হোস্ট সত্যিই যে ঠিকানাটি ধরে রাখে সেটিই ব্যবহার করুন।

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

অর্ধেক ডিফল্ট নয়, সম্পূর্ণ রিটার্ন টেবিল তৈরি করুন

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

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

ক্রমও গুরুত্বপূর্ণ। কম প্রাধান্য নম্বরের বিস্তৃত নিয়ম আগে মূল্যায়িত হয়, তাই এই ট্র্যাফিককে মূল টেবিলে ফেরত পাঠাতে পারত এমন যেকোনো নিয়মের আগে উৎস নিয়মে পৌঁছাতে হবে। যোগ করার পর ip rule show দিয়ে প্রাধান্যগুলি পরীক্ষা করুন, কেবল বুটেই নয়।

উৎস-নির্দিষ্ট লুকআপ দিয়ে যাচাই করুন

কার্নেলকে সার্ভিস ঠিকানা থেকে একটি পরীক্ষা গন্তব্যে রুট করতে বলুন। উত্তরে টানেল নয়, eth0 ও WAN গেটওয়ের নাম থাকা উচিত:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

চূড়ান্ত রুট ও নিয়মটি ইন্টারফেসের মালিক নেটওয়ার্ক ম্যানেজারের অধীনে রাখুন। ঠিকানা পরিবর্তন, DHCP নবায়ন ও VPN পুনঃসংযোগ সবই কার্নেলের অবস্থা পুনর্লিখন করে, এবং হাতে যোগ করা নিয়ম পরবর্তী ঘটনার পর হারিয়ে যায় বা পুরোনো গেটওয়ে দেখায়।

এই ব্যতিক্রম কোথায় থামে

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

এটি হোস্টের পাবলিক ঠিকানাকে ইন্টারফেসে দেখায়ও না। যখন উজানের NAT সেই ঠিকানার মালিক, তখন উত্তরটিকে এখনও সেই পথেই বেরোতে হবে যা ওই NAT প্রত্যাশা করে, তাই WAN টেবিলকে অনুমান করা পাবলিক রেঞ্জ নয়, মূল গেটওয়ে ও প্রিফিক্সের প্রতিফলন করতে হবে।

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

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