127.0.0.1-এ DNAT কেন বিশেষ যত্ন প্রয়োজন
বাহ্যিক ট্রাফিক লুপব্যাক-বদ্ধ প্রক্সি উপাদানে পুনর্নির্দেশ করার সময় route_localnet বুঝুন।
একটি পরিষেবা 127.0.0.1:1080-এ শোনে। একটি DNAT নিয়ম আগত ট্রাফিককে ওই ঠিকানায় পাঠায়, তবুও সংযোগটি ব্যর্থ হয়। পরিষেবাটি সুস্থ থাকতে পারে এবং NAT নিয়মটি মিলতে পারে: IPv4 লুপব্যাক ঠিকানার জন্য রাউটিংয়ে বিশেষ আচরণ রয়েছে।
লিনাক্সের route_localnet নিয়ন্ত্রণ করে রাউটিংয়ের সময় 127/8 ঠিকানাকে মার্শিয়ান ঠিকানা হিসেবে গণ্য করা হবে কি না। এর ডিফল্ট মান স্বাভাবিক লুপব্যাক সীমা বজায় রাখে। নির্দিষ্ট ইন্টারফেসের জন্য একটি ব্যতিক্রম ইচ্ছাকৃত স্থানীয় পুনর্নির্দেশ নকশার জন্য প্রাসঙ্গিক হতে পারে।
এটি ব্যাখ্যা করে কেন অন্য মেশিনের কাজ করা নিয়ম আপনার না-কপি-করা কোনো sysctl-এর উপর নির্ভর করতে পারে। তবে এটি সর্বত্র অপশনটি চালু করার যৌক্তিকতা দেয় না।
নিরাপত্তার অনুমান পথের সঙ্গে বদলায়
লুপব্যাক বাইন্ডিং প্রায়ই ব্যবহৃত হয় কারণ একটি সহায়ক উপাদানের স্বতন্ত্র ক্লায়েন্ট প্রমাণীকরণ থাকে না। যদি অন্য ইন্টারফেস থেকে আসা ট্রাফিক সেখানে রাউট করা যায়, তবে কেবল বাইন্ড ঠিকানাই আর পৌঁছানো যায় এমন শ্রোতাকে বর্ণনা করে না। প্রকৃত নিয়মসমষ্টিতে প্রবেশ উৎস, গন্তব্য ও পোর্ট সীমিত করুন, এবং প্রযোজ্য হলে লুপব্যাক উৎস বা গন্তব্য ঠিকানা দাবি করা ট্রাফিকও অন্তর্ভুক্ত করুন।
পরিষেবাটি ধারণ করা নেটওয়ার্ক নেমস্পেস পর্যালোচনা করুন। কন্টেইনারের লুপব্যাক হোস্টের লুপব্যাক নয়, এবং হোস্ট ইন্টারফেসের সেটিং বদলালে কন্টেইনারে স্বয়ংক্রিয়ভাবে শ্রোতা তৈরি হয় না।
rp_filter উৎস-পথ যাচাইয়ের একটি ভিন্ন প্রশ্নের উত্তর দেয়। এটি বিশ্বব্যাপী বন্ধ করা লুপব্যাক রাউটিং বোঝার সাধারণ বিকল্প নয়। একইভাবে ip_nonlocal_bind সকেটকে অস্থানীয় ঠিকানায় বাঁধার বিষয়ে, এই DNAT পথটিকে সঠিক করার বিষয়ে নয়।
শেষে, পুনর্নির্দেশিত প্রোটোকলকে শ্রোতার সঙ্গে মানানসই হতে হবে। SOCKS পোর্টে কাঁচা HTTP বা TLS ট্রাফিক পাঠালেও অনুবাদক প্রয়োজন; রাউটিং ব্যতিক্রম অনুপস্থিত দর-কষাকষি যোগাতে পারে না।