خط اجارهای برای VPN؟ نخست نیازمندی را ترجمه کنید

پیشنهاد یک خط اجارهای مشخص برای VPN دفتر را نام میبرد و عدد بدون هیچ توضیحی میرسد. پیش از امضا، جمله را به چهار نیازمندی که در واقع پنهان میکند بشکنید: تحویل فیزیکی، ترتیب تحویل نشانی IP، ظرفیت در هر دو جهت، و تعهد پشتیبانی پشت مدار. آنها را به همین ترتیب بهعنوان دروازه اجرا کنید، چون مداری که در تحویل شکست میخورد با عدد پهنای باند بزرگتر نجات نمییابد. سپس آنچه تحویل داده شده را با آنچه نوشتهاید بسنجید.

نیازمندی را ترجمه کنید، نه نام محصول را

IPsec ترافیک را در لایه IP محافظت میکند و حمل را به هر مداری که میخرید واگذار میکند. معماری IPsec توصیف میکند ترافیک میان همتاها چگونه محافظت میشود؛ درباره نوع تحویل، نرخ تعهد یا پنجره تعمیر چیزی نمیگوید. اینها ویژگیهای یک قرارداد خدماتاند.

این تفاوت تمام دلیل آن است که یک نیازمندی مدار میتواند مشروع باشد و در همان حال نیازمندی VPN نباشد. دروازهای که تنها یک رابط سریال دارد واقعاً به تحویل سریال نیاز دارد، و این محدودیت سختافزاری است نه محدودیت پروتکل. دستگاه را عوض کنید و محدودیت ناپدید میشود. هر نیازمندی را به شکل «دروازه به X نیاز دارد چون Y» بنویسید و هر خطی را که کامل نمیشود رد کنید.

پیش از نام بردن سرعت، تحویل را نام ببرید

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

رابط، مذاکره سرعت و اینکه چه کسی مبدل رسانه یا مسیریاب را تأمین میکند را تأیید کنید. سپس تأیید کنید مسئولیت شما کجا پایان مییابد، چون نقطه مرز تعیین میکند وقتی خط ساعت 03:00 قطع میشود چه کسی اجازه دارد به چه چیزی دست بزند. آن مرز را در سند کنار شناسه مدار بنویسید. همان یک خط است که یک تماس پشتیبانی را به گفتوگویی پنجدقیقهای تبدیل میکند، نه یک ساعت ارجاع.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

تحویل IP را تأیید کنید، نه فقط نشانی را

بپرسید سرویس واقعاً چه نشانی یا پیشوندی تحویل میدهد و آیا ایستا است. مداری که نشانی پویا میدهد برای دروازه سایتبهسایت مناسب نیست، چون پیکربندی همتا باید از تغییری که شما برنامهریزی نکردهاید جان سالم به در ببرد. طول پیشوند را هم تأیید کنید، چون یک نشانی و یک /29 مسیریابیشده دو محصول متفاوتاند.

سپس بپرسید آیا چیزی نشانی را پیش از رسیدن به شما ترجمه میکند. NAT سمت ارائهدهنده یا NAT درجه اپراتور در جلوی سرویس، نشستهای ورودی را میشکند، پس دروازهای که انتظار دارد IPsec را از سایتهای دور بپذیرد قابل دسترسی نیست. سرعت این را جبران نمیکند: یک خط سریع پشت مترجمی که کنترلش نمیکنید هنوز نمیتواند اتصال ورودی روی پورتی را بپذیرد که کسی آن را هدایت نمیکند.

ثبت کنید مسیریاب و DNS مالک کیست. اگر ارائهدهنده مسیریاب را تأمین میکند، شما میانافزار، رفتار NAT و تصورش از مسیر پیشفرض را به ارث میبرید و هر تغییر بعدی از طریق تیکت میرود. بگذارید کسی بیرون از شبکه شما اتصال ورودی به پورتی را که انتظار دارید در دسترس باشد امتحان کند، چون تنها آزمونی است که داستان ترجمه را اثبات میکند.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

ظرفیت را از بار کاری، در هر دو جهت، اندازه بگیرید

ظرفیت باید بر حسب کار توصیف شود، نه بر حسب یک عدد برای هر کاربر. دسترسی انبوه به فایل، مدیریت تعاملی و پشتیبانگیری شبانه هر یک الگوی ترافیکی متفاوتی تولید میکنند و تنها یکی از آنها به توان عبوری پیوسته در جهت بالا اهمیت میدهد. عدد پهنای باند به ازای هر کاربر یک آسایش فروش است، نه یک مدل.

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

تعهدهای عملیاتی را تثبیت کنید

دسترسپذیری، پاسخ تعمیر، مسیر تشدید و اطلاع تعمیرات باید کتبی باشند و روش اندازهگیری نام برده شود. نرخ سرصفحه اینترنت هیچیک از این ویژگیها را تثبیت نمیکند و صفحهای بازاریابی هم که قابلیت اطمینان را بدون تعریف قطعی وعده میدهد چنین نمیکند. بپرسید ساعت از کجا شروع میشود، چون زمان پاسخ اندازهگیریشده از تأیید خود ارائهدهنده با عددی که از هشدار پایش شما اندازهگیری میشود یکی نیست. این دو تعریف میتوانند ساعتها تفاوت داشته باشند بدون آنکه کسی دروغ بگوید.

مرز پشتیبانی را هم ثبت کنید. اگر مسئولیت ارائهدهنده در تحویلی پایان مییابد که مسیریاب خود شما آن را خاتمه میدهد، نخستین ساعت هر رخداد صرف تصمیمگیری درباره مالک خرابی میشود و هیچ ساعت SLA آن را پوشش نمیدهد.

مدار را در برابر شرایط مکتوب بررسی کنید

وقتی سرویس فعال شد، ویژگیهایی را که واقعاً برایشان قرارداد بستهاید اندازه بگیرید، نه آنهایی که نصبکننده نشان داد. توان عبوری، تأخیر و افت در مسیر واقعی شواهد هستند و باید در زمانی و از مکانی که میتوانید نام ببرید ثبت شوند. اندازهگیری را در ساعت پرترافیک تکرار کنید، نه فقط هنگام تحویل. آزمون پذیرشی که ساعت 10:00 در روزی خلوت اجرا شود درباره خط در ساعت 15:00 بسیار کم میگوید.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

نتایج را با قرارداد نگه دارید، چون بحث درباره کارایی بدون خط پایه جدالی درباره برداشتها است. اگر اندازهگیری از تعهد عقب بماند، آن را وقتی شواهد تازه است و سرویس هنوز در هر پنجره پذیرشی که قرارداد میدهد قرار دارد مطرح کنید. نام بردن میزبان در درخواست همچنین دستدادن TLS را معتبر نگه میدارد، تا هشدار گواهی بهاشتباه مدار خراب تلقی نشود.

سرانجام، آن چهار دروازه را دوباره در برابر آنچه تحویل شد بخوانید. تحویل، تحویل نشانی IP، ظرفیت و شرایط پشتیبانی هر یک خطی در سند دارند و کنار هر خط نامی نوشته شده است.