অন্য NAT যোগ করার আগে প্রাইভেট LAN-গুলির মধ্যে রাউটিং করুন
ওভারল্যাপিং ঠিকানা পরিসর, অনুপস্থিত রিটার্ন রুট বা অবিশ্বস্ত ট্রানজিট রাউটিং, NAT ও টানেলের মধ্যে সিদ্ধান্ত নেয়। ফায়ারওয়াল সম্পাদনার আগে এই তিনটি যাচাই করুন।
দুটি অভ্যন্তরীণ ফায়ারওয়াল, একটি প্রাইভেট ট্রানজিট সেগমেন্ট, এবং প্রতিটি LAN-এর কয়েকটি হোস্টকে অন্যটির সঙ্গে কথা বলার অনুমতি দেওয়ার অনুরোধ। স্বাভাবিক প্রতিক্রিয়া হলো একটি VPN দাঁড় করানো বা দ্বিতীয় NAT স্তর যোগ করা, আর দুটিই সমস্যার যোগ্যতার চেয়ে বেশি খরচ করে। সাধারণ রাউটিংই যথেষ্ট যখন তিনটি শর্ত পূরণ হয়: ঠিকানা পরিসর ওভারল্যাপ করে না, দুই পক্ষই অন্য LAN-এ ট্রাফিক ফেরত দিতে পারে, এবং ট্রানজিট সেগমেন্ট ডেটার জন্য যথেষ্ট বিশ্বস্ত। কিছু ডিজাইন করার আগে এই তিনটি যাচাই করুন, কারণ প্রতিটি উত্তর বদলে দেয়।
ডিজাইন নির্ধারণকারী তিনটি শর্ত
প্রথম শর্ত ঠিকানা স্থান। যদি দুই LAN একই RFC 1918 ব্লক ব্যবহার করে, রাউটিং তাদের আলাদা করতে পারে না এবং অনুবাদ অনিবার্য হয়ে ওঠে, ঐচ্ছিক নয়। দ্বিতীয়টি রিটার্ন পাথ: A থেকে B-তে রুট তখনই অর্থহীন যখন B-ও জানে না A-র LAN-এ কীভাবে পৌঁছাবে, আর অসমমিত জ্ঞানই সেই সবচেয়ে সাধারণ কারণ যার জন্য রাউটেড ডিজাইন নীরবে উত্তর ফেলে দেয়।
তৃতীয়টি আস্থা। রাউটিং প্যাকেট সরায়; সেগুলো রক্ষা করে না। একই ভবনের ভিতরের প্রাইভেট ট্রানজিট সেগমেন্ট আর প্রোভাইডার হ্যান্ড-অফ বা শেয়ার্ড ক্যাম্পাস ব্যাকবোন অতিক্রমকারী লিংক এক জিনিস নয়। সেগমেন্ট অবিশ্বস্ত হলে উত্তর হলো দুটি ফায়ারওয়ালের মধ্যে একটি টানেল, আর নিচের রাউটিং পরিকল্পনা তার ভিতরেও প্রযোজ্য।
তিনটিই একই দিকে ইঙ্গিত করলেই সরল ডিজাইন জেতে। এর একটি ব্যর্থ হলে অনুবাদ দিয়ে ঢেকে দেওয়ার বদলে সেই শর্তটি স্পষ্টভাবে ঠিক করুন, কারণ NAT ব্যর্থতা লুকায়, সমাধান করে না।
ট্রানজিট নেটওয়ার্কে রুট পরিকল্পনা গড়ুন
প্রতিটি ফায়ারওয়ালকে শেয়ার্ড সেগমেন্টে একটি ঠিকানা দিন এবং প্রতিটি দূরবর্তী LAN-এর জন্য একটি নির্দিষ্ট রুট যোগ করুন। বিদ্যমান কনফিগারেশনের আর কিছু সরাতে হবে না, বিশেষত ইন্টারনেট ডিফল্ট রুট ঠিক যেখানে আছে সেখানেই থাকতে হবে। ডিফল্ট রুটকে পিয়ার ফায়ারওয়াল দিয়ে বদলালে প্রতিটি অসম্পর্কিত গন্তব্য ট্রানজিটের ওপর দিয়ে যাবে, যা চাওয়া পরিবর্তনের চেয়ে অনেক বড়। pfSense-এর স্ট্যাটিক রাউটিং ডকুমেন্টেশন সেই প্ল্যাটফর্মের জন্য একই রুট-প্লাস-গেটওয়ে মডেল বর্ণনা করে, এবং আপনি যে ফায়ারওয়ালই চালান না কেন সমতুল্য নিয়ন্ত্রণ সেখানে আছে।
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
ফায়ারওয়াল A 10.30.0.0/24 পরিবেশন করে আর ফায়ারওয়াল B 10.40.0.0/24, দুই ট্রানজিট ঠিকানা 192.0.2.0/24-এ। প্রতিটি LAN হোস্ট তার স্থানীয় ফায়ারওয়ালকে গেটওয়ে হিসেবে রাখে, তাই একমাত্র নতুন অবস্থা হলো দুই পাশে একটি করে রুট। Linux-ভিত্তিক ফায়ারওয়ালে একই পরিকল্পনা এমন দেখায়, এবং ফরওয়ার্ডিং সক্রিয় করতে হবে, নইলে রুট সমাধান হবে অথচ প্যাকেট ফেলে দেওয়া হবে।
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
ফিল্টারিং অনুবাদ থেকে আলাদা রাখুন
রাউটিং ও নীতি ভিন্ন নিয়ন্ত্রণ, এবং দ্বিতীয়টিতেই বেশিরভাগ রাউটেড ডিজাইন সত্যিই ব্যর্থ হয়। যে ইনগ্রেস সীমান্ত প্যাকেট সত্যিই অতিক্রম করে সেখানে নির্দিষ্ট উৎস, গন্তব্য ও সেবার অনুমতি দিন, এবং মনে রাখুন WAN-এর মতো ইন্টারফেস লেবেল একটি নাম, আস্থার বিবৃতি নয়। প্রাইভেট ট্রাফিক বহনকারী ট্রানজিট পোর্টে ডিফল্টভাবে প্রাইভেট-ঠিকানা ব্লকিং সক্রিয় থাকতে পারে।
তারপর সিদ্ধান্তে পৌঁছানোর আগে আউটবাউন্ড অনুবাদ দেখুন যে কোনো NAT ঘটছে না। স্বয়ংক্রিয় আউটবাউন্ড নিয়ম এমন ট্রাফিক পুনর্লিখন করতে পারে যা কখনো অনুবাদের জন্য নয়, ফলে দূর পক্ষের নিজের নীতি ও লগের জন্য প্রয়োজনীয় উৎস ঠিকানা নষ্ট হয়। নিশ্চিত করুন নির্বাচিত ফ্লো মূল ঠিকানা ধরে রাখে, এবং যে ট্রাফিকের এখনো দরকার তার জন্য ইন্টারনেট অনুবাদ নিয়মগুলো অপরিবর্তিত রাখুন।
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
যখন NAT-ই সৎ উত্তর
অনুবাদ তখনই স্থান পায় যখন ঠিকানা পরিসর সত্যিই ওভারল্যাপ করে এবং পুনঃসংখ্যাকরণ পাওয়া যায় না, বা কোনো নীতি এক পক্ষকে সাবনেটের বদলে একক ঠিকানা দেখতে বাধ্য করে। সেসব ক্ষেত্রে সচেতন এক-থেকে-এক বা পোর্ট-সীমিত ম্যাপিং জানা পরিণতিসহ একটি ডিজাইন সিদ্ধান্ত, কোনো কাজ চালানোর উপায় নয়।
উচ্চস্বরে বলার মতো পরিণতি হলো দূর পক্ষ আর আলাদা উৎস দেখতে বা ফিল্টার করতে পারে না। লগ অনুবাদক ঠিকানায় নেমে আসে, প্রতি-হোস্ট নীতি কাজ করা বন্ধ করে, এবং সমস্যা সমাধান হয়ে দাঁড়ায় কোন অভ্যন্তরীণ হোস্ট নির্দিষ্ট মুহূর্তে একটি ফ্লোর মালিক ছিল তা খোঁজা। প্রশ্নের ট্রাফিকের জন্য এসবের কিছু না হলে NAT ঠিক আছে।
যখন ট্রানজিট নিজেই ভুল অনুমান
শেয়ার্ড সেগমেন্ট প্রোভাইডার, শেয়ার্ড সুইচ ফ্যাব্রিক, বা অন্য পক্ষ ট্রাফিক পড়তে পারে এমন কোনো পথ অতিক্রম করলে শুধু রাউটিং পূর্ণ উত্তর নয়। দুটি ফায়ারওয়ালের মধ্যে টানেল আপনাকে গোপনীয়তা ও পিয়ার প্রমাণীকরণ দেয়, আর এর ভিতরের রুট টেবিল সেই একই টেবিল যা আপনি ট্রানজিটে লিখতেন।
এটি প্রথম অংশের আস্থার প্রশ্ন থেকে ঠিক করুন, VPN বেশি নিরাপদ এই অভ্যাস থেকে নয়। যে সেগমেন্ট ইতিমধ্যে প্রাইভেট তার ওপর টানেল কোনো লাভ ছাড়াই পরিচালন ব্যয় ও আরেকটি ব্যর্থতার ধারা যোগ করে, আর অবিশ্বস্ত সেগমেন্টে রাউটিং গোপনীয়তার বদলে এমন সরলতা দেয় যা আপনি চালাতে পারবেন না। তিনটি শর্তের কোনটি সিদ্ধান্তটি চালাল তা লিখে রাখুন, পরের প্রকৌশলীকে আর তা পুনরায় বিশ্লেষণ করতে হবে না।