دو کلاینت VPN، دو نشانی عمومی: SNAT را هماهنگ کنید

دو کلاینت VPN می‌توانند از طریق دو نشانی IPv4 عمومی متفاوت خارج شوند، و قاعده‌ای که این کار را می‌کند کوتاه‌تر از آن است که بیشتر مردم انتظار دارند. آنچه آن را کار می‌اندازد نحو iptables نیست، بلکه وضعیت بسته هنگام رسیدن به زنجیره خروج است: نشانی مبدأ در آنجا هنوز باید کلاینت‌ها را از هم تشخیص دهد. اگر یک masquerade پیشین هر دو را از قبل روی یک نشانی ادغام کرده باشد، هیچ قاعده‌ای برای هر کلاینت نمی‌تواند آن تمایز را بازگرداند. ابتدا این مسئله را روشن کنید، سپس ترجمه را بنویسید.

کدام هویت تا دروازه دوام می‌آورد

قاعده با نشانی مبدأ بسته مطابقت دارد، نه با نام کاربری VPN و نه با نامی که برنامه کلاینت نشان می‌دهد. هر چیزی که بسته را پیش‌تر در مسیر ترجمه کند تعیین می‌کند که قاعده شما هنوز چه چیزی را می‌تواند ببیند. جدول nat را به ترتیب اجرا کنید و نقطه‌ای را بیابید که مبدأ در آن هنوز برای هر کلاینت جداست.

iptables -t nat -S POSTROUTING

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

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

ترجمه نمی‌تواند نشانی از خود بسازد

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

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

پیش از masquerade عمومی درج کنید

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

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

فرمان اول رابطی را نام می‌برد که بسته به اینترنت واقعاً از آن خارج می‌شود. فرمان دوم زنجیره را با شماره خط چاپ می‌کند. ورودی masquerade عمومی خطی است که باید بالای آن بمانید.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

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

مبدأ را با یک جریان تازه اثبات کنید

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

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

ترجمه هنوز مسیر را انتخاب نمی‌کند، جریان را از فیلتر عبور نمی‌دهد و سرویس ورودی منتشر نمی‌کند. مسیر نادرست و قاعده مجاز غایب پس از یک قاعده SNAT بی‌نقص هم شکست می‌خورند. IPv6 و هر مسیر خروج ثانویه را نیز بررسی کنید، سپس جفت‌های داخلی-به-عمومی را در مستندات دیوار آتش یادداشت کنید تا تغییر بعدی از نگاشت آغاز شود نه از متن قاعده.