স্বচ্ছ প্রক্সি DNAT: ফেরত পথটি কেন গুরুত্বপূর্ণ
কেন DNAT একটি অনুরোধ আলাদা প্রক্সিতে পৌঁছাতে পারে অথচ উত্তরটি গেটওয়ে এড়িয়ে সংযোগ ভেঙে দেয়, তা বুঝুন।
একটি পুনঃনির্দেশিত SYN Squid-এ পৌঁছাতে পারে, অথচ ক্লায়েন্ট তখনও সময়সীমা পায়। DNAT সেটআপে ফেরত প্যাকেটটিকেও অনুবাদ অবস্থার মালিক গেটওয়েতে পৌঁছাতে হবে।
এই কাল্পনিক LAN-টি দেখুন:
client 192.168.40.25 → gateway 192.168.40.1
DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directlyক্লায়েন্ট প্রথমে একটি ওয়েবসাইট ঠিকানায় সংযুক্ত হয়েছিল। DNAT-এর পরে প্রক্সি ক্লায়েন্টের উৎস দেখে এবং স্থানীয় সাবনেট রুট ব্যবহার করে সরাসরি উত্তর দিতে পারে। সেই উত্তর গেটওয়ের বিপরীত অনুবাদ এড়িয়ে যায় এবং প্রত্যাশিত ওয়েবসাইট ঠিকানার বদলে প্রক্সি ঠিকানা থেকে ক্লায়েন্টে পৌঁছাতে পারে। গেটওয়ে কখনও না পাওয়া প্যাকেট মেরামত করতে পারে না।
| পদ্ধতি | পরিণতি |
|---|---|
| প্রক্সির উত্তরগুলো অনুবাদকারী গেটওয়ে দিয়ে পাঠানো | আগত প্রক্সি সংযোগ ক্লায়েন্টের উৎস ঠিকানা ধরে রাখতে পারে |
| উপযুক্ত উৎস অনুবাদও প্রয়োগ করা | প্রক্সি গেটওয়েকে তার সমকক্ষ হিসেবে উত্তর দেয়, কিন্তু এখন মূল ক্লায়েন্টের বদলে সেই অনূদিত উৎস দেখে |
সুন্দর লগের জন্য SNAT সরাবেন না, আগে ফেরত পথ যাচাই করুন। ব্যাপকভাবে প্রয়োগ করলে উৎস ACL ও অ্যাট্রিবিউশনও বদলায়; সেই ফলাফলকে ডিজাইনের অংশ হিসেবে মেনে নিন।
একটি বিশ্বস্ত HTTP হপ ফরওয়ার্ডিং হেডারে ক্লায়েন্ট মেটাডেটা পাঠাতে পারে, কিন্তু NAT সেই হেডার তৈরি করে না বা এটিকে TCP পিয়ার পরিচয়ে বদলায় না। Squid-এ যাওয়া সংযোগে উৎস সংরক্ষণ করা Squid-এর আলাদা ওয়েবসাইট সংযোগেও তা সংরক্ষণ করে না।
পরিশেষে, ইন্টারসেপশন ডিজাইনকে এখনও Squid-এর প্রয়োজনীয় গন্তব্য তথ্য সরবরাহ করতে হবে। প্রতিসম ফেরত রাউটিং এই সময়সীমা প্রক্রিয়াটি সমাধান করে, সম্পূর্ণ স্বচ্ছ-প্রক্সি কনফিগারেশন নয়।