خروجی اینترنت VPN مدیریت‌شده شما واقعاً از کجا بیرون می‌رود
«اینترنت شامل» هیچ نمی‌گوید که ترافیک عمومی از کجا خارج می‌شود، چه کسی آن را فیلتر می‌کند یا پس از یک خرابی چه چیزی باقی می‌ماند. مسیر را دنبال کنید و سپس هر دو حالت خرابی را بنویسید.
تا زمانی که پیشنهاد نشان ندهد آن ترافیک از کجای شبکهٔ ارائه‌دهنده خارج می‌شود، نمی‌توانید بگویید چه کسی ترافیک عمومی یک شعبه را فیلتر می‌کند. دسترسی اینترنتی که در یک VPN مدیریت‌شده گنجانده شده، سرویس دومی است که روی مسیری با دروازه‌های خودش، ترجمهٔ آدرس خودش و صف تشدید خودش حرکت می‌کند. بیشتر قراردادها سمت خصوصی را با جزئیات توصیف می‌کنند و سمت عمومی را به یک جمله می‌سپارند. بررسی‌های زیر آن جمله را به نموداری تبدیل می‌کند که می‌توانید از آن دفاع کنید.
برای هر سایت یک مقصد عمومی را دنبال کنید
یک میزبان در یک شعبه انتخاب کنید و یک مقصد عمومی را دنبال کنید و آخرین آدرسی که به ارائه‌دهنده تعلق دارد و اولین آدرسی که به اینترنت تعلق دارد را یادداشت کنید. پرش میان این دو آدرس همان خروجی است و اغلب هیچ‌جا نزدیک سایتی که بسته را فرستاده نیست. دستگاهی را که این گذار را انجام می‌دهد علامت بزنید، زیرا همان دستگاه فیلتری را دارد که تصمیم می‌گیرد چه چیزی بیرون برود. ردیابی را از سایت دومی تکرار کنید و آدرس‌های خروجی را مقایسه کنید، زیرا دو شعبه که روی فاکتور یکسان به نظر می‌رسند می‌توانند از دروازه‌های متفاوت در شهرهای متفاوت بیرون بروند.
آدرس مبدأیی را هم که مقصد واقعاً می‌بیند یادداشت کنید، زیرا ترجمه ممکن است در پرشی رخ دهد که هرگز رسمش نکرده‌اید. پاسخ‌های مشاهده‌شده را کنار پاسخ‌های ترسیم‌شده بنویسید، و فاصلهٔ میان آن دو همان جایی است که نخستین حادثه از آن می‌آید. مهندس ارائه‌دهنده‌ای که نمی‌تواند آدرس خروجی یک سایت مشخص را بدهد، پیشاپیش چیز مفیدی دربارهٔ طراحی به شما گفته است.
سه چیدمان خروجی و آنچه هر یک تمرکز می‌دهد
خروجی مرکزی که خودتان اداره می‌کنید ترافیک عمومی را به دروازه‌ای از خودتان می‌کشد، که سیاست فیلتر و گزارش‌ها را به شما می‌دهد اما بار همهٔ سایت‌ها را روی یک مدار متمرکز می‌کند. خروجی تحت ادارهٔ ارائه‌دهنده سیاست و گزارش‌ها را به آن سوی مرز قرارداد منتقل می‌کند، که عملیات را ساده می‌کند و در همان حرکت دید شما را می‌گیرد. خروجی در هر سایت ترافیک عمومی را محلی نگه می‌دارد و شمار سطوح سیاستی را که باید یکسان بمانند چند برابر می‌کند.
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
پیش از آنکه فهرست را منو فرض کنید بپرسید ارائه‌دهنده واقعاً کدام یک از این سه را عرضه می‌کند، و بپرسید آیا یک سایت می‌تواند بدون مدار جدید میان آن‌ها جابه‌جا شود. پاسخ مهاجرت، آنچه قراردادی است را از آنچه صرفاً فنی است جدا می‌کند. همچنین ثبت کنید که ترجمهٔ مبدأ از آنِ کیست، زیرا همان تعیین می‌کند شریک چه چیزی را باید در فهرست مجاز بگذارد. دروازه‌های مشترک به معنای ظرفیت مشترک و گاهی اعتبار مشترک هم هست، که رفتار شرکا با آدرس‌های شما را تغییر می‌دهد. ظرفیت هم پرسش خودش را می‌طلبد، زیرا یک دروازهٔ مشترک در همان لحظه به مشتریان دیگری خدمت می‌دهد.
فیلتر، ترجمه و رمزنگاری صاحبان جداگانه دارند
مسیر دسترسی‌پذیری می‌سازد و دربارهٔ بازرسی چیزی نمی‌گوید، پس این دو را دو پرسش متفاوت با دو صاحب متفاوت بدانید. برای هر مسیر پیش‌فرض اعلام‌شده، دستگاهی را که فیلتر می‌کند، دستگاهی را که احراز هویت می‌کند، دستگاهی را که ترجمه می‌کند و دستگاهی را که بازرسی می‌کند نام ببرید، سپس بگویید هر یک را چه کسی اداره می‌کند. جداسازی مسیر در ارائه‌دهنده نمی‌گوید رمزنگاری کجا پایان می‌یابد، و یک سرویس خصوصی می‌تواند تونلش را در یک مرز تمام کند در حالی که خروجی عمومی در مرز دیگری تمام می‌شود. بپرسید آیا ترجمه در لبهٔ ارائه‌دهنده رخ می‌دهد، در یک دروازهٔ مشترک یا در خروجی خودتان، و آیا گزارش‌های نشست وجود دارد و تا چه مدت. صاحبان را در پاسخ‌ها بشمارید، زیرا قراردادی که یک طرف را برای چهار کار نام می‌برد معمولاً سه‌تای آن‌ها را مستندنشده می‌گذارد.
یک مسیر پیش‌فرض گسترده واردشده به زمینهٔ مسیریابی خصوصی همان بررسی را می‌طلبد، زیرا واردسازی یک توافق آگاهانه است و نه یک راحتی بی‌خطر. بخش 11 از RFC 4364 چند چیدمان دسترسی اینترنت برای VPNهای BGP/MPLS را مرور می‌کند و تبادل مسیر میان زمینهٔ VPN و زمینهٔ ارسال پیش‌فرض ارائه‌دهنده را دقیقاً همان نوع توافق می‌داند. بپرسید چه چیزی مانع می‌شود ترافیک عمومی به‌طور تصادفی مسیر خصوصی بگیرد، و پاسخ را کنار سیاست مسیر بخواهید نه در یک اسلاید.
دو حالت خرابی که پیش از امضا باید توافق شود
دو آزمون را در قرارداد بنویسید: از دست دادن خروجی اینترنت، و از دست دادن یک اتصال خصوصی. برای هر یک، منابع داخلی، سرویس‌های اینترنت محلی و مسیرهای مدیریتی را که باید کار کنند فهرست کنید. سپس مسیر جایگزینی را فهرست کنید که باید مسدود بماند، زیرا مسیری دور زدن کنترل‌های مرکزی بدتر از یک قطعی تمیز است. هر دو آزمون را به ارائه‌دهنده بدهید و نتیجهٔ مورد انتظارشان را کتبی بخواهید، همراه با تشخیص و اطلاع‌رسانی.
همان آزمون‌ها را از یک سایت آزمایشی اجرا کنید و با آن پاسخ کتبی مقایسه کنید. هر جا این دو با هم نمی‌خوانند، قرارداد شبکه‌ای متفاوت از آنچه خریده‌اید را توصیف می‌کند. دو فرمان موارد رایج را پوشش می‌دهند: یکی مسیری را که یک مقصد عمومی می‌پیماید نشان می‌دهد، دیگری آدرسی را که می‌بیند.
traceroute -n 203.0.113.10
curl -s https://example.net/ipتعهدهای دسترس‌پذیری را به همان بخشی که اندازه گرفتید ببندید، نه به نام سرویس. یک مدار محلی، ستون فقرات ارائه‌دهنده و یک دروازهٔ مشترک، تعهدها و تیم‌های تشدید جداگانه دارند. حروف L2VPN و L3VPN و MPLS یک سازوکار ارسال را توصیف می‌کنند، نه تضمینی سرتاسری.
شواهد بر صفت‌های پیشنهاد پیروز می‌شود
واژه‌هایی مانند افزونه، امن و تاب‌آور نیتی را توصیف می‌کنند نه طراحی‌ای. به‌جای آن، فهرست دستگاه‌ها، مکان‌های خروجی، طرح ترجمه و مسیر اطلاع‌رسانی را بخواهید. ارائه‌دهنده‌ای که می‌تواند آن چهار قلم را تحویل دهد طراحی دارد؛ آنکه نمی‌تواند، یک اسلاید دارد. پاسخ‌ها را در مستندات سرویس نگه دارید نه در رشتهٔ ایمیل، و در هر تغییر قرارداد دوباره سراغشان بروید.
چیدمان‌های خروجی در سکوت جابه‌جا می‌شوند، چون ارائه‌دهندگان دروازه‌ها را ادغام می‌کنند، پس نموداری از سه سال پیش یک بار است. وقتی شریکی آدرس مبدأ ناآشنایی را گزارش می‌کند، باید ظرف چند دقیقه بتوانید بگویید از طراحی شما آمده یا از تغییری که کسی اعلامش نکرده است. همین توانایی، نه صفت‌ها، چیزی است که از نخستین قطعی جان سالم به در می‌برد.