ULA در IPv6 داخل VPN: آدرسدهی خصوصی، نه حریم خصوصی
آدرسهای محلی یکتا به یک VPN یک طرح داخلی پایدار میدهند و نه چیز دیگر. پیشوند را درست تولید کنید و سیاست دیوار آتش را تصمیمی جداگانه نگه دارید.
آدرسهایی که خصوصی به نظر میرسند به معنایی که بیشتر مردم میگویند خصوصی نیستند، و آدرسدهی محلی یکتای IPv6 روشنترین نمونه است. یک پیشوند ULA به VPN یک طرح داخلی پایدار برای منابع پشت آن میدهد. این پیشوند هیچ چیزی را رمزنگاری نمیکند، هیچ طرفی را احراز هویت نمیکند و تعیین نمیکند که یک کلاینت به کدام سرویسها دسترسی دارد. برخورد با پیشوند به عنوان یک کنترل امنیتی همان اشتباهی است که این مقاله برای رفع آن نوشته شده است.
پیشوند در واقع چه چیزی فراهم میکند
RFC 4193 محدوده fc00::/7 را برای استفاده محلی کنار میگذارد و بیت L فضای تخصیصیافته محلی را از قالب رزروشده جدا میکند. در عمل این یعنی آنچه تولید میکنید fd00::/8 است. مشخصات همچنین تعیین میکند که شناسه جهانی 40 بیتی چگونه استخراج شود تا سایتهای مستقل به طور تصادفی پیشوند یکسانی انتخاب نکنند. آن فضا طراحی شده است تا بیرون از اینترنت عمومی بماند، که ویژگی مسیریابی است و نه حفاظت.
درون یک سایت، چیدمان معمول یک شناسه جهانی /48 است که به زیرشبکهها تقسیم میشود: یکی برای کلاینتهای تونل، یکی برای سمت سرور و یکی برای هر LAN راه دور. همان ساختار تمام فایده است و این فایدهای در آدرسدهی است. هر بسته هنوز به یک مسیر نیاز دارد و هنوز به سیاستی نیاز دارد که آن را مجاز کند.
اشتباه گرفتن پیشوند با یک تونل همان راهی است که یک طرح در نهایت آدرسهای fd00 را مستند میکند و فرض میکند ترافیک میان آنها محافظتشده است. اینطور نیست، مگر اینکه چیز دیگری حفاظت را انجام دهد.
چرا کپی کردن پیشوند نمونه دردسر دارد
هر آموزشی از یک پیشوند بهیادماندنی استفاده میکند و هر خوانندهای که آن را کپی میکند همان خطر تداخل را به ارث میبرد. دو سایتی که بعداً از طریق یک تونل سایتبهسایت با محدودههای یکسان به هم متصل میشوند، دقیقاً همان ابهامی را ایجاد میکنند که از فضاهای خصوصی IPv4 همپوشان شناخته شده است. هیچ طرفی بهتنهایی اشتباه نیست و شبکه ترکیبی هیچ راهی برای دانستن مقصد مورد نظر ندارد.
تولید شناسه جهانی بر اساس فرآیند مستند یک دقیقه وقت میگیرد و سؤال را حذف میکند. پیشوند، ورودی تولید و تاریخ را ثبت کنید در کنار طرح آدرسها.
خطر برای کسی که شبکهها را پس از یک خرید ادغام میکند یا دو آزمایشگاه را از طریق VPN به هم وصل میکند، نظری نیست. برای یک سایت واحد هم فوری نیست، و به همین دلیل تا زمانی که ادغام از قبل برنامهریزی نشده باشد به تعویق میافتد.
دامنه و دسترسی دو پرسش جداگانهاند
ULA برای آدرسدهی معمول اینترنت با مسیریابی جهانی در نظر گرفته نشده است. این باعث نمیشود هر میزبان که از آن استفاده میکند مورد اعتماد باشد و آن میزبانها را از دیگر شبکههای خصوصی متصل غیرقابل دسترس نمیکند. دیوارهای آتش و مجوزهای برنامهها هنوز تعیین میکنند که یک طرف چه چیزی میتواند استفاده کند و تونل هنوز همان احراز هویتی را فراهم میکند که با آن پیکربندی شده است.
یک خروجی اینترنت به طرح خروج IPv6 خودش نیاز دارد. اختصاص یک آدرس ULA به یک کلاینت دسترسی به مقاصد جهانی دلبخواه ایجاد نمیکند و از کلاینتی که یکی دریافت میکند نباید انتظار داشت که از طریق آن در اینترنت عمومی مرور کند.
دو سایت با پیشوندهای متفاوت هنوز به مسیرهای بازگشت برای محدودههای یکدیگر نیاز دارند و هر دو دیوار آتش به قواعد همخوان نیاز دارند. هیچیک از اینها از خانواده آدرسها نتیجه نمیشود. آنچه نتیجه میشود کار مستندسازی است: جدولی از پیشوندها و سامانههایی که مجاز به پاسخ دادن روی هر یک هستند.
طرح را در هر دو سر بررسی کنید
تأیید کنید که پیشوند همانجایی ظاهر میشود که فکر میکنید، سپس تأیید کنید که یک مقصد واقعاً از طریق آن قابل دسترسی است.
ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1
فهرست آدرسها نشان میدهد کدام رابط کدام زیرشبکه را دارد و کلاینتی که اشتباه را دریافت کرده معمولاً آن را همینجا نشان میدهد. فهرست مسیرها نشان میدهد آیا پیشوند دور مسیری از طریق تونل دارد یا کنار گذاشته میشود. آزمون تنها پرسشی را پاسخ میدهد که اهمیت دارد: اینکه آیا بسته رفتوبرگشت را انجام میدهد.
پس از اتصال دوباره بررسی را تکرار کنید، زیرا کلاینتی که آدرسش را نگه میدارد اما مسیر را از دست میدهد اتصالی میسازد که بالا به نظر میرسد و چیزی ارسال نمیکند. آدرس بخش آسان است و مسیر همان چیزی است که ناپدید میشود. هر دو خروجی را کنار نام نمایه اتصال ذخیره کنید تا مقایسه بعدی از شواهد شروع شود.