NAT مبدأ آدرس مشتریان را از دیوار آتش بعدی پنهان می‌کند

قاعده‌ای که برای مشتریان کارکنان و آزمایشگاه نوشته شده روی دیوار آتش لبه جدید می‌رود و بی‌صدا با همه‌چیز یا با هیچ‌چیز مطابقت می‌کند. دلیل در بالادست است: دروازه‌ای از قبل آدرس مشتریان را بازنویسی کرده، پس قاعده یک آدرس ترانزیت را به‌جای دو گروه می‌بیند. افزودن یک دستگاه اطلاعاتی را که مسیر حذف کرده برنمی‌گرداند. پیش از نوشتن سیاست، آخرین نقطه‌ای را بیابید که تمایز هنوز در آن وجود دارد.

چرا قاعده لبه یک آدرس می‌بیند

ترجمه چند‌به‌یک هر جفت آدرس و پورت داخلی را به یک آدرس خارجی مشترک با پورت تخصیص‌یافته نگاشت می‌کند. گفتگوها به‌خاطر این اتصال‌های پورت برای مترجم قابل تمایز می‌مانند، اما دستگاه پایین‌دست که تطبیق ساده پیشوند مبدأ انجام می‌دهد فقط آدرس مشترک را می‌بیند. همین کافی است تا دو گروه نزد قاعده یکسان شوند. بسته‌ها همچنان می‌رسند؛ گروه‌بندی نه.

بررسی کنید که رابط دیوار آتش واقعاً چه چیزی را مشاهده می‌کند، نه آنچه نمودار وعده می‌دهد. این دو بیشتر از آنچه کسی انتظار دارد با هم تفاوت دارند.

آخرین هویت قابل اعمال را بیابید

از نقطه اعمال شروع کنید و عقب بروید تا پیشوند اصلی ظاهر شود. معمولاً دو فرمان مرز را پیدا می‌کنند.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

جدول NAT نشان می‌دهد کدام ترافیک و با کدام قاعده ترجمه می‌شود، در حالی که فهرست conntrack جفت‌های اصلی و ترجمه‌شده را برای جریان‌های فعال نشان می‌دهد. جایی که دیوار آتش بالادست همیشه فقط آدرس ترجمه‌شده را می‌بیند، قواعد مبدأ به تفکیک گروه هرطور نوشته شوند کار نمی‌کنند. در مسیر به جلو یا عقب بروید تا به دستگاهی برسید که دو پیشوند مشتری در آن متمایز می‌مانند. در هر گام مبدأ را ثبت کنید، نه اینکه به برچسب داخلی یا خارجی اعتماد کنید.

سه جایگاه و هزینه هرکدام

سیاست می‌تواند روی دروازه ترجمه‌کننده باشد، جایی که مبدأهای اصلی هنوز دیده می‌شوند. می‌تواند روی دیوار آتش بالادست باشد اگر ترانزیت به‌جای ترجمه مسیریابی شود، که یعنی افزودن مسیرهای برگشت و حذف بازنویسی مبدأ. یا می‌توان آن را بر هویت به‌جای آدرس‌ها اعمال کرد، از طریق کنترلی احراز‌شده که کاربر یا دستگاه را می‌شناسد. هر انتخاب یک مالک و یک حالت شکست دارد و تنها دو گزینه نخست قاعده را صرفاً درباره آدرس مبدأ نگه می‌دارند.

هر کدام را انتخاب کنید، قاعده را همراه با آدرسی که با آن مطابقت دارد مستند کنید. قاعده‌ای که فرض آدرسش بی‌صدا تغییر کرده بدتر از نبودن قاعده است، چون همچنان با ترافیک مطابقت می‌کند در حالی که چیزی کاملاً دیگر را محافظت می‌کند.

پذیرش: یک مشتری مجاز و یک مشتری ردشده

با یک جفت مشتری، یکی از هر گروه، آزمایش کنید و ثبت کنید هرکدام چگونه به نقطه اعمال می‌رسد. هر دو جفت را کنار نتیجه قاعده نگه دارید تا شواهد نشان دهد تمایز باقی مانده، نه اینکه دیوار آتش دیگری وجود دارد. پس از تغییر NAT یا مسیریابی آزمایش را تکرار کنید، چون آدرس ارائه‌شده همان بخشی است که بی‌صدا می‌شکند. هرجا باید افراد را از هم تشخیص داد احراز هویت را نگه دارید، زیرا آدرس مبدأ ورودی سیاست است، نه دلیل هویت.

نقطه اعمال، مبدأ مشاهده‌شده و قاعده را در تیکت بنویسید. وگرنه مهندس بعدی دیوار آتش دومی و همان قاعده را اضافه می‌کند.