مسیریابی منبع برای دو استخر VPN: قاعده شما چه چیزی را از دست می‌دهد
قاعده‌ای به شکل from پیش از آنکه SNAT بازنویسی‌اش کند با آدرس مشتری مطابقت دارد، و آزمایش از دروازه با هیچ‌یک مطابقت نمی‌کند. جست‌وجو را برای هر استخر اجرا کنید و در عوض اولویت‌ها را بخوانید.
دو استخر مشتری، یک دروازه و طرح پیش‌پاافتاده به نظر می‌رسد: یک قاعده استخر اول را از uplink سریع بیرون می‌برد، قاعده دیگر استخر دوم را از تونل شریک عبور می‌دهد. سپس قاعده‌ها سر جای خود هستند و استخر دوم همچنان از مسیر پیش‌فرض خارج می‌شود. قاعده خراب نیست. منبع بسته چیزی نیست که نویسنده در لحظه جست‌وجو انتظار داشت، چون ترجمه و جست‌وجو در نقاط مختلف سفر همان بسته رخ می‌دهند و ترتیب برخلاف نمودار ذهنی است که بیشتر مردم می‌کشند.
جست‌وجو پیش از بازنویسی منبع رخ می‌دهد
برای بسته‌ای که از مشتری VPN ارسال می‌شود، هسته یک توالی ثابت اجرا می‌کند. بسته روی رابط تونل می‌رسد، از prerouting می‌گذرد که conntrack و DNAT در آن قرار دارند، سپس تصمیم مسیریابی گرفته می‌شود، سپس ارسال، سپس postrouting که SNAT در آن آخر از همه اعمال می‌شود. قاعده‌ای به شکل from در همان تصمیم مسیریابی بررسی می‌شود، یعنی آدرس اصلی مشتری را می‌بیند، نه آدرس ترجمه‌شده را.
پس افزودن قاعده masquerade تغییر نمی‌دهد که کدام سیاست با جریان خروجی مطابقت دارد. آنچه تغییر می‌کند چیزی است که طرف دور می‌بیند و بنابراین کدام مسیر بازگشت وجود دارد. این دو پیامد متفاوت است و بازبینی تغییرات مدام آن‌ها را با هم اشتباه می‌گیرد. جدا کنیدشان و طرح معمولاً در عرض یک دقیقه روشن می‌شود.
آدرس ترجمه‌شده در جهت پاسخ در قاعده‌ها ظاهر می‌شود. بسته‌ای که به دروازه بازمی‌گردد به آدرس ترجمه‌شده نشانه‌گذاری شده است، و اگر قاعده‌های سیاستی بر پایه مقصد یا رابط ورودی داشته باشید، همان مقداری است که مطابقت می‌دهید. همان اتصال، در هر جهت منبع حقیقت متفاوت.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
پس دو استخر با منبع متفاوت واقعاً به جدول‌های متفاوت نیاز دارند و طرح درست است. چیزی که جدول بالا رد می‌کند میان‌بر عیب‌یابی با نگاه کردن به آنچه سایت دور دریافت کرده و استنتاج قاعده از آن است.
آزمایش از دروازه آزمایش استخر نیست
ترافیکی که خود دروازه تولید می‌کند هرگز از prerouting نمی‌گذرد، چون روی هیچ رابطی وارد نشده است. در مسیر output مسیریابی می‌شود، با آدرس خود دروازه به‌عنوان منبع، و قاعده from که بر محدوده مشتری بنا شده مطابقت نخواهد کرد. هر تیکتی در این حوزه که می‌گوید از جعبه کار می‌کند ولی از مشتری نه، تکرار همان واقعیت است.
مشتری را شبیه‌سازی کنید نه تقریب. جست‌وجوی مسیریابی را می‌توان مستقیم پرسید، با دادن منبع و رابط ورودی:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201آن را یک بار برای هر استخر اجرا کنید. اگر دو فرمان همان رابط را برگردانند، قاعده‌ها استخرها را جدا نمی‌کنند و دلیل یا قاعده‌ای غایب است یا قاعده‌ای با اولویت بالاتر که با هر دو مطابقت دارد. اگر رابط‌های متفاوت برگردانند اما مشتری همچنان شکست بخورد، خطا پس از جست‌وجو است و می‌توانید نگاه کردن به قاعده‌ها را متوقف کنید.
اولویت، نه جایگاه در فایل
قاعده‌ها به ترتیب صعودی اولویت ارزیابی می‌شوند و عدد مهم است، نه ترتیبی که تایپ کردید. جدول local در اولویت 0، جدول main در 32766 و قاعده پیش‌فرض در 32767 است، به همین دلیل قاعده‌ای که با اولویت پیش‌فرض افزوده شود نزدیک انتهای فهرست می‌نشیند و از تقریباً همه می‌بازد.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201اولویت صریح ترتیب مورد نظر را در فایل و در بازبینی دیدنی می‌کند. همچنین مانع می‌شود افزوده بعدی بی‌صدا از قاعده موجود جلو بزند، که شایع‌ترین دلیل از کار افتادن یک سیاست فعال پس از تغییری بی‌ربط است.
قاعده مطابق که به جدول ناقص اشاره می‌کند دام دیگر است. اگر جدول 201 مسیر پیش‌فرض داشته باشد اما مسیری به مقصد نداشته باشد، بسته دور ریخته یا به جای اشتباه فرستاده می‌شود و قاعده به‌تنهایی کاملاً درست به نظر می‌رسد. جدول را بخوانید، نه فقط قاعده را. قاعده یک اشاره‌گر است و جدول خالی اشاره‌گری به هیچ‌جا.
مسیر بازگشت هنوز باید وجود داشته باشد
سیاست منبع یک خروجی انتخاب می‌کند. مسیر بازگشت نمی‌سازد. اگر استخر دوم از تونل شریک خارج شود، شریک باید بداند چگونه به 172.31.8.0/24 برسد، یا با مسیری بازگشتی به دروازه یا با دریافت آدرس‌های ترجمه‌شده‌ای که از قبل می‌شناسد.
انتخاب میان این دو تصمیمی طراحی با پیامدهای دیدنی است. مسیریابی محدوده مشتری به عقب هویت هر مشتری را نزد شریک حفظ می‌کند و می‌خواهد پیشوند شما را بپذیرد. ترجمه استخر را پشت یک آدرس پنهان می‌کند و می‌خواهد شریک فقط همان آدرس را بپذیرد، به قیمت اینکه گزارش‌های شما و او دیگر بر سر اینکه چه کسی وصل شده هم‌نظر نباشند.
هر چه انتخاب کنید، آن را کنار تعریف استخر بنویسید. مسیر بازگشتی که فقط در حافظه کسی وجود دارد دقیقاً همان چیزی است که تا وقتی شریک فایروال را تغییر دهد دوام می‌آورد و سپس یک روز برای بازسازی می‌برد.
تونل خود دروازه را در سیاست نگیرید
قاعده‌هایی که برای مشتری می‌نویسید بر ترافیکی که دروازه تولید می‌کند هم اعمال می‌شود، مگر اینکه آن را استثنا کنید. قاعده‌ای گسترده بر پایه یک نشانه یا رابط خروجی می‌تواند اتصال خود دروازه به شریک را بگیرد و آنگاه تونلی که سیاست را حمل می‌کند توسط سیاست مسیریابی می‌شود. این یک حلقه یا قطعی می‌سازد که شبیه خرابی ارائه‌دهنده به نظر می‌رسد.
هر قاعده را تا آنجا که طرح اجازه می‌دهد باریک کنید: پیشوند منبع، رابط ورودی و در جایی که پشتیبانی شود نشانه‌ای که فقط بسته‌های مشتری آن را دارند. سپس پس از هر تغییر قاعده اتصال خود دروازه را آزمایش کنید، چون خرابی خودارجاع است و در آزمایش مشتری دیده نمی‌شود.
صفحه راهنمای ip-rule معنی انتخاب‌گر و اولویت را مستند می‌کند. آن را با آزمایش جست‌وجو برای هر استخر ترکیب کنید و طرح قابل‌بررسی می‌شود، که همان تفاوت مسیریابی سیاستی یک‌ساله و مسیریابی سیاستی است که همه از دست زدن به آن می‌ترسند.