یک زیرشبکه LAN را از OpenVPN عبور بده و مسیر پیش‌فرض را نگه دار
مسیر پیش‌فرض LAN را نگه دار در حالی که یک زیرشبکه از تونل می‌گذرد. جدول سیاست را با ویرایش‌های جدول اصلی مقایسه کن، سپس NAT یا مسیر سمت سرور را انتخاب کن.
دستگاه‌هایی که برای یک LAN مسیریابی می‌کنند و همزمان به یک VPN وصل می‌شوند، با خودشان به همان بحث می‌رسند: تونل می‌خواهد مالک مسیر پیش‌فرض باشد و LAN آن را پس می‌خواهد. وقتی OpenVPN متصل می‌شود، ممکن است یک مسیر پیش‌فرض از میان تونل یا یک جفت نیمه‌مسیر پیش‌فرض نصب کند، که برای لپ‌تاپ درست و برای دروازه‌ای که همسایگانش انتظار پاسخ از نشانی LAN آن دارند نادرست است. پاسخ این نیست که VPN را نادیده بگیری. پاسخ این است که به دو تصمیم دو جدول متفاوت بدهی.
یک مسیر پیش‌فرض، دو مالک
ترافیک ارسال‌شده و ترافیکی که به‌صورت محلی تولید می‌شود لازم نیست یک مسیر را طی کنند. کارخواهان LAN تونل را فقط برای مقصدهایی که انتخاب می‌کنی لازم دارند، در حالی که نشست‌های مدیریت خود میزبان و پاسخ‌هایش به همان کارخواهان به مسیر پیش‌فرض LAN نیاز دارند. آمیختن هر دو در جدول اصلی یک پاسخ را به دو پرسش متفاوت تحمیل می‌کند.
OpenVPN کلیدی دقیقاً برای همین دارد. route-noexec مانع می‌شود که کارخواه اصلاً به جدول اصلی دست بزند، و مقادیری که در غیر این صورت به کار می‌برد به یک اسکریپت route-up صادر می‌شوند به‌عنوان route_vpn_gateway، dev و نشانی‌های واسط. سپس تو تصمیم می‌گیری کدام جدول کدام مسیر را بگیرد، در کدی که بعداً می‌توانی بخوانی.
جدول سیاست در برابر بازنویسی جدول اصلی
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
جدول جداگانه تنها گزینه‌ای است که فراتر از یک زیرشبکه مقیاس می‌گیرد. یک بار نامش را بگذار و بعد با نام به آن ارجاع بده تا کسی مجبور نباشد عددی را به خاطر بسپارد:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnنشانی‌های اینجا جای‌نگهدار هستند. پیش از اجرای هر چیزی، پیشوند LAN، دروازه تونل و نام دستگاه را از استقرار خودت جایگزین کن.
قاعده باید با میزبان هم بخواند
قاعده‌ای که فقط با پیشوند LAN می‌خواند بسته‌های ارسال‌شده را پوشش می‌دهد. ترافیکی را که خود دروازه تولید می‌کند پوشش نمی‌دهد و پاسخ‌هایی را هم که به کارخواهان LAN برمی‌گرداند پوشش نمی‌دهد، پاسخ‌هایی که نشانی LAN دروازه را به‌عنوان منبع خود دارند. آن جست‌وجوها به main می‌افتند و هنوز می‌توانند از تونل بیرون بروند.
قاعده دومی برای نشانی LAN خود دروازه اضافه کن، یا قاعده اول را به مجموعه‌ای گسترش بده که هر دو را دربر بگیرد. ترتیب مهم است: قاعده مشخص‌تر را اول بگذار و نتیجه را با جست‌وجویی بررسی کن که منبع را صریح نام می‌برد.
ip route get 203.0.113.9 from 192.168.50.1اگر این برای مقصدی که باید محلی بماند دستگاه تونل را گزارش کرد، مجموعه قاعده‌ها درست نیست، صرف‌نظر از اینکه جدول چه دارد.
NAT یا مسیری در طرف دور
سرور VPN زیرشبکه تونل را می‌شناسد و هیچ چیز دیگری. بسته‌هایی که با نشانی منبع LAN می‌رسند مسیر بازگشتی ندارند مگر کسی آن را فراهم کند، و دقیقاً دو راه برای فراهم کردنش وجود دارد. افزودن مسیر برای پیشوند LAN روی سرور منبع اصلی را سرتاسر دیدنی نگه می‌دارد، که طراحی حسابرسی‌شده معمولاً همین را می‌خواهد. ماسک‌گذاری روی دروازه منبع را به نشانی تونل بازنویسی می‌کند و هیچ همکاری‌ای از سرور نمی‌خواهد.
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEوقتی سرور را کنترل نمی‌کنی و نمی‌توانی آنجا مسیر اضافه کنی NAT را انتخاب کن. وقتی گزارش‌ها، کنترل دسترسی یا تقارن مسیر بازگشت مهم‌اند مسیر سمت سرور را انتخاب کن، چون ماسک‌گذاری نشانی اصلی را از هر چیزی که طرف دور ثبت می‌کند پاک می‌کند.
در هر دو حالت ارسال باید فعال باشد، و فیلترکردن سخت‌گیرانه مسیر معکوس ممکن است پاسخ را بیندازد وقتی main تونل را برای آن منبع انتخاب نمی‌کرد. پیش از سرزنش تونل مقدار مؤثر را بررسی کن.
کاری کن که این تقسیم از اتصال دوباره جان سالم ببرد
قاعده‌ها و مسیرهایی که دستی اضافه شده‌اند با بازساخته شدن واسط از بین می‌روند و یک ورودی کهنه جدول می‌تواند از نشستی که آن را توجیه می‌کرد بیشتر بماند. قاعده جدول، مسیر تونل و ورودی ماسک‌گذاری را داخل اسکریپت route-up کارخواه بگذار و جدول را در بالای اسکریپت پاک کن تا دروازه قدیمی نتواند به نشست جدید برسد.
از هر دو سر بررسی کن: یک جست‌وجو روی دروازه با منبع LAN، و یک درخواست واقعی از کارخواه LAN به مقصدی که باید از تونل بگذرد. مسیری که وجود دارد ولی هرگز انتخاب نمی‌شود دقیقاً مانند نبودن مسیر رفتار می‌کند تا وقتی شمارنده‌ها را بخوانی.