افزودن زیرشبکه دوم به VPN سایت به سایت: دو مسیر
تونل‌های سیاست‌محور به انتخابگرهای هم‌خوان در دو طرف نیاز دارند؛ تونل‌های مسیرمحور به یک مسیر. مسیر درست را انتخاب کنید و ابتدا مسیر بازگشت را درست کنید.
افزودن زیرشبکه دوم به یک تونل سایت به سایتِ کارکننده در یک طراحی پنج دقیقه و در طراحی دیگر تقریباً تمام بعدازظهر وقت می‌گیرد. وقتی تونل برای پیشوندهایی که نام می‌برید مسیر نصب می‌کند، شما یک مسیر اضافه می‌کنید و ترافیک از آن پیروی می‌کند. وقتی یک جفت انتخابگر ثابت را مذاکره می‌کند، پیشوند جدید تا زمانی که هر دو طرف بر یک جفت هم‌خوان توافق نکنند بی‌محافظت می‌ماند. سه چیز وضعیت شما را تعیین می‌کند: پیکربندی هر طرف واقعاً چه چیزی را توصیف می‌کند، آیا ترافیک مذاکره‌شده به کوچک‌ترین جفت هم‌خوان محدود می‌شود، و مسیر بازگشت محدوده جدید از آنِ کیست.
هسته را بخوانید، نه برچسب وضعیت را
تونلی که اتصال را گزارش می‌کند دست‌کم یک انجمن فرزند نصب کرده است، اما نه لزوماً همانی که فکر می‌کنید. در لینوکس هسته نشان می‌دهد چه چیزی اعمال می‌شود: ip xfrm policy جفت‌های انتخابگر را فهرست می‌کند و swanctl --list-sas (یا ipsec statusall قدیمی‌تر) نشان می‌دهد طرف‌ها بر چه چیزی توافق کرده‌اند، از جمله انتخابگرهای ترافیک در هر جهت. اگر پیشوند جدید در هیچ‌کدام نیامده باشد، هرچه فایل پیکربندی بگوید، بی‌محافظت است.
این را با جدول مسیریابی مقایسه کنید. در طراحی مسیرمحور، دستگاه تونل گام بعدی برای پیشوندهای محافظت‌شده است. طراحی سیاست‌محور اغلب مسیر مشخصی برای زیرشبکه دور ندارد و تنها مسیر پیش‌فرض را دارد، چون سیاست ترافیک را انتخاب می‌کند نه جدول.
تونل‌های سیاست‌محور: هر دو طرف باید پیشوند جدید را فهرست کنند
در اصطلاح strongSwan انتخابگر در local_ts و remote_ts زیر پیکربندی فرزند زندگی می‌کند، جانشین‌های leftsubnet و rightsubnet. پیشوند جدید باید در هر دو طرف آینه‌وار بیاید: آنچه سایت A محلی می‌خواند، سایت B دور می‌خواند. ناهماهنگی به‌ندرت خطای تمیزی می‌دهد. طرف‌ها به اشتراک باریک می‌شوند، پیشوند قدیمی کار می‌کند و تنها جدید بی‌صدا شکست می‌خورد.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyدر pfSense یا OPNsense این یعنی یک ورودی دوم Phase 2 که زیرشبکه محلی جدید را با زیرشبکه دور جدید جفت می‌کند و سپس اعمال. ورودی قدیمی را نگه دارید؛ جایگزینی آن زیرشبکه اصلی را جابه‌جا می‌کند نه اینکه بیفزاید. اگر Phase 2 موجودی از قبل ابرشبکه‌ای مانند 0.0.0.0/0 یا محدوده‌ای خلاصه‌شده را بپوشاند، ورودی باریک‌تری کنارش اضافه نکنید: انتخابگرهای هم‌پوشان سیاست‌های رقیب نصب می‌کنند و ترتیب ارزیابی برنده را تعیین می‌کند.
IKEv1 هر جفت زیرشبکه را Phase 2 خودش می‌کند و طرفی که در هر تبادل یک جفت می‌گیرد بقیه را رها می‌کند. IKEv2 می‌تواند چند جفت انتخابگر را در یک فرزند حمل کند، اما تنها اگر هر دو پیاده‌سازی بپذیرند. فهرست swanctl --list-sas حقیقت است؛ آنچه تایپ کرده‌اید یک درخواست است.
تونل‌های مسیرمحور: مسیر همان سیاست است
رابط XFRM یا دستگاه VTI ترافیک را بر پایه جدول مسیریابی حمل می‌کند. پیشوند جدید را در هر دو سایت به دستگاه نشانه می‌روید و وضعیت بسته‌شده به تبدیل رابط اعمال می‌شود. جفت انتخابگری برای همگام‌سازی نیست، از این رو این طراحی با زیادشدن زیرشبکه‌ها بهتر مقیاس می‌گیرد. راهنمای ارسال strongSwan سمت هسته را با جزئیات بیشتری می‌گوید.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard همین ایده را پیش‌تر می‌برد. AllowedIPs هم‌زمان فهرست مجاز رمزنگاری و از راه wg-quick ورودی جدول مسیریابی است. پیشوند را تنها در یک طرف بیفزایید و دست‌دادن، بسته‌های خروجی و سکوت می‌گیرید، چون طرف دور بسته‌هایی را که مبدأشان در فهرستش نیست دور می‌ریزد. شکل wg set تمام فهرست را جایگزین می‌کند، پس پیشوندهایی را که کار می‌کردند دوباره بنویسید وگرنه قطعشان می‌کنید:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0آن فرمان دوم وقتی از wg set به‌جای wg-quick استفاده کرده‌اید اختیاری نیست. هسته فهرست مجاز جدید را بی‌درنگ می‌پذیرد، اما هیچ‌چیز مسیری برایش اضافه نمی‌کند، پس ترافیک تولیدشده محلی هنوز از دروازه پیش‌فرض بیرون می‌رود. این رایج‌ترین دلیل کارکردن زیرشبکه جدید WireGuard از میزبان تونل و نه از لپ‌تاپ است.
مسیر بازگشت بیشتر از خود تونل شکست می‌خورد
میزبان‌های زیرشبکه دور جدید باید پاسخ‌ها را از دروازه VPN بازگردانند. وقتی آن دروازه مسیریاب پیش‌فرضشان نیست پاسخ به مسیریاب LAN می‌رود که یا دورش می‌ریزد یا با نشانی مبدأ خصوصی به اینترنت می‌فرستد. از میزبانی در طرف دور آزمایش کنید نه از دروازه: ip route get 10.30.20.15 در لینوکس یا Find-NetRoute -RemoteIPAddress 10.30.20.15 در PowerShell گام بعدی‌ای را که میزبان واقعاً به کار می‌برد نشان می‌دهد. اگر پاسخ نقطه پایانی تونل نبود، مسیر ایستایی برای پیشوند جدید همان‌جا اضافه کنید.
NAT مبدأ در سایتی که مسیر بازگشت ندارد جایگزین مشروعی است و بسیاری از استقرارهای hub-and-spoke با آن از دست‌زدن به هر سرور پرهیز می‌کنند. آن را بر پیشوند جدید در دروازه سمت مقصد هم اعمال کنید:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEهزینه واقعی است. گزارش‌های دور دیگر نشانی‌های مبدأ فردی را نشان نمی‌دهند و قواعد دیوار آتش که بر زیرشبکه اصلی بنا شده‌اند در یک قاعده برای دروازه فرو می‌ریزند. این را آگاهانه انتخاب کنید نه به این دلیل که مسیری کم بود.
دیوارهای آتش نیمه دیگر مسیر بازگشت هستند. دستگاه‌های ناحیه‌محور ناحیه یک رابط تونل موجود را به‌طور خودکار به زیرشبکه جدید گسترش نمی‌دهند و قاعده‌ای که برای پیشوند قدیمی نوشته شده تطبیق نمی‌یابد. پیش از متهم کردن IPsec، زیرشبکه جدید را به ناحیه یا به جفت قاعده در هر دو جهت بیفزایید.
با سه پرسش تصمیم بگیرید، سپس با ترافیک بررسی کنید
نسخه کوتاه: آیا پیکربندی طرف پیشوندها را نام می‌برد (سیاست‌محور)، یا ترافیک به رابطی مسیریابی می‌شود (مسیرمحور)؟ آیا هر دو سر پیشوند جدید را فهرست می‌کنند؟ آیا راهی برای بازگشت از زیرشبکه جدید به محدوده مبدأ اصلی هست؟
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
بررسی همان جایی است که بیشتر تغییرها زود بسته می‌شوند. پینگ از دروازه چیز کمی اثبات می‌کند، چون دروازه از خودش مبدأ می‌گیرد و اغلب با سیاستی متفاوت از میزبان تطبیق می‌یابد. از میزبانی در زیرشبکه جدید پینگ کنید، سپس برنامه‌ای را که انگیزه تغییر بود اجرا کنید و شمارنده‌ها را ببینید نه نماد وضعیت را.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showدر تونل سیاست‌محور شمارنده‌های ip xfrm state باید در هر دو جهت بالا بروند؛ شمارنده‌های تخت یعنی بسته مسیریابی شده اما انتخاب نشده است. در WireGuard، wg show انتقال هر طرف را گزارش می‌کند و دست‌دادن با صفر بایت دریافتی به فهرست طرف دور یا مسیر بازگشتش اشاره دارد.
پایان کار: پیشوند، انتخابگر یا مسیر سمت طرف، تصمیم مسیر بازگشت و ورودی دیوار آتش را همراه با بقیه فهرست تونل ثبت کنید. سپس یک دروازه را راه‌اندازی دوباره کنید و باز بیازمایید: مسیری که دستی اضافه شده از میان می‌رود و نفر بعدی نباید دوباره آن را کشف کند.