کلاینتهای LAN تا فعالشدن مسیریابی سیاستی، VPN روتر را نادیده میگیرند
قواعد ارسال بستهها را مجاز میکنند، اما هرگز رابط را انتخاب نمیکنند. یک جدول سیاست و قاعده جداگانه تعیین میکند کدام کلاینتهای LAN از VPN روتر استفاده میکنند.
روتر از طریق تونل خود به اینترنت میرسد، در حالی که لپتاپی پشت آن هنوز آدرس ISP را گزارش میدهد. افزودن قواعد پذیرش کمکی نمیکند و این شکست گویاست: فیلترکردن پاسخ میدهد که آیا بسته اجازه عبور دارد یا نه، نه اینکه به کجا میرود. انتخاب رابط را پیشتر یک جستوجوی مسیریابی انجام داده که هیچ چیزی از فهرست کلاینتهای شما نمیداند. جستوجو را درست کنید تا دیوار آتش دیگر مظنون نباشد.
قاعده فیلتر نمیتواند رابط را انتخاب کند
جریان بسته در روتر لینوکس نخست تصمیم مسیریابی را اجرا میکند و سپس قلاب ارسال را. وقتی قاعدهای با دستگاه تونل خروجی مطابقت میکند، هسته از قبل تصمیم گرفته که تونل راه خروج است. اگر جدول اصلی هنوز مسیر پیشفرض WAN را ترجیح دهد، بسته در راه ISP است و قاعده پذیرشی که همین حالا نوشتید هرگز آن را نمیبیند. همین یک واقعیت ترتیبی توضیح میدهد چرا یک صفحه قاعده جدید دیوار آتش هیچ چیز را تغییر نمیدهد.
مثال زیر از یک LAN با 192.168.8.0/24 روی br-lan، یک دستگاه تونل tun0 و یک ستاپباکس روی 192.168.8.23 استفاده میکند که باید از تونل عبور کند.
پیش از ویرایش قواعد، جستوجو را بخوانید
از هسته بخواهید مسیری را به نمایندگی آن کلاینت حل کند. پاسخ شامل دستگاه خروجی و آدرس مبدئی است که انتخاب میشود، و این همه چیزی است که برای تأیید تشخیص لازم دارید. اگر پاسخ دستگاه WAN را نام ببرد، بسته هرگز شانسی برای رسیدن به قاعده شما نداشته است.
ip -4 route get 198.51.100.7 from 192.168.8.23
پرسوجو را برای کلاینتی تکرار کنید که باید در مسیر معمول بماند. وقتی هر دو پاسخ یک دستگاه را نام میبرند، هنوز هیچ سیاستی بر پایه مبدأ در کار نیست و اصلاح به مسیریابی تعلق دارد نه به فیلترکردن.
جدولی را به کلاینتهایی که میخواهید پوشش دهید پیوند بزنید
مسیریابی سیاستی یک جستوجوی قاعدهمحور را پیش از جدول اصلی قرار میدهد. جدولی بسازید که مسیر پیشفرضش تونل است، سپس آن جدول را به یک انتخابگر پیوند دهید: رابط ورودی، آدرس مبدأ یا نشان دیوار آتش. اولویتها ترتیب را تعیین میکنند و جدول اصلی بسیار پایینتر در فهرست، روی 32766 قرار دارد، بنابراین قاعدهای با شماره پایین اول بررسی میشود. انتخابگرهای رابط همه کلاینتهای روی پل را پوشش میدهند؛ انتخابگرهای آدرس یک ماشین را پوشش میدهند.
ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200
رابطهای فرمور معمولاً همان اشیای صفحه مسیریابی سیاستی یا سیاست VPN را نشان میدهند. فهرست دستگاه در آنجا از قواعد دستنویس آسانتر نگهداری میشود و معمولاً از ارتقاهایی که نحو قواعد را تغییر میدهند جان سالم به در میبرد.
انتخابگر را عمدی انتخاب کنید. قاعده رابط کوتاه و آیندهنگر است، اما ترافیک مدیریتی خود روتر را هم که به آن پل میرسد میگیرد. قاعده مبدأ دقیق است و هر بار که فهرست دستگاه تغییر کند به ویرایش نیاز دارد. انتخاب را بنویسید، چون نفر بعدی که بپرسد چرا یک دستگاه متفاوت رفتار میکند به آن نیاز خواهد داشت.
مقصدهای محلی را بیرون از تونل نگه دارید
جدول تازه فقط مسیرهایی را میداند که در آن میگذارید. پیشوند LAN غایب است، بنابراین ترافیک چاپگر و NAS مسیر پیشفرض تونل را دنبال میکرد و ناپدید میشد. یک مسیر throw جستوجو را در این جدول پایان میدهد و تصمیم را به جدول اصلی بازمیگرداند.
ip -4 route add throw 192.168.8.0/24 table 200
اگر آن مسیر را جا بیندازید، اشتراکهای محلی میشکنند و نشست مدیریتی خود روتر هم میتواند ناپدید شود اگر انتخابگر از آنچه در نظر داشتید گستردهتر باشد. سپس مسئله مبدأ را روشن کنید: بستههای تونل که هنوز آدرسهای LAN را حمل میکنند نیاز دارند طرف مقابل مسیر بازگشت را بداند، در حالی که masquerading روی تونل آن شرط را حذف میکند و هویت کلاینتی را هم که طرف مقابل میدید حذف میکند.
قواعد و مسیرهایی که در زمان اجرا اضافه میشوند پس از راهاندازی مجدد یا بهروزرسانی فرمور از بین میروند. آنها را به سازوکار راهاندازی روتر اضافه کنید، یک بار راهاندازی مجدد کنید و دوباره از کلاینت آزمایش بگیرید: آدرس عمومی آن، کلاینت دومی که باید روی WAN بماند و شمارندههای تونل در یک اتصال تازه.