برای VPN از سایت به سایت چه چیزی ثبت کنیم: انتخاب‌گرها و دامنه
رکورد انتخاب‌گرها باید بگوید هر طرف چه می‌بیند. پیشوندهای پیکربندی‌شده، انجمن‌های مذاکره‌شده، ترجمه و مالکیت سرویس همگی در آن جای دارند.
شش ماه پس از راه‌افتادن تونل، یک زیرشبکه تازه دیگر با سیاست تطبیق نمی‌یابد و تنها سند روی اشتراک می‌گوید VPN دفتر. این همان شکستی است که رکورد انتخاب‌گرها از آن جلوگیری می‌کند، و مشخص است: مجموعه‌ای از نشانی‌ها تغییر کرد در حالی که کاغذبازی تغییر نکرد. نوشتن درست رکورد یعنی بدانید کدام یک از چند مجموعه نشانی را توصیف می‌کنید، و آنچه را که طرف مقابل واقعاً اعمال می‌کند ثبت کنید نه آنچه را که خودتان پیکربندی کرده‌اید.
پیکربندی‌شده همان مذاکره‌شده نیست
در تونل IPsec مبتنی بر سیاست، هر طرف انتخاب‌گرهای ترافیک را پیشنهاد می‌دهد: بازه‌های مبدأ و مقصد برای انجمن فرزند. طرف پاسخ‌دهنده مجاز است آن پیشنهاد را باریک‌تر کند ، بنابراین انجمن نصب‌شده ممکن است کمتر از آنچه پیکربندی فهرست می‌کند را پوشش دهد. رکوردی که پیکربندی را کپی می‌کند پس نیتی را توصیف می‌کند، نه دامنه حفاظت کنونی را. آن دو بی‌صدا از هم جدا می‌شوند و هیچ چیز در صفحه وضعیت تونل به آن اشاره نمی‌کند.
هر دو ستون را نگه دارید، با تاریخی که آن‌ها را مشاهده کردید. انتخاب‌گر پیکربندی‌شده همان چیزی است که قصد داشتید؛ انتخاب‌گر مذاکره‌شده همان چیزی است که هسته همین حالا اعمال می‌کند. وقتی متفاوت‌اند، همان تفاوت بسیار بیشتر از یک اشکال مسیریابی یک شکست غافلگیرکننده را توضیح می‌دهد.
یک انجمن همچنین نماینده هر جفت پیکربندی‌شده نیست. تونلی با چند ترکیب انتخاب‌گر می‌تواند به چند انجمن فرزند برسد، و رکوردی که یکی از آن‌ها را فهرست می‌کند فهرست ناقصی است. آن‌ها را بشمارید نه اینکه خلاصه‌شان کنید.
تونل‌های مبتنی بر مسیر جور دیگری انتخاب می‌کنند
با یک رابط مبتنی بر مسیر، جدول مسیریابی تعیین می‌کند چه چیزی وارد تونل می‌شود و انتخاب‌گرها می‌توانند عمداً گسترده باشند. این طرحی مشروع است نه سهل‌انگاری، و رکورد باید آن را همین‌گونه توصیف کند. مسیر، رابطی که به آن اشاره دارد، و سیاست دیوار آتش که محدود می‌کند کدام سرویس‌ها در دسترس‌اند را بنویسید. دامنه حفاظت عمداً گسترده است و باریک‌سازی را دامنه سرویس انجام می‌دهد.
کپی کردن یک الگوی مبتنی بر سیاست روی تونلی مبتنی بر مسیر سندی می‌سازد که سازوکاری را توصیف می‌کند که استقرار از آن استفاده نمی‌کند. مهندس بعدی آن‌گاه به دنبال انتخاب‌گرهایی می‌گردد که هرگز قرار نبوده آنجا باشند، و نتیجه می‌گیرد تونل بد پیکربندی شده در حالی که فقط بد مستند شده است.
ترجمه به همان جدول تعلق دارد
وقتی NAT بازه متفاوتی را به طرف مقابل ارائه می‌دهد، پیشوندهای اصلی و ترجمه‌شده را با هم ثبت کنید. مرحله‌ای را که انتخاب‌گرها و قواعد دسترسی با آن‌ها تطبیق می‌یابند یادداشت کنید، چون ترتیب تعیین می‌کند طرف دور هرگز نشانی را که نوشته‌اید ببیند یا نه. جدولی که فقط یکی از دو بازه را دارد از نبود جدول بدتر است، چون کامل به نظر می‌رسد.
این همان جزئیاتی است که پس از تغییر NAT یک تونل سالم را می‌شکند: انتخاب‌گر هنوز با پیشوند اصلی تطبیق می‌یابد، طرف مقابل اکنون پیشوند ترجمه‌شده دریافت می‌کند، و مسیر بازگشتش به نشانی اشاره می‌کند که دیگر وجود ندارد. هیچ چیز در لحظه‌ای که آن دو از توافق بازمی‌مانند خطایی ثبت نمی‌کند.
DNS خصوصی هم به همان جا تعلق دارد. نامی که به نشانی‌ای حل می‌شود که از سایت مربوطه قابل استفاده نیست، خطای مستندسازی همراه با یک بلیت پشتیبانی است و تقصیر به گردن تونل انداخته می‌شود.
الزام سرویس را پیوست کنید
بازه محافظت‌شده فهرست مجوز نیست. بنویسید کدام سرویس‌ها باید از کدام مبدأ در دسترس باشند و مالک برنامه پشت آن‌ها کیست. آن دو فیلد به پرسش‌های متفاوتی پاسخ می‌دهند و درهم آمیختنشان همان راهی است که یک بازبینی امنیتی به بحث درباره مسیریابی به‌جای دسترسی می‌انجامد.
سپس مدیر شبکه‌ای را که قاعده را نگه می‌دارد نام ببرید. فهرست انتخاب‌گرها بدون مالک بی‌صدا کهنه می‌شود، و کهنه از غلط قابل تشخیص نیست وقتی تونل ساعت دو بامداد می‌شکند. مالک همچنین کسی است که می‌تواند تأیید کند تغییری عمدی بوده است.
رکورد را به طرح آزمون تبدیل کنید
برای هر مسیر لازم، یک میزبان مبدأ و مقصد نمونه انتخاب کنید و مسیر، سرویس و دروازه پاسخ مورد انتظار را یادداشت کنید. این سند را به طرح آزمون تبدیل می‌کند نه توصیف. انجمن زنده را با فرمان زیر بخوانید و آن را با ردیف مذاکره‌شده‌ای که نوشته‌اید مقایسه کنید.
swanctl --list-sasاسکلتی پنج‌خطی معمولاً برای صادق نگه داشتن رکورد کافی است. نسخه زیر بدون بریدن در بلیت تغییر جا می‌شود:
sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netopsپینگ فقط به دروازه آزمون پذیرش نیست. هرگز مسیر عبور را تمرین نمی‌دهد، پس می‌تواند موفق شود در حالی که هر جریان فورواردشده شکست می‌خورد. از میزبانی در یک طرف به سرویسی در طرف دیگر آزمون کنید و تأیید کنید پاسخ از تونل می‌رسد. اگر فقط پینگ موفق شود، رکورد همین حالا همان مشکل فورواردینگ را یافته که برای پیشگیری از آن نوشته شده بود. مستندات فورواردینگ strongSwan توضیح می‌دهد که انتخاب‌گرها، مسیرها و فورواردینگ روی یک همتای Linux چگونه برهم اثر می‌گذارند.