آیا باید روی ارسال پورت به یک زیرشبکه VPN، SNAT اعمال کنید؟

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

چرا پاسخ راه دیگری می‌رود

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

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

قاعده‌ای مبدأ که به‌قدر کافی باریک باشد تا بتوان به آن اعتماد کرد

روتر را همان مبدأیی کنید که میزبان دور به آن پاسخ می‌دهد. در این چیدمان آدرس WAN 203.0.113.24 است، LAN 192.168.88.0/24 است، آدرس تونل روتر 172.20.5.1 است، و سرویس روی 172.20.5.40:8443 پاسخ می‌دهد. قاعده زیر با بسته پس از ترجمه مقصد مطابقت دارد، به همین دلیل آدرس ترجمه‌شده را نام می‌برد نه آدرس عمومی را. هیچ چیز در آن به آدرس کلاینت وابسته نیست، و دقیقاً همین نکته است.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

وقتی ماسک عمومی انتخاب صادقانه است

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

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

قبل از انتشار شمارنده‌ها را بررسی کنید

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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