NAT کردن LAN از طریق tun0 روی دروازه VPN اوپن‌بی‌اس‌دی

دو مهندس که دروازه OpenBSD یکسانی در اختیار دارند غالباً دو مجموعه قاعده متفاوت برای رسیدن به یک شبکه دوردست به شما می‌دهند و هر دو قابل دفاع است. انتخاب میان ترجمه مبدأ و مسیر بازگشت اصلاً پرسش نحوی نیست. مسئله به این برمی‌گردد که طرف دور پیش‌تر درباره 192.168.88.0/24 چه می‌داند و شما چه چیزی را باید در گزارش‌های خود نگه دارید. اگر این را اشتباه کنید، خط nat-to کاملاً درست به نظر می‌رسد در حالی که پاسخ‌ها در دروازه پیش‌فرض دور ناپدید می‌شوند.

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

جدول مسیریابی تصمیم می‌گیرد که 172.20.0.0/16 از طریق tun0 قابل دسترسی است و این تصمیم پیش از مراجعه به هر ترجمه pf گرفته می‌شود. سپس ترجمه مبدأ سرآیند بسته را تغییر می‌دهد تا طرف دور نشانی تونل دروازه را به جای یک میزبان LAN ببیند. هیچ‌یک از این دو سازوکار جای دیگری را نمی‌گیرد: قاعده nat نمی‌تواند از هیچ مسیر بسازد و مسیر نمی‌تواند مسیریاب دوردستی را که هرگز از زیرشبکه خصوصی شما نشنیده قانع کند. وقتی طرف دور مسیر بازگشت ندارد، پاسخ‌ها دور ریخته یا به دروازه پیش‌فرض آن فرستاده می‌شوند و هیچ میزان تنظیم قاعده این را درست نمی‌کند.

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

سه شرطی که آن را تعیین می‌کند

سه پرسش را به ترتیب بپرسید و طراحی معمولاً خودش را انتخاب می‌کند. آیا شبکه دور مسیر ایستایی دارد که به نشانی تونل برای 192.168.88.0/24 اشاره کند، یا مدیر آن مسیریاب‌های آن مسیر را کنترل می‌کند؟ اگر بله، بگذارید نشانی‌های LAN بدون تغییر سفر کنند و ترجمه را کاملاً نادیده بگیرید. آیا در طرف دور به دید هر مشتری نیاز دارید، چه برای سیاست دسترسی و چه برای ردپای حسابرسی؟ اگر بله، حفظ مبدأ ارزش کار مسیریابی را دارد. آیا نشانی تونل آن‌قدر پایدار است که در مسیر دور نوشته شود، یا میان اتصال‌های دوباره تغییر می‌کند؟

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

قطعه را جایی بگذارید که pf واقعاً آن را ارزیابی کند

قطعه زیر فرض می‌کند LAN برابر 192.168.88.0/24 است، شبکه دور 172.20.0.0/16 است و رابط تونل tun0 است. هیچ چیز در آن گام بعدی را انتخاب نمی‌کند. فقط مبدأ را روی بسته‌هایی بازنویسی می‌کند که از پیش از تونل خارج می‌شوند.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

دو جزئیات در آن خط اول بیشترین وزن را حمل می‌کند. پرانتزهای دور tun0 به pf می‌گویند هر بار که یک ورودی وضعیت می‌سازد نشانی رابط را بخواند، که وقتی تونل پس از اتصال دوباره شماره‌گذاری می‌شود اهمیت دارد. واژه match یعنی قاعده بازنویسی می‌کند و سپس رد می‌شود، پس یک قاعده pass جداگانه هنوز باید جریان را بپذیرد. رابط نام‌برده در خط match نیز باید همانی باشد که جدول مسیریابی انتخاب می‌کند، وگرنه pf قاعده را روی مسیر خروجی متفاوتی از مسیری که بسته واقعاً می‌پیماید ارزیابی می‌کند.

سمت هسته را فراموش نکنید. ارسال IPv4 باید فعال باشد و قواعد pass حالت‌دار برای تونل و LAN باید وجود داشته باشند پیش از آنکه هیچ‌یک از این‌ها معنا پیدا کند. بخش PF NAT در پرسش‌های متداول OpenBSD مرجع درست برای ترتیب واژه‌های کلیدی در اینجا است.

پیش از اعتماد به ترافیک، مجموعه قاعده را بررسی کنید

نخست نحو را با pfctl -nf /etc/pf.conf بررسی کنید، که فایل را بدون بارگذاری آن تجزیه می‌کند. سپس سیاست را بارگذاری کنید و بخوانید هسته واقعاً چه چیزی نگه می‌دارد، زیرا قاعده‌ای که پاک تجزیه شده باشد باز هم می‌تواند سایه بیندازد یا به رابط اشتباه بچسبد. pfctl -sn قواعد ترجمه را در شکل بارگذاری‌شده چاپ می‌کند و pfctl -sr قواعد فیلتر را به ترتیب ارزیابی چاپ می‌کند.

سپس سیم را زیر نظر بگیرید. روی دروازه، tcpdump -ni tun0 'host 172.20.0.10' نشان می‌دهد آیا نشانی مبدأیی که از تونل خارج می‌شود نشانی تونل است یا میزبان LAN. یک netstat -rn -f inet سریع تأیید می‌کند که مقصد به کدام رابط تجزیه می‌شود. وقتی ترافیک جریان یافت، pfctl -ss ورودی‌های وضعیت را فهرست می‌کند؛ اگر جریانی وضعیتی تولید نکرد، بسته هرگز با قاعده‌ای که یکی می‌سازد مطابقت نداشته است.

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

وقتی ترجمه بیش از آنچه صرفه‌جویی می‌کند هزینه دارد

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

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

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