NAT-এর পিছনে WireGuard পিয়ারে পোর্ট ফরওয়ার্ডিং: DNAT ও SNAT
DNAT অনুরোধ পৌঁছে দেয়, কিন্তু উত্তর আসে ভুল ঠিকানা থেকে। একটি মিলে যাওয়া SNAT নিয়ম যোগ করুন এবং টানেল কনফিগার হওয়ার পরে দুটোই বসান।
একটি ব্রাউজার https://203.0.113.10:8443 অনুরোধ করে, প্রক্সি সংযোগ গ্রহণ করে, আর WireGuard পিয়ারের সার্ভিস কখনও উত্তর দেয় না। DNAT নিয়মটি তার কাজ করছে; ব্যর্থ হচ্ছে উত্তরটির অংশ। উভয় অনুবাদের মধ্য দিয়ে প্যাকেটটি অনুসরণ করুন, তাহলে অনুপস্থিত নিয়মটি স্পষ্ট হয়ে যাবে। সমাধান হলো সঠিক হুকে আরও একটি NAT বিবৃতি, নতুন টানেল নয়।
একটি অনুরোধ শুরু থেকে শেষ পর্যন্ত অনুসরণ করুন
অনুরোধটি প্রক্সির পাবলিক ইন্টারফেসে পৌঁছায়, উৎসে ক্লায়েন্টের পাবলিক ঠিকানা আর গন্তব্যে প্রক্সির ঠিকানা থাকে। nat PREROUTING-এ DNAT নিয়মটি গন্তব্যকে পিয়ারের টানেল ঠিকানা 10.90.0.2-তে পুনর্লিখন করে। এরপর রাউটিং সিদ্ধান্ত প্যাকেটটি wg0 দিয়ে বাইরে পাঠায়, এবং ফরওয়ার্ড পথ সম্পূর্ণ হয়।
পিয়ারে প্যাকেটটি এখন মূল পাবলিক উৎস ঠিকানা বহন করে, কারণ কিছুই তা পুনর্লিখন করেনি। সার্ভিসটি সংযোগ গ্রহণ করে এবং তার উত্তর নিজের ডিফল্ট গেটওয়েতে পাঠায়, যা পিয়ারের সামনের হোম রাউটার। সেই রাউটারের এমন প্রবাহের কোনো অবস্থা নেই যা সে কখনও দেখেনি, তাই সে হয় প্যাকেটটি ফেলে দেয়, নয়তো নিজের পাবলিক ঠিকানায় রূপান্তর করে, যা ক্লায়েন্ট গ্রহণ করবে না।
অসমতাই পুরো সমস্যা: অনুরোধ প্রক্সি দিয়ে যায়, আর উত্তর সরাসরি যাওয়ার চেষ্টা করে। প্রক্সির সংযোগ ট্র্যাকিং কেবল তখনই সাহায্য করে যখন উত্তর প্রক্সি দিয়ে ফিরে আসে, আর উৎস ঠিকানা মূল ক্লায়েন্টের দিকে থাকা পর্যন্ত তা সেখানে ফিরতে পারে না।
ফেরত রূপান্তর যোগ করুন
ফরওয়ার্ড করা প্রবাহের উৎসটি পিয়ারের দিকে যাওয়ার আগে প্রক্সির টানেল ঠিকানায় পুনর্লিখন করুন। এরপর সার্ভিসটি 10.90.0.1-এ উত্তর দেয়, প্রক্সি তা গ্রহণ করে, এবং প্যাকেটটি ক্লায়েন্টের কাছে ফেরার আগে সংযোগ ট্র্যাকিং উভয় রূপান্তর উল্টে দেয়।
iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1POSTROUTING নিয়মটি ইচ্ছাকৃতভাবে সংকীর্ণ: এটি রূপান্তরিত গন্তব্য ও টানেল ইন্টারফেসের সাথে মেলে, তাই wg0 দিয়ে বেরিয়ে যাওয়া অসম্পর্কিত ট্রাফিক পুনর্লিখন করে না। একটি প্রশস্ত masquerade নিয়ম ক্লায়েন্ট ঠিকানাটিও লুকাত, কিন্তু তা প্রতিটি প্রবাহের জন্য করত এবং NAT টেবিল নিরীক্ষা করা কঠিন করে তুলত।
টানেল যেখানে আছে সেখানে নিয়মগুলো বসান
টানেল ঠিকানা বা ইন্টারফেস উল্লেখ করে এমন নিয়ম অবশ্যই wg-quick তা কনফিগার করার পরে চলতে হবে। ইন্টারফেস PreUp-এর আগে তৈরি হয়, কিন্তু ঠিকানা, MTU, DNS ও রুট পরে প্রয়োগ হয়, আর PostUp সবকিছু জায়গায় থাকার পরে চলে। যোগগুলো PostUp-এ এবং মুছে ফেলাগুলো PreDown-এ রাখুন।
PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1মুছে ফেলা অবশ্যই যোগের সাথে টোকেনে টোকেনে মিলতে হবে, multiport ও ইন্টারফেস মিলসহ। এক মিলে ভিন্ন একটি মুছে ফেলা কিছুই মুছবে না, এবং পরের পুনঃসংযোগ নিয়মটির দ্বিতীয় কপি যোগ করবে। কয়েকবার পুনঃসংযোগের পরে টেবিলে ডুপ্লিকেট জমে যা কনফিগারেশন লাইনের সাথে সম্পর্কিত করা কঠিন।
ফলাফলটি iptables -t nat -S দিয়ে পুনঃসংযোগের পরে পরীক্ষা করুন। একই নিয়ম দুইবার দেখা গেলে PreDown লাইনটি মিলছে না এবং পরিষ্কার করা নিঃশব্দে ব্যর্থ হচ্ছে।
ফরওয়ার্ডিং, ফিল্টারিং ও অন্য NAT
IPv4 ফরওয়ার্ডিং স্থায়ীভাবে চালু করুন, তারপর ফিল্টার টেবিলে ফরওয়ার্ড করা প্রবাহ অনুমোদন করুন। DNAT FORWARD চেইনের আগে ঘটে, তাই ফিল্টার নিয়মটি পাবলিক ঠিকানার বদলে রূপান্তরিত গন্তব্যের সাথে মেলে। যদি UFW ফায়ারওয়াল পরিচালনা করে, অনুমতিটি রুট নিয়ম হিসেবে লিখুন; সাধারণ হোস্ট নিয়ম ফরওয়ার্ড করা ট্রাফিক কভার করে না।
প্রক্সির নিয়ম সঠিক থাকলেও আরও দুটি NAT স্তর পথ ভাঙতে পারে। হোম সংযোগে পাবলিক ঠিকানাটি রাউটারের, আর তার ফায়ারওয়ালে পোর্ট খোলা মানে সেই পোর্ট প্রক্সিতে পাঠানোর পোর্ট-ফরওয়ার্ড এন্ট্রি তৈরি করা নয়। বাইরে থেকে খোলা দেখানো কিন্তু কিছুই উত্তর না দেওয়া পোর্টে প্রায়ই ঠিক সেই ম্যাপিংটাই থাকে না।
NAT VPS-এ প্রোভাইডার একটি পাবলিক পোর্টকে প্রাইভেট ঠিকানায় ম্যাপ করে। ম্যাপিংটি আপনার ঘোষিত পোর্টের সাথে মিলতে হবে, আর অমিল ভাঙা টানেলের মতোই দেখায়। WireGuard কনফিগারেশন বদলানোর আগে প্রোভাইডারের ম্যাপিং নিশ্চিত করুন।
ফেরত পথ যাচাই করুন এবং খরচ মেনে নিন
প্রক্সির LAN নয় এমন নেটওয়ার্ক থেকে সংযোগ করুন, তারপর সংযোগ খোলা থাকা অবস্থায় রূপান্তর জোড়াটি পরীক্ষা করুন:
conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080conntrack এন্ট্রিতে মূল টাপল, রূপান্তরিত টাপল ও উত্তরের দিক দেখানো উচিত। উত্তর অনুপস্থিত থাকলে পিয়ার টানেল দিয়ে পাঠাচ্ছে না, যার অর্থ সাধারণত SNAT নিয়ম প্রযোজ্য হয়নি বা পিয়ারের নিজের ফায়ারওয়াল প্রবাহটি ফেলেছে।
PostUp নিয়মগুলো পুনরায় প্রয়োগ করে তা প্রমাণ করতে একবার রিবুট করুন, তারপর টানেল বন্ধ করুন এবং PreDown সেগুলো সরিয়েছে তা নিশ্চিত করুন। সংযোগ বিচ্ছেদের পরেও টিকে থাকা মৃত নিয়মই পরবর্তী পরিবর্তনকে অপ্রত্যাশিতভাবে আচরণ করানোর কারণ।
শেষে, SNAT-এর খরচ মেনে নিন। সার্ভিস প্রতিটি অনুরোধকে প্রক্সি থেকে আসা হিসেবে দেখে, তাই অ্যাক্সেস লগ, প্রতি-ক্লায়েন্ট রেট লিমিট ও ঠিকানা অনুমোদন তালিকা আর ব্যবহারকারীদের আলাদা করে না। হেয়ারপিন কেসটির জন্য প্রক্সির LAN-এর ক্লায়েন্টদের নিজস্ব উৎস রূপান্তর দরকার। পিয়ারের সত্যিকারের ক্লায়েন্ট ঠিকানা দরকার হলে বিকল্প হলো ক্লায়েন্ট নেটওয়ার্কে ফেরত রুট, যা বেশি কাজ কিন্তু তথ্য সংরক্ষণ করে।