VPN سایت‌به‌سایت مبتنی بر مسیر در برابر مبتنی بر سیاست: چه تفاوتی دارد
IPsec مبتنی بر سیاست ترافیک را با انتخاب‌گر برمی‌گزیند؛ نوع مبتنی بر مسیر آن را از رابط تونل می‌فرستد. هر دو همچنان به قواعد فایروال و مسیر بازگشت نیاز دارند.
هر دو طراحی همان ترافیک را با همان ماشین IPsec محافظت می‌کنند و تفاوتشان در این است که چه چیزی تعیین می‌کند کدام بسته وارد تونل شود. در اتصال مبتنی بر سیاست، انتخاب‌گرهای ترافیک مورد مذاکره این کار را انجام می‌دهند؛ در نوع مبتنی بر مسیر، مسیری که به رابط تونل اشاره می‌کند این کار را می‌کند. اشتباه گرفتن این دو، همان رشته پشتیبانی آشنایی را می‌سازد که در آن تونل برقرار گزارش می‌شود اما برنامه به هیچ چیز نمی‌رسد. این تمایز بیشترین اهمیت را دارد وقتی شبکه‌ای اضافه می‌کنید، پروتکل مسیریابی اجرا می‌کنید یا مسیری را عیب‌یابی می‌کنید که بی‌صدا از خروجی اشتباه بیرون می‌رود.
دو راه برای تعیین اینکه چه چیزی وارد تونل می‌شود
VPN مبتنی بر سیاست یک سیاست امنیتی می‌سازد که با پیشوندهای مبدأ و مقصد مطابقت دارد و سپس هر چیزی را که جا شود رمزنگاری می‌کند. طرف مقابل باید انتخاب‌گرهای سازگار را مذاکره کند، بنابراین دامنه مؤثر در نهایت به اشتراک آنچه هر دو طرف پیشنهاد کرده‌اند می‌رسد. هیچ چیز بیرون از آن اشتراک محافظت نمی‌شود، هر چه جدول مسیریابی بگوید.
VPN مبتنی بر مسیر رابطی می‌سازد که نماینده تونل است و به جدول مسیریابی اجازه می‌دهد ترافیک را به آن بفرستد. دیمن IKE همچنان وضعیت و سیاست هر رابط را نصب می‌کند و این همان جزئیاتی است که مردم وقتی تصمیم می‌گیرند مسیرها جای رمزنگاری را گرفته‌اند از آن می‌گذرند. هر دو طراحی با IPsec رمزنگاری می‌کنند؛ تنها سازوکار انتخاب متفاوت است.
مقایسه زیر را به‌عنوان مجموعه‌ای از امضاهای خرابی بخوانید نه جدول امتیاز، چون هیچ ستونی به‌تنهایی برنده نیست.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
مبتنی بر سیاست: انتخاب‌گر همان قرارداد است
انتخاب‌گرها مذاکره می‌شوند، نه فقط پیکربندی. 10.10.0.0/16 را در یک طرف و 10.10.1.0/24 را در طرف دیگر پیشنهاد کنید؛ آنگاه انجمن چیزی را پوشش می‌دهد که مذاکره بر آن قرار گرفت و هر میزبان دیگری بیرون می‌ماند.
وضعیت نصب‌شده را بخوانید نه فایل پیکربندی را. در همتای Linux، جدول‌های خود کرنل حقیقت پایه هستند و نشان می‌دهند چه چیزی از مذاکره جان سالم به در برده است. سیاستی که پیشوندهای درست را نام می‌برد اما وضعیت منطبقی ندارد یعنی انجمن هرگز بالا نیامده است. وضعیت همراه با سیاستی برای پیشوند اشتباه، مشکل معکوس است و تونلی می‌سازد که سالم به نظر می‌رسد در حالی که یک زیرشبکه به هیچ چیز نمی‌رسد.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasهر دو خروجی را با پیشوندهایی که فکر می‌کنید محافظت می‌کنید مقایسه کنید. همین یک مقایسه بیشتر گزارش‌های تونل کارکننده با سرور دسترس‌ناپذیر را حل می‌کند. همچنین نشان می‌دهد کدام همتا را باید تغییر دهید، چون عدم تطابق معمولاً فقط در یک جهت دیده می‌شود.
مبتنی بر مسیر: رابط همان قرارداد است
رابط XFRM به تونل نام و هویت می‌دهد و ترافیک به آن می‌رسد چون جدول مسیریابی چنین می‌گوید. آنگاه چند پیشوند دوردست به مسئله مسیریابی تبدیل می‌شوند نه مسئله انتخاب‌گر، و یک پروتکل مسیریابی می‌تواند آن‌ها را اعلام کند. سود واقعی همین است، نه رمزنگاری.
رابط نیاز به سیاست را از بین نمی‌برد. دیمن قواعدی برای هر رابط وابسته به هویت رابط نصب می‌کند، بنابراین بسته‌ای که به رابط اشتباه برسد باز هم شکست می‌خورد. نشانی مبدأیی که همتا نمی‌پذیرد نیز شکست می‌خورد، حتی با مسیری بی‌عیب. مبتنی بر مسیر یعنی مسیر ورود را تعیین می‌کند، نه اینکه سیاست ناپدید شده است.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10وقتی مسیر برقرار شد، شمارنده‌های رابط را تماشا کنید. مسیری که وجود دارد اما شمارنده‌ها صفر می‌مانند یعنی هیچ چیز در تونل تطبیق داده نمی‌شود، که معمولاً به وضعیت نبودن اشاره دارد نه به مسیر نبودن.
کجا این دو طراحی واقعاً از هم جدا می‌شوند
افزودن شبکه تمیزترین آزمون برای اینکه کدام مدل به شما می‌خورد است. طراحی مبتنی بر مسیر یک مسیر اضافه می‌کند و حداکثر یک بار انتخاب‌گر را گسترش می‌دهد، در حالی که طراحی مبتنی بر سیاست جفت‌های پیشوند را روی هر دو همتا ویرایش می‌کند و دوباره مذاکره می‌کند. دو زیرشبکه پایدار آن ویرایش را بی‌اهمیت می‌کند و بیست تا آن را به یک پروژه تبدیل می‌کند.
هیچ‌یک از دو مدل جای فایروال را نمی‌گیرد و مقایسه‌ها معمولاً پیش از این نقطه متوقف می‌شوند. انتخاب‌گر گسترده یا مسیر گسترده تعیین می‌کند چه چیزی رمزنگاری می‌شود، نه چه چیزی مجاز است.
رفتار MTU هم در عمل متفاوت است. کپسوله‌سازی بار مفید قابل استفاده را کم می‌کند و رابط مبتنی بر مسیر MTU خودش را حمل می‌کند، بنابراین محدود کردن MSS در هر دو دروازه از نشانه چاه سیاه جلوگیری می‌کند؛ جایی که پاسخ‌های کوچک می‌رسند و بزرگ‌ها ناپدید می‌شوند. تونل‌های مبتنی بر سیاست از سمت دیگر به همان دیوار می‌خورند، چون انتخاب‌گر چیزی درباره اندازه بسته نمی‌گوید. محدودیت را آگاهانه تنظیم کنید نه اینکه همتا را سرزنش کنید.
مهاجرت بدون از دست دادن مسیر بازگشت
جفت‌های پیشوند موجود را پیش از هر تغییری ثبت کنید، سپس یک مسیر برنامه را جابه‌جا کنید و آن را سرتاسر ببینید. تونلی که برقرار می‌شود تونلی نیست که ارسال می‌کند و تفاوت در جهت پاسخ ظاهر می‌شود.
وقتی همتاها وصل می‌شوند اما میزبان‌های LAN نمی‌توانند، مسیر بازگشت و نشانی مبدأیی را که میزبان دور استفاده خواهد کرد بررسی کنید. میزبانی با دو رابط ممکن است از رابط اشتباه پاسخ دهد و هیچ تغییر انتخاب‌گری آن را درست نمی‌کند. پیش از ویرایش الگوریتم‌ها ترافیک را در هر دو سر ضبط کنید.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsدر حین کار مسیر مدیریتی‌ای نگه دارید که به تونل وابسته نباشد. عقب‌نشینی آسان‌تر است وقتی دسترسی خود دروازه روی اتصالی که عیب‌یابی می‌کنید سوار نیست.