VPN سایت به سایت در برابر دسترسی از راه دور: هر کدام چه چیزی را به هم وصل می‌کند
یکی دروازه‌ها را به هم وصل می‌کند و دیگری دستگاه‌ها را. انتخاب‌گرهای ترافیک را با مسیرها مقایسه کنید، آدرس‌دهی را برنامه‌ریزی کنید و سپس ارسال و سیاست را از یک میزبان واقعی آزمایش کنید.
هر دو طرح VPN نامیده می‌شوند و مشکلات متفاوتی را حل می‌کنند. تونل سایت به سایت دو دروازه را به هم وصل می‌کند، بنابراین هر میزبانی که پشت آن‌ها قرار دارد می‌تواند بدون نصب هیچ چیز به آدرس‌های مجاز در طرف دیگر دسترسی پیدا کند. تونل دسترسی از راه دور دستگاه‌های جداگانه را یکی‌یکی به یک شبکه متصل می‌کند، هر بار یک کلاینت. این مقایسه مهم است چون بیشتر خطاهای استقرار از پیکربندی یکی با انتظار رفتار دیگری ناشی می‌شود و نشانه آن معمولاً یک وقفه زمانی در سرویسی است که تونل واقعاً به آن رسیده است.
دو طرح، دو مرز
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
هیچ‌کدام از این دو طرح دامنه پخش LAN را گسترش نمی‌دهد. دستگاه‌های طرف مقابل در فهرست کشف محلی ظاهر نمی‌شوند و انتظار چنین چیزی نخستین فرضی است که باید کنار گذاشت. نام‌های خصوصی DNS که به‌طور عمدی منتشر می‌کنید از هر پروتکل کشفی قابل پیش‌بینی‌ترند و در برابر تغییر ارائه‌دهنده دوام می‌آورند.
در یک سایت 10.10.0.0/24 و در سایت دیگر 10.20.0.0/24 را در نظر بگیرید. دروازه A به یک مسیر یا انتخاب‌گر ترافیک نیاز دارد که پیشوند 10.20.0.0/24 را به تونل بفرستد و دروازه B به تصویر آینه‌ای آن نیاز دارد. سپس میزبان‌های دو طرف از اتصال IP معمولی استفاده می‌کنند و هرگز نمی‌دانند تونلی وجود دارد. همین نامرئی بودن ویژگی کار است و به همین دلیل خرابی‌ها شبیه خطاهای معمول شبکه به نظر می‌رسند نه خطاهای تونل.
مبتنی بر سیاست و مبتنی بر مسیر یک تونل نیستند
در استقرار IPsec مبتنی بر سیاست، انتخاب‌گرهای ترافیک مورد توافق دقیقاً مشخص می‌کنند کدام جفت‌های مبدأ و مقصد محافظت می‌شوند. اگر زیرشبکه‌ای تازه پشت یک دروازه ظاهر شود و هیچ انتخاب‌گری آن را پوشش ندهد، تونل برپا می‌ماند و آن زیرشبکه به‌سادگی منتقل نمی‌شود. در طراحی مبتنی بر مسیر، یک رابط ترافیک را دریافت می‌کند و جدول مسیریابی تصمیم می‌گیرد، که باعث می‌شود افزودن یک پیشوند یک تغییر مسیریابی باشد نه مذاکره دوباره تونل.
StrongSwan هر دو نما را مستقیم نشان می‌دهد و خواندن آن‌ها با هم راهی است برای فهمیدن اینکه واقعاً کدام مدل را مستقر کرده‌اید.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'فهرست انتخاب‌گری که پیشوند مورد نظر شما را حذف کرده باشد، خرابی را بدون هیچ ضبط بسته‌ای توضیح می‌دهد و مسیری که به رابط اشتباه اشاره کند، خرابی آینه‌ای در مسیر بازگشت را توضیح می‌دهد. پیش از هر مذاکره دوباره، هر دو را بخوانید، چون تجدید کلید انتخاب‌گری را که هرگز پیکربندی نکرده‌اید اضافه نمی‌کند.
پیش از تونل، آدرس‌دهی را برنامه‌ریزی کنید
بازه‌های هم‌پوشان همان خطای طراحی هستند که با پیکربندی اصلاح نمی‌شوند. اگر هر دو سایت از 192.168.1.0/24 استفاده کنند، میزبانی که به 192.168.1.50 نیاز دارد دو گزینه دارد و هیچ راهی برای انتخاب. تونل احراز هویت می‌شود، انجمن‌های امنیتی برقرار می‌شوند و تصمیم مسیریابی با این حال اشتباه یا مبهم خواهد بود.
یکی از سه گزینه صادقانه را انتخاب کنید: شماره‌گذاری یکی از سایت‌ها را تغییر دهید، بازه هم‌پوشان را در دروازه ترجمه کنید تا هر طرف پیشوند متمایزی ببیند، یا برای آن میزبان‌ها از مسیریابی مستقیم دست بکشید و سرویس را به شکل دیگری منتشر کنید. هر کدام هزینه‌ای دارد و اولی معمولاً در افق دوساله ارزان‌ترین است. پیش از وجود تونل تصمیم بگیرید، چون بعد از آن تغییر به هر دستگاهی که آدرس قدیمی دارد دست می‌زند.
مسئله MTU را هم زود حل کنید. تونل بار مفید قابل استفاده را کاهش می‌دهد و طراحی‌ای که به قطعه‌بندی تکیه می‌کند رفتار متفاوتی از طراحی‌ای دارد که MSS را در دروازه‌ها ثابت می‌کند.
ارسال و سیاست بیرون از تونل قرار دارند
دروازه باید مایل باشد بسته‌ها را میان رابط تونل و رابط LAN ارسال کند و هر دو جهت به سیاستی نیاز دارند که سرویس را مجاز کند. در Linux این‌ها دو تنظیم جداگانه هستند، به‌علاوه قواعد دیوار آتش که تعیین می‌کنند جریان ارسال‌شده اصلاً مجاز است یا نه.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTمیزبان دریافت‌کننده لایه سومی اضافه می‌کند: دیوار آتش خودش هنوز باید کلاینتی از زیرشبکه دور را بپذیرد. سرور فایلی که فقط /24 محلی خود را مجاز می‌کند ترافیک ارسال‌شده از 10.20.0.7 را رد می‌کند، هر چقدر هم تونل سالم به نظر برسد، و این رد شدن به‌راحتی به‌عنوان خرابی مسیریابی خوانده می‌شود.
از یک میزبان آزمایش کنید، نه از دروازه
pingی که خود دروازه می‌فرستد ممکن است آدرس مبدأ و سیاست متفاوتی از ترافیک کاربران ارسال‌شده داشته باشد. همین آن را آزمایشی ضعیف و گاهی گمراه‌کننده می‌کند: موفق می‌شود در حالی که برنامه شکست می‌خورد، یا شکست می‌خورد در حالی که برنامه کار می‌کند.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullاز میزبان واقعی، آدرس مبدأ واقعی و پروتکل واقعی که برنامه استفاده می‌کند استفاده کنید. سپس مسیر بازگشت را جداگانه بخوانید، چون جهت رفتِ کارآمد بدون مسیر بازگشت وقفه زمانی‌ای تولید می‌کند که با سرویس مسدود یکسان به نظر می‌رسد.
طرح را بر اساس پرسشی که پاسخ می‌دهید انتخاب کنید: آیا شبکه‌ها را به هم وصل می‌کنید یا دستگاه‌ها را می‌پذیرید؟ هر چیز دیگری، از جمله اینکه کدام ارائه‌دهنده را پیکربندی می‌کنید، از همان پاسخ نتیجه می‌شود.