بین LAN های خصوصی مسیریابی کنید، پیش از افزودن یک NAT دیگر
فضای آدرس هم‌پوشان، مسیر بازگشت گمشده یا ترانزیت غیرقابل اعتماد میان مسیریابی، NAT و تونل تصمیم می‌گیرند. پیش از ویرایش فایروال این سه را بررسی کنید.
دو فایروال داخلی، یک قطعه ترانزیت خصوصی و درخواستی برای اینکه چند میزبان در هر LAN با میزبان‌های LAN دیگر صحبت کنند. واکنش معمول برپا کردن یک VPN یا افزودن لایه دوم NAT است و هر دو واکنش بیش از آنچه مشکل می‌ارزد هزینه دارند. مسیریابی معمولی کافی است وقتی سه شرط برقرار باشد: بازه‌های آدرس هم‌پوشانی ندارند، هر دو طرف می‌توانند ترافیک را به LAN دیگر برگردانند و قطعه ترانزیت برای داده‌ها به‌اندازه کافی قابل اعتماد است. پیش از طراحی هر چیزی این سه را بررسی کنید، چون هر یک پاسخ را تغییر می‌دهد.
سه شرطی که طراحی را تعیین می‌کنند
شرط اول فضای آدرس است. اگر هر دو LAN از همان بلوک RFC 1918 استفاده کنند، مسیریابی نمی‌تواند آن‌ها را از هم تشخیص دهد و ترجمه به‌جای اختیاری بودن، اجتناب‌ناپذیر می‌شود. شرط دوم مسیر بازگشت است: مسیری از A به B بی‌فایده است مگر آنکه B هم بداند چگونه به LAN مربوط به A برسد، و دانش نامتقارن رایج‌ترین دلیل دور ریختن بی‌صدای پاسخ‌ها در یک طراحی مسیریابی‌شده است.
شرط سوم اعتماد است. مسیریابی بسته‌ها را جابه‌جا می‌کند؛ از آن‌ها محافظت نمی‌کند. یک قطعه ترانزیت خصوصی درون یک ساختمان با تحویل به یک اپراتور یا پیوندی که از ستون فقرات مشترک دانشگاه می‌گذرد متفاوت است. اگر قطعه قابل اعتماد نباشد، پاسخ تونلی بین دو فایروال است و طرح مسیریابی زیر همچنان درون آن اعمال می‌شود.
تنها وقتی هر سه به یک سمت اشاره کنند، طراحی ساده برنده می‌شود. وقتی یکی از آن‌ها شکست بخورد، همان شرط را صریح اصلاح کنید نه اینکه آن را با ترجمه بپوشانید، چون 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. تونل روی قطعه‌ای که از قبل خصوصی است هزینه عملیاتی و یک حالت خرابی دیگر بدون هیچ سودی اضافه می‌کند، در حالی که مسیریابی روی قطعه غیرقابل اعتماد محرمانگی را با سادگی‌ای معاوضه می‌کند که از عهده آن برنمی‌آیید. بنویسید کدام یک از سه شرط انتخاب را هدایت کرد تا مهندس بعدی مجبور به بازبحث آن نشود.