VPN üçün icarə xətti? Əvvəlcə tələbi tərcümə edin

Təklif ofis VPN-i üçün konkret icarə xəttini adlandırır və rəqəm heç bir izahat olmadan gəlir. İmzalamazdan əvvəl cümləni əslində gizlətdiyi dörd tələbə bölün: fiziki qəbul, IP çatdırılma qaydası, hər iki istiqamətdə tutum və xəttin arxasındakı dəstək öhdəliyi. Onları bu sıra ilə qapı kimi işə salın, çünki qəbuldan keçməyən xətti daha böyük bant genişliyi rəqəmi xilas edə bilməz. Sonra çatdırılanı yazdıqlarınızla yoxlayın.

Məhsulun adını deyil, tələbi tərcümə edin

IPsec trafiki IP qatında qoruyur və daşımanı aldığınız xəttə buraxır. IPsec arxitekturası trafikin həmyaşıdlar arasında necə qorunduğunu təsvir edir; qəbul növü, öhdəlik dərəcələri və təmir pəncərələri barədə heç nə demir. Bunlar xidmət müqaviləsinin xassələridir.

Bu fərq xətt tələbinin qanuni olub yenə də VPN tələbi olmamasının bütün səbəbidir. Yalnız seriyalı interfeysi olan şlüz həqiqətən seriyalı qəbula ehtiyac duyur və bu, protokol deyil, aparat məhdudiyyətidir. Cihazı dəyişin və məhdudiyyət yox olur. Hər tələbi "şlüz X-ə ehtiyac duyur, çünki Y" formasında yazın və tamamlana bilməyən hər sətri rədd edin.

Sürəti adlandırmazdan əvvəl qəbulu adlandırın

Qəbul sərhəd nöqtəsindəki fiziki və kanal qatı əlaqəsidir: mis Ethernet, konkret ötürücü ilə lif, seriyalı interfeys və ya yalnız mövcud cihazda olduğu üçün var olan daha köhnə bir şey. Bunu səhv etmək bant genişliyinin heç vaxt olmadığı qədər baha başa gəlir, çünki adətən hər iki uçda yeni aparat deməkdir. Çatışmayan optika tutum problemi deyil və heç bir yüksəltmə onu düzəltmir.

Konnektoru, sürət razılaşmasını və media çeviricisini və ya marşrutlaşdırıcını kimin təmin etdiyini təsdiqləyin. Sonra məsuliyyətinizin harada bitdiyini təsdiqləyin, çünki sərhəd nöqtəsi 03:00-da xətt düşəndə kimin nəyə toxuna biləcəyini müəyyən edir. Bu sərhədi xətt identifikatorunun yanında qeydə yazın. Bu, dəstək zəngini bir saatlıq ötürmə əvəzinə beş dəqiqəlik söhbətə çevirən yeganə sətirdir.

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

Yalnız ünvanı deyil, IP çatdırılmasını təsdiqləyin

Xidmətin əslində hansı ünvanı və ya prefiksi çatdırdığını və statik olub-olmadığını soruşun. Dinamik ünvan paylayan xətt sayt-sayt şlüzünə uyğun deyil, çünki həmyaşıd konfiqurasiyası planlaşdırmadığınız dəyişikliyə dözməlidir. Prefiks uzunluğunu da təsdiqləyin, çünki bir ünvan və marşrutlaşdırılmış /29 fərqli məhsullardır.

Sonra soruşun: ünvan sizə çatmazdan əvvəl onu nəsə tərcümə edirmi. Provayder tərəfindəki NAT və ya xidmətin qarşısındakı daşıyıcı səviyyəli NAT daxil olan sessiyaları pozur, ona görə uzaq saytlardan IPsec qəbul etməyi gözləyən şlüzə çatmaq mümkün olmur. Sürət bunu kompensasiya etmir: idarə etmədiyiniz tərcüməçinin arxasındakı sürətli xətt yenə də heç kimin yönləndirmədiyi portda daxil olan bağlantını qəbul edə bilməz.

Marşrutlaşdırıcının və DNS-in kimə aid olduğunu qeyd edin. Provayder marşrutlaşdırıcını təmin edirsə, onun proqram təminatını, NAT davranışını və standart marşrut anlayışını miras alırsınız və hər sonrakı dəyişiklik biletdən keçir. Şəbəkənizdən kənarda birinə əlçatan olmasını gözlədiyiniz porta daxil olan bağlantı cəhd etdirin, çünki tərcümə hekayəsini sübut edən yeganə test budur.

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

Tutumun ölçüsünü iş yükündən götürün, hər iki istiqamətdə

Tutum işin həcmi ilə, istifadəçi başına rəqəmlə deyil, təsvir olunmalıdır. Kütləvi fayl girişi, interaktiv idarəetmə və gecə yedəkləməsi hər biri fərqli trafik nümunəsi yaradır və onlardan yalnız biri davamlı yuxarı axın sürətinə əhəmiyyət verir. Oturacaq başına bant genişliyi rəqəmi satış rahatlığıdır, model deyil.

Hər iki istiqaməti təxmin edin, inkapsulyasiya yükünü əlavə edin və trafikin partlayışlı yoxsa davamlı olduğunu qeyd edin. Sonra müqavilənin başlıq dərəcəsini deyil, öhdəlik dərəcəsini yoxlayın, çünki bir neçə saniyədən sonra bitən partlayış icazəsi gecə yedəkləməsinə kömək etmir. Şlüzün öz hədlərini də eyni büdcədə saxlayın, çünki şifrələmə emalı və eyni vaxtlı sessiya sayı xəttdən çox əvvəl darboğaz yarada bilər. Daha sürətli xətt doymuş şlüzü düzəltməyəcək.

Əməliyyat öhdəliklərini dəqiqləşdirin

Əlçatanlıq, təmir cavabı, eskalasiya yolu və texniki xidmət bildirişi ölçmə üsulu göstərilməklə yazılı olmalıdır. Başlıq internet dərəcəsi bu xassələrin heç birini müəyyən etmir, kəsintini təyin etmədən etibarlılıq vəd edən marketinq səhifəsi də etmir. Saatın necə başladığını soruşun, çünki provayderin öz təsdiqindən ölçülən cavab vaxtı monitorinq siqnalınızdan ölçülən rəqəmlə eyni deyil. Bu iki tərif heç kim yalan danışmadan saatlarla fərqlənə bilər.

Dəstək sərhədini də qeyd edin. Provayderin məsuliyyəti sizin marşrutlaşdırıcınızın sonlandırdığı qəbulda bitirsə, hər hadisənin ilk saatı nasazlığın kimə aid olduğunu müəyyən etməyə gedir və heç bir SLA saatı bunu əhatə etmir.

Xətti yazılı şərtlərlə yoxlayın

Xidmət işə düşdükdən sonra quraşdırıcının nümayiş etdirdiyini deyil, həqiqətən müqavilə bağladığınız xassələri ölçün. Real yolda ötürmə qabiliyyəti, gecikmə və itki dəlildir və onlar adını çəkə biləcəyiniz vaxtda və yerdə qeydə alınmalıdır. Ölçməni yalnız təhvil zamanı deyil, sıx saatda təkrarlayın. Sakit gündə 10:00-da keçirilən qəbul testi sizə 15:00-dakı xətt barədə çox az şey deyir.

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/

Nəticələri müqavilə ilə birlikdə saxlayın, çünki baza xətti olmayan performans müzakirəsi təəssüratlar barədə mübahisədir. Ölçmə öhdəliyi tutmursa, dəlil təzə ikən və xidmət hələ müqavilənin verdiyi qəbul pəncərəsi içindəkən bunu qaldırın. Sorğuda adlandırılmış host TLS əl sıxışmasını da etibarlı saxlayır, beləliklə sertifikat xəbərdarlığı uğursuz xətt kimi qəbul edilmir.

Nəhayət, dörd qapını çatdırılanlarla yenidən oxuyun. Qəbul, IP çatdırılması, tutum və dəstək şərtlərinin hər birinin qeyddə bir sətri var və hər sətrin yanında bir ad var.