استخرهای VPN دوپشته: آدرس‌دهی به هر دو خانواده در strongSwan

یک دروازه می‌تواند به کاربر سیار هم نشانی مجازی IPv4 و هم IPv6 بدهد، در حالی که تونل بیرونی همچنان روی IPv4 سفر می‌کند. این‌ها تصمیم‌های مستقلی هستند و برخورد با آن‌ها به‌عنوان یک تصمیم همان جایی است که طرح‌های دوپشته معمولاً از هم می‌پاشند. خانواده‌های داخلی کارخواه، پیشوندهای محافظت‌شده‌ای که می‌تواند به آن‌ها برسد، و ترابری که کپسوله‌سازی را حمل می‌کند سه انتخاب جداگانه‌اند.

بیشتر سردرگمی از آنجا می‌آید که واژهٔ دوپشته به طرحی اطلاق می‌شود که فقط در یک جا دوپشته است. یک سرویس می‌تواند در داخل دوپشته باشد، روی نشانی بیرونی خود تک‌پشته، و باز هم برای کارخواه‌ها کاملاً خوب کار کند. آنچه نمی‌تواند انجام دهد این است که تصادفی کار کند.

دو خانواده در داخل، یک مسیر در بیرون

اتصال بیرونی IKE روی UDP است و به یک خانوادهٔ نشانی قابل‌دسترس از هر جایی که کارخواه هست نیاز دارد. نشانی داخلی IPv6 به ارائه‌دهندهٔ دارای IPv6 نیاز ندارد، زیرا بستهٔ داخلی بارِ درون بستهٔ بیرونی است. بسیاری از استقرارهای کارآمد پیشوندهای IPv6 را از پیوند بالاروی فقط IPv4 عبور می‌دهند.

آنچه مسیر بیرونی واقعاً محدود می‌کند دسترس‌پذیری و گذر از NAT است. اگر دروازه فقط نشانی IPv4 را اعلام کند، کارخواهی در شبکهٔ فقط IPv6 به‌هیچ‌وجه نمی‌تواند متصل شود، هر استخری که پیکربندی کرده باشید. خانوادهٔ بیرونی را بر اساس جمعیت کارخواهانتان تعیین کنید، نه بر اساس طرح نشانی داخلی.

به کارخواه در هر خانواده یک نشانی بدهید

درخواست هر دو خانواده در سمت کارخواه یک جملهٔ یک‌خطی است، به شرط آنکه دروازه چیزی برای تقسیم داشته باشد. استخرهای نام‌دار منابع را از شبکه‌های سرویس جدا نگه می‌دارند و همین ویژگی است که قواعد دیوار آتش را شش ماه بعد خوانا می‌کند.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

مقدار vips از هر خانواده یک نشانی می‌خواهد و فهرست استخرها تعیین می‌کند که آن نشانی‌ها از کجا می‌آیند. مستندات strongSwan دربارهٔ IP مجازی درخواست‌های متعدد و تخصیص استخر را پوشش می‌دهد، از جمله این نکته که کارخواهی که نشانی مشخصی می‌خواهد تنها ترجیحی را بیان می‌کند که پاسخ‌دهنده می‌تواند آن را نادیده بگیرد. قاعدهٔ دسترسی‌ای نسازید که فرض کند کارخواه همیشه همان مقدار را دریافت می‌کند.

پیشوند یکتای محلی خودتان را تولید کنید، نه اینکه نمونه را کپی کنید. دو سازمانی که هر دو fd42::/16 آن را مستقر کنند، نخستین بار که به هم متصل شوند برخورد را کشف خواهند کرد و عیب‌یابی آن خوشایند نیست.

انتخابگرها مقصدها را توصیف می‌کنند، نه منابع را

انتخابگرهای ترافیک محلی SA فرزند می‌گویند کدام شبکه‌های محافظت‌شده پشت دروازه هستند و انتخابگرهای دور توصیف می‌کنند که کارخواه چه چیزی را می‌تواند به‌عنوان منبع به کار ببرد. نشانی استخر مجازی به سمت منبع آن سیاست تعلق دارد؛ گذاشتنش در فهرست مقصد خوانش نادرست رایجی از پیکربندی است.

هر دو خانواده به مسیرهای بازگشت و ارسال مجاز روی دروازه نیاز دارند. افزودن یک پیشوند به انتخابگر بدون مسیری بازگشتی به استخر تونلی می‌سازد که برقرار می‌شود، یک جهت ترافیک را عبور می‌دهد و پاسخ را بی‌صدا دور می‌ریزد. انتخابگر سیاست است، نه مسیریابی.

استخرها و پیشوندهای سرویس را در بلوک‌های جداگانهٔ طرح نشانی خود نگه دارید. وقتی هم‌پوشانی پیدا کنند، مسیری که باید به میزبان محافظت‌شده برسد می‌تواند با نشانی استخر منطبق شود و در تونل ناپدید گردد.

DNS و مسیر پاسخ تعیین می‌کنند که آیا کار تمام‌شده به نظر می‌رسد

پاسخ‌های حل‌کننده مستقل از ترابری‌اند که برای رسیدن به حل‌کننده به کار می‌رود. یک نام می‌تواند رکورد A، رکورد AAAA یا هر دو را برگرداند و کارخواه بر اساس قواعد ترجیح خودش انتخاب می‌کند . اگر سرویس داخلی رکورد AAAA منتشر کند اما چیزی آن پیشوند را مسیریابی نکند، کارخواهان در شبکه‌های دوپشته ابتدا مسیر IPv6 را امتحان می‌کنند و تا زمانی که شکست بخورد همان‌جا می‌مانند. در این مدت هیچ چیز در پیکربندی تونل اشتباه به نظر نمی‌رسد.

پس برای هر نام تعیین کنید کدام خانواده‌ها باید قابل‌استفاده باشند، سپس بررسی کنید که پیشوند مربوطه در انتخابگر هست و مسیر بازگشت دارد. این تصمیمی سرویس‌به‌سرویس است. انتشار یکجای هر دو نوع رکورد همان راهی است که یک سرویس کارآمد فقط IPv4 برای نیمی از کاربرانش شروع به تمام‌شدن مهلت می‌کند.

پیش از آنکه تمام‌شده بنامیدش، هر دو خانواده را بررسی کنید

پیکربندی‌ای که بارگذاری می‌شود پیکربندی‌ای نیست که کار می‌کند. وضعیتی را که دیمن گزارش می‌دهد بخوانید، تخصیص‌های استخر را تأیید کنید و سپس به مسیرهایی نگاه کنید که کارخواه واقعاً نصب کرده است.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

دو فرمان نخست SAهای فرزند برقرارشده و اینکه کدام استخرها هنوز نشانی آزاد دارند را نشان می‌دهند، پس طرحی که برای نخستین کارخواه کار می‌کند و برای دهمی شکست می‌خورد آشکار می‌شود. دو فرمان آخر نشان می‌دهند که آیا کارخواه نشانی سراسری IPv6 از استخر گرفته است و ترافیک به یک پیشوند محافظت‌شده در واقع کجا می‌رود. نشانی تخصیص‌یافته را با استخری که پیکربندی کرده‌اید بسنجید، نه با نشانی‌ای که آرزو داشتید. اگر پاسخ‌دهنده تحت سیاستش مقدار دیگری انتخاب کرده باشد، مسیرها و قواعد دیوار آتش باید همچنان با انتخاب او هم‌خوان باشند.

سپس برای هر خانواده یک میزبان محافظت‌شده را آزمایش کنید و نامی را آزمایش کنید که به هر دو تجزیه می‌شود. آزمایش تک‌خانواده‌ای هیچ چیزی دربارهٔ نیمی از طرح که تمرین نکرده‌اید نمی‌گوید و همان نیمه معمولاً جای مسیر گمشده است.