SNAT در برابر DNAT در برابر Masquerade: هر قاعده NAT در VPN چه می‌کند

NAT مبدأ بازنویسی می‌کند که جریان ظاهراً از کجا می‌آید؛ NAT مقصد بازنویسی می‌کند که به کجا می‌رود. Masquerade همان NAT مبدأ با نشانی قرض‌گرفته است.

یک ضبط روی هر دو طرف دروازه VPN بگذارید و یک جریان می‌تواند چهار نشانی متفاوت نشان دهد. NAT مبدأ بازنویسی می‌کند که بسته ادعا می‌کند از کجا می‌آید؛ NAT مقصد بازنویسی می‌کند که به کجا می‌رود. Masquerade جهت سوم نیست، قاعده‌ای از NAT مبدأ است که نشانی‌اش را از رابط خروجی می‌گیرد نه از یک مقدار ثابت. مشخص کنید کدام یک از این سه را واقعاً لازم دارید و بیشتر تیکت‌های «VPN خراب است» به پرسشی درباره مسیر برگشت فرو می‌ریزند.

هر قاعده چه چیزی را بازنویسی می‌کند

NAT مبدأ، که معمولاً SNAT نوشته می‌شود، نشانی مبدأ یک جریان را هنگام خروج از مسیریاب یا دروازه تغییر می‌دهد. سرویس گیرنده به نشانی ترجمه‌شده پاسخ می‌دهد و جعبه‌ای که ترجمه می‌کند تغییر را با حالتی که برای آن اتصال نگه داشته بود برمی‌گرداند. در Linux این حالت در conntrack زندگی می‌کند، به همین دلیل conntrack -L چندتایی‌های اصلی و پاسخ را کنار هم چاپ می‌کند.

NAT مقصد، DNAT، به‌جای آن مقصد را تغییر می‌دهد. بسته‌ای که به نشانی عمومی روی UDP 51820 فرستاده شده می‌تواند به سرور داخلی WireGuard در 10.8.0.2:51820 بازنویسی شود. مسیریاب خانگی یا متعادل‌کننده بار ابری بدین ترتیب یک شنونده VPN را منتشر می‌کند، و این هیچ چیزی درباره آنچه تونل بعداً می‌تواند حمل کند نمی‌گوید.

Masquerade به خانواده SNAT تعلق دارد. قاعده هیچ نشانی را نام نمی‌برد؛ هر نشانی که رابط خروجی هنگام خروج بسته داشته باشد به کار می‌برد. Linux به آن هدف خودش را می‌دهد و این گزینه معمول روی رابط WAN است که نشانی‌اش را از DHCP یا PPPoE می‌گیرد.

جایی که نگاشت زندگی می‌کند، شکست را تعیین می‌کند

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

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

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

Masquerade یا SNAT صریح

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

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

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

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

خواندن قاعده‌ها روی دروازه Linux

دروازه دسترسی از راه دور با مشتریانی روی 10.8.0.0/24 و رابط WAN به نام eth0 به هدایت فعال و سیاست پالایشی نیاز دارد که جریان را مجاز کند، پیش از آنکه هیچ قاعده NAT بتواند کمک کند. نسخه iptables هر دو جهت را در جدول nat نگه می‌دارد:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

شکل nftables از همان دو قلاب با رابط نام‌دار و زنجیره صریح استفاده می‌کند:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

هر دو تکه فرض می‌کنند زنجیره پالایش جریان هدایت‌شده را پیشاپیش می‌پذیرد. NAT قاعده اجازه نیست، و بسته‌ای که درست ترجمه شده ممکن است یک جدول بعدتر دور انداخته شود. نگاشت زنده را با conntrack -L تأیید کنید، آنچه بارگذاری شده را با nft list ruleset یا iptables-save -t nat تأیید کنید، سپس روی هر دو رابط ضبط کنید تا ببینید نشانی واقعاً تغییر می‌کند.

حالت‌های شکستی که شبیه قاعده بد به نظر می‌رسند

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

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

سپس آزمونی هست که قبول می‌شود و استقرارهایی که شکست می‌خورند. اجرای دستی فرمان NAT سازوکار را اثبات می‌کند نه پیکربندی را. قاعده‌ای که در زمان اجرا افزوده شود در راه‌اندازی مجدد یا رویداد بعدی رابط ناپدید می‌شود و قاعده Masquerade وابسته به رابطی که شماره‌اش عوض می‌شود می‌تواند بی‌صدا نشانی‌ای را که طرف دور می‌بیند تغییر دهد. قاعده را در پیکربندی دیوار آتشی که مالک آن است بگذارید و پس از اتصال دوباره آزمون را تکرار کنید.

فهرست بررسی پیش از ذخیره قاعده

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

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

مقالات مرتبط