مدیریت خودکار تلفن‌های یالینک؛ راه‌اندازی امن Provisioning برای ده‌ها دستگاه با HTTPS

Yealink Auto Provisioning این فرایند را متمرکز می‌کند. تلفن هنگام روشن‌شدن یا در زمان تعیین‌شده به یک Provisioning Server متصل می‌شود، فایل تنظیمات مربوط به مدل و MAC خودش را دریافت می‌کند و تنظیمات جدید را اعمال می‌کند. به این ترتیب می‌توان تنظیمات مشترک ده‌ها تلفن را از یک محل کنترل کرد و در عین حال اطلاعات اختصاصی هر داخلی را در فایل جداگانه نگه داشت.

در این آموزش یک ساختار عملی و امن برای Auto Provisioning می‌سازیم: فایل Common و MAC-Oriented را از هم جدا می‌کنیم، یک Provisioning Server روی HTTPS راه می‌اندازیم، برای دسترسی Username و Password می‌گذاریم، اطلاعات SIP را از فایل عمومی جدا می‌کنیم، رمزگذاری CFG را بررسی می‌کنیم، زمان Provisioning را کنترل می‌کنیم و در نهایت یک روش Rollback طراحی می‌کنیم تا یک فایل اشتباه باعث از کار افتادن تمام تلفن‌ها نشود.

Yealink Auto Provisioning دقیقاً چیست؟

Auto Provisioning یعنی تلفن تنظیماتش را از یک Server دریافت کند، نه اینکه Administrator همه گزینه‌ها را دستی در رابط وب یا صفحه تلفن وارد کند.

مدل ساده به این شکل است:

Yealink Phone
      ↓
Provisioning Server URL
      ↓
HTTPS
      ↓
Common CFG
      +
MAC-Oriented CFG
      ↓
Apply Configuration
      ↓
SIP Registration

برای مثال می‌توانید تنظیمات عمومی مانند زمان‌بندی Provisioning را برای همه تلفن‌های یک مدل در Common CFG قرار دهید، اما Username و Password داخلی ۲۰۱ را فقط در فایل مربوط به MAC همان تلفن بنویسید.

چرا برای چند ده تلفن تنظیم دستی انتخاب خوبی نیست؟

فرض کنید ۴۰ تلفن دارید و SIP Server از:

pbx-old.example.com

به:

sip.example.com

منتقل شده است.

در روش دستی باید ۴۰ تلفن را جداگانه تغییر دهید.

در Auto Provisioning می‌توانید فایل‌های Configuration را اصلاح کنید و تلفن‌ها در چرخه بعدی Provisioning تنظیم جدید را دریافت کنند.

همین روش برای تغییراتی مانند NTP، Dial Plan، Account، Transport، تنظیمات امنیتی و بسیاری از پارامترهای مدیریتی نیز قابل استفاده است.

معماری پیشنهادی برای ۳۰ تا ۵۰ تلفن

Common CFG و MAC CFG چه تفاوتی دارند؟

این تفاوت پایه اصلی طراحی درست Provisioning است.

Common CFG

Common CFG برای تلفن‌های یک مدل استفاده می‌شود.

نام این فایل به مدل دستگاه وابسته است و Yealink برای هر مدل نام مشخصی تعیین می‌کند.

برای نمونه در مستندات فعلی:

T54W:
y000000000096.cfg

اما برای مدل دیگری مانند T46U فایل متفاوت است.

بنابراین فایل Common را از روی مدل حدس نزنید؛ نام فایل را از Administrator Guide یا Provisioning Guide همان مدل بردارید.

MAC-Oriented CFG

این فایل فقط روی یک دستگاه اثر می‌گذارد و نام آن از MAC Address تلفن ساخته می‌شود.

اگر MAC دستگاه:

00:15:65:74:B1:50

باشد، فایل باید به‌صورت ۱۲ کاراکتر بدون جداکننده و با حروف کوچک ساخته شود:

00156574b150.cfg

Yealink در مستندات جدید خود تأکید می‌کند نام MAC-Oriented CFG باید با MAC تلفن منطبق باشد.

چه چیزی را در Common و چه چیزی را در MAC قرار دهیم؟

یک قاعده ساده داشته باشید:

اگر مقدار برای همه تلفن‌های یک مدل یکسان است، Common مناسب‌تر است.

اگر مقدار فقط متعلق به یک کاربر یا یک تلفن است، MAC CFG انتخاب بهتری است.

بنابراین Password حساب SIP را داخل Common CFG قرار ندهید.

اگر ۴۰ تلفن دارید و فایل عمومی لو برود، نباید Credentials تمام داخلی‌ها همراه آن افشا شوند.

ساختار پیشنهادی دایرکتوری

برای یک مجموعه متوسط می‌توانید ساختار را ساده نگه دارید:

/srv/yealink-provision/
│
├── y000000000096.cfg
├── y000000000108.cfg
│
├── 00156574b150.cfg
├── 00156574b151.cfg
├── 00156574b152.cfg
│
├── account.cfg
├── dialplan.cfg
│
└── archive/
    ├── 2026-10-01/
    └── 2026-10-10/

در این مثال دو مدل مختلف Common CFG جدا دارند و هر تلفن فایل MAC اختصاصی خودش را دارد.

خط اول فایل CFG را فراموش نکنید

فایل‌های Yealink CFG با Header استاندارد شروع می‌شوند:

#!version:1.0.0.1

برای مثال:

#!version:1.0.0.1

static.auto_provision.power_on = 1
static.auto_provision.repeat.enable = 1
static.auto_provision.repeat.minutes = 1440

در این نمونه تلفن هنگام روشن‌شدن Provisioning را اجرا می‌کند و در صورت فعال‌بودن Repeated Provisioning هر ۱۴۴۰ دقیقه دوباره وضعیت Configuration را بررسی می‌کند.

نمونه فایل MAC برای یک داخلی SIP

فرض کنید MAC تلفن:

00156574b150

و داخلی:

201

است.

فایل:

00156574b150.cfg

می‌تواند ساختاری مانند این داشته باشد:

#!version:1.0.0.1

account.1.enable = 1
account.1.label = 201
account.1.display_name = User-201
account.1.auth_name = 201
account.1.user_name = 201
account.1.password = CHANGE_THIS_PASSWORD

account.1.sip_server.1.address = sip.example.com
account.1.sip_server.1.port = 5061
account.1.sip_server.1.transport_type = 2

در پارامتر Transport، مقدار دقیق را باید با مدل و Firmware خود تطبیق دهید. در مستندات مدل‌های فعلی Yealink مقدار ۰ برای UDP، مقدار ۱ برای TCP و مقدار ۲ برای TLS استفاده می‌شود.

Password واقعی را در نمونه‌ها و Git قرار ندهید

یکی از خطرناک‌ترین اشتباه‌ها این است که Directory مربوط به Provisioning را وارد یک Repository عمومی کنید.

فایل MAC می‌تواند شامل:

account.1.auth_name
account.1.user_name
account.1.password

باشد.

بنابراین Repository، Backup و Access Logهای Provisioning Server باید مانند اطلاعات حساس مدیریت شوند.

سرور Provisioning را با HTTPS بسازید

Yealink از چند روش Provisioning پشتیبانی می‌کند، اما برای Server اینترنتی یا شبکه‌ای که اطلاعات SIP حساس از آن عبور می‌کند، HTTPS انتخاب منطقی‌تری نسبت به HTTP یا TFTP است.

برای نمونه یک سرور Ubuntu را در نظر می‌گیریم.

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

راه‌اندازی Provisioning Server روی Ubuntu

ابتدا Nginx و ابزارهای موردنیاز را نصب کنید:

sudo apt update

sudo apt install nginx apache2-utils certbot python3-certbot-nginx -y

پوشه Provisioning را بسازید:

sudo mkdir -p /srv/yealink-provision

Owner را روی کاربری قرار دهید که فایل‌ها را مدیریت می‌کند. در این مثال:

sudo chown -R root:www-data /srv/yealink-provision

Permission پیشنهادی برای شروع:

sudo find /srv/yealink-provision -type d -exec chmod 750 {} \;

sudo find /srv/yealink-provision -type f -exec chmod 640 {} \;

Nginx باید بتواند فایل‌ها را بخواند، اما Client نباید امکان نوشتن روی Server داشته باشد.

یک Domain مخصوص Provisioning بسازید

مثلاً:

provision.example.com

رکورد DNS آن را به IP سرور متصل کنید.

بعد از Resolve شدن Domain:

nslookup provision.example.com

یا در Linux:

dig A provision.example.com +short

را اجرا کنید.

کانفیگ ساده Nginx

یک Virtual Host بسازید:

sudo nano /etc/nginx/sites-available/yealink-provision

نمونه اولیه:

server {
    listen 80;
    server_name provision.example.com;

    root /srv/yealink-provision;

    location / {
        autoindex off;
        try_files $uri =404;
    }
}

آن را فعال کنید:

sudo ln -s /etc/nginx/sites-available/yealink-provision \
/etc/nginx/sites-enabled/yealink-provision

sudo nginx -t

sudo systemctl reload nginx

قبل از ادامه یک فایل آزمایشی بسازید

echo "provision-ok" | sudo tee /srv/yealink-provision/test.txt

سپس:

curl http://provision.example.com/test.txt

باید:

provision-ok

دریافت کنید.

اگر 404 می‌گیرید، مسیر فایل و Nginx Root را بررسی کنید.

HTTPS را فعال کنید

بعد از اطمینان از DNS و HTTP:

sudo certbot --nginx -d provision.example.com

سپس تست کنید:

curl -I https://provision.example.com/test.txt

اگر HTTPS سالم باشد باید یک پاسخ موفق HTTP دریافت کنید.

Certificate سمت Yealink هم مهم است

HTTPS زمانی امن است که تلفن Certificate سرور را نیز اعتبارسنجی کند.

اگر از CA خصوصی استفاده می‌کنید، ممکن است لازم باشد Root یا Intermediate CA را داخل:

Security → Trusted Certificates

تلفن وارد کنید.

خاموش‌کردن گزینه Only Accept Trusted Certificates می‌تواند برای تشخیص موقت مفید باشد، اما برای محیط عملیاتی بهتر است Trust Chain را درست کنید و Verification را فعال نگه دارید.

روی Provisioning Server احراز هویت قرار دهید

فقط HTTPS کافی نیست. اگر URL فایل‌ها برای همه قابل دسترسی باشد، کسی که MAC یک دستگاه را بداند ممکن است بتواند فایل آن را درخواست کند.

برای Nginx می‌توانید Basic Authentication ایجاد کنید:

sudo htpasswd -c /etc/nginx/.yealink_htpasswd yealink_ro

یک Password طولانی و تصادفی تعیین کنید.

سپس Location را تغییر دهید:

location / {
    auth_basic "Yealink Provisioning";
    auth_basic_user_file /etc/nginx/.yealink_htpasswd;

    autoindex off;
    try_files $uri =404;

    limit_except GET HEAD {
        deny all;
    }
}

Configuration را تست کنید:

sudo nginx -t

sudo systemctl reload nginx

دسترسی را با curl آزمایش کنید

بدون Credentials:

curl -I https://provision.example.com/test.txt

باید با Authentication Challenge روبه‌رو شوید.

با Credentials:

curl -u yealink_ro:'PASSWORD' \
https://provision.example.com/test.txt

باید فایل دریافت شود.

Username و Password را داخل URL نگذاریم؟

Yealink از URLهایی مانند:

https://user:password@server/path/

پشتیبانی می‌کند، اما برای محیط واقعی بهتر است تا حد امکان Credentials را در خود URL قرار ندهید؛ چون URL ممکن است در Log، Screenshot یا ابزارهای مدیریتی نمایش داده شود.

Yealink برای Provisioning Server فیلدهای جداگانه دارد:

Server URL
User Name
Password

و پارامترهای متناظر عبارت‌اند از:

static.auto_provision.server.url
static.auto_provision.server.username
static.auto_provision.server.password

آدرس Provisioning Server را روی یک تلفن آزمایشی وارد کنید

در رابط وب تلفن:

Settings → Auto Provision

مقادیر را وارد کنید:

Server URL:
https://provision.example.com/

User Name:
yealink_ro

Password:
********

ابتدا فقط یک تلفن آزمایشی را Provision کنید.

نباید از روز اول تمام ۴۰ تلفن را به Server جدید وصل کنید.

روش‌های خودکار کشف Provisioning Server

برای چند تلفن می‌توانید URL را دستی وارد کنید، اما برای ده‌ها دستگاه بهتر است تلفن بتواند Server را خودکار پیدا کند.

Yealink می‌تواند Provisioning Server Address را از DHCP دریافت کند.

در مستندات فعلی، ترتیب اولویت معمول برای کشف Server چنین است:

Custom DHCP Option
↓
Option 66
↓
Option 43

DHCP Option 66 در بسیاری از شبکه‌ها برای معرفی Server Provisioning استفاده می‌شود.

مزیت DHCP Option چیست؟

فرض کنید ۵۰ تلفن Factory Reset شده‌اند.

اگر DHCP Option درست باشد، تلفن بعد از گرفتن IP می‌تواند Provisioning Server Address را نیز دریافت کند و بدون ورود دستی به رابط وب، فرایند Provisioning را شروع کند.

اما DHCP Option را ابتدا در VLAN آزمایشی تست کنید؛ یک URL اشتباه می‌تواند تمام Endpointهای همان Scope را به Server اشتباه بفرستد.

فایل Common برای چند مدل یکی نیست

این اشتباه در Deploymentهای واقعی زیاد رخ می‌دهد.

اگر سازمان شما T54W، T46U و T31G دارد، نمی‌توانید یک فایل Common با نام واحد را برای همه مدل‌ها فرض کنید.

هر مدل Common CFG مخصوص خودش را درخواست می‌کند.

برای مثال مستندات Yealink نام‌های متفاوتی مانند:

T54W:
y000000000096.cfg

T46U:
y000000000108.cfg

T31/T31P/T31G:
y000000000123.cfg

را مشخص می‌کنند.

همیشه جدول مدل‌های همان نسخه مستندات Yealink را بررسی کنید.

Boot File چه زمانی مفید است؟

Yealink از Common Boot File با نام:

y000000000000.boot

و MAC-Oriented Boot File مانند:

00156574b150.boot

پشتیبانی می‌کند.

Boot File زمانی مفید است که بخواهید Configuration را به چند فایل موضوعی تقسیم کنید.

مثلاً:

#!version:1.0.0.1

include:config <account.cfg>
include:config <dialplan.cfg>
include:config <features.cfg>

این ساختار در Deployment بزرگ‌تر خواناتر از یک فایل چند هزار خطی است.

در استفاده از Common و MAC Boot دقت کنید

Yealink در مستندات عیب‌یابی هشدار می‌دهد اگر MAC-Oriented Boot و Common Boot هم‌زمان موجود باشند، رفتار Download بر اساس MAC-Oriented Boot می‌تواند اولویت پیدا کند.

بنابراین قبل از ورود به معماری Boot File، ساختار را روی یک تلفن آزمایشی کامل تست کنید.

چرا باید فایل Account را رمزگذاری کنیم؟

HTTPS اطلاعات را هنگام انتقال رمزگذاری می‌کند، اما فایل CFG همچنان روی Disk سرور وجود دارد.

اگر:

account.1.password = SecretPassword

به‌صورت Plaintext ذخیره شده باشد، دسترسی غیرمجاز به Directory یا Backup Server می‌تواند Credentials را افشا کند.

Yealink برای این موضوع Configuration File Encryption دارد.

Yealink چه فایل‌هایی را می‌تواند رمزگذاری کند؟

طبق مستندات رسمی، از جمله:

MAC-Oriented CFG
Common CFG
MAC-local CFG
Custom CFG

قابل رمزگذاری هستند.

بنابراین فایل‌هایی مانند:

account.cfg
sip.cfg
00156574b150.cfg

را می‌توان با ابزار رسمی Yealink رمزگذاری کرد.

ابزارهای Encryption رسمی Yealink

Yealink ابزارهای زیر را معرفی می‌کند:

Config_Encrypt_Tool.exe
Config_Encrypt.exe
yealinkencrypt

دو مورد اول برای Windows و ابزار yealinkencrypt برای Linux ارائه شده است.

در بعضی خانواده‌های فعلی، Yealink از AES Key با طول ۱۶ کاراکتر برای مدل Encryption مربوطه استفاده می‌کند.

اما الگوریتم و پارامترهای دقیق Encryption می‌توانند با نسل دستگاه و Firmware تغییر کنند؛ بنابراین Encryption Tool و راهنمای همان Firmware را با هم استفاده کنید.

Aeskey.txt را روی Provisioning Server عمومی نگذارید

ابزار Encryption می‌تواند فایلی به نام:

Aeskey.txt

ایجاد کند که Keyهای Plaintext در آن ذخیره شده‌اند.

این فایل یک Secret است.

آن را داخل Web Root قرار ندهید.

بهتر است:

/srv/yealink-provision/

فقط فایل‌های موردنیاز تلفن را داشته باشد و Keys در مسیر جداگانه و محدود ذخیره شوند.

HTTPS و Encryption جای هم را نمی‌گیرند

این دو لایه هدف متفاوت دارند.

HTTPS:

مسیر انتقال بین تلفن و Server را محافظت می‌کند.

Config Encryption:

خود فایل Configuration را در حالت ذخیره‌شده و هنگام جابه‌جایی محافظت می‌کند.

برای Configurationهای دارای SIP Password استفاده هم‌زمان از این دو دفاع قوی‌تری ایجاد می‌کند.

Provisioning Interval را چطور تنظیم کنیم؟

Yealink چند Trigger برای Auto Provisioning دارد.

از جمله:

Power On
Repeatedly
Weekly
Flexible
Auto Provision Now
SIP NOTIFY

برای چند ده تلفن، همیشه Repeatedly با Interval خیلی کوتاه انتخاب خوبی نیست.

Repeated Provisioning

پارامترهای اصلی:

static.auto_provision.repeat.enable
static.auto_provision.repeat.minutes

در مستندات فعلی مقدار پیش‌فرض Repeat Interval برابر:

1440 minutes

یعنی ۲۴ ساعت ذکر شده است.

نمونه:

static.auto_provision.repeat.enable = 1
static.auto_provision.repeat.minutes = 1440

هر پنج دقیقه Provision نکنید مگر دلیل مشخص داشته باشید

برای ۵۰ تلفن، Interval بسیار کوتاه باعث Requestهای زیاد و افزایش احتمال اعمال سریع یک Configuration خراب روی تمام دستگاه‌ها می‌شود.

برای محیط پایدار می‌توانید از Provisioning روزانه یا Weekly Window استفاده کنید و تغییر فوری را فقط روی گروه Pilot اعمال کنید.

Weekly Provisioning برای محیط عملیاتی مناسب‌تر است

Yealink اجازه می‌دهد روز و بازه زمانی Provisioning هفتگی را تعیین کنید.

مثلاً:

02:00 تا 04:00

در زمانی که تماس کمی وجود دارد.

Yealink همچنین می‌تواند Provisioning را به زمانی موکول کند که تلفن برای مدت مشخصی Inactive بوده باشد.

اگر هنگام Provisioning تماس فعال باشد چه می‌شود؟

در مستندات فعلی Yealink، تلفن هنگام وجود Active Call وضعیت تماس را در فاصله‌های زمانی بررسی می‌کند و Provisioning را تا پایان تماس به تعویق می‌اندازد؛ بنابراین Scheduling کم‌ترافیک همچنان بهترین انتخاب است.

Force Reboot را با احتیاط استفاده کنید

پارامتر:

static.auto_provision.reboot_force.enable

می‌تواند تلفن را بعد از Auto Provisioning مجبور به Reboot کند.

اما Yealink خودش هشدار می‌دهد ترکیب اشتباه این گزینه با Provisioning هنگام Power On می‌تواند Loop راه‌اندازی مجدد ایجاد کند.

پس Reboot اجباری را فقط زمانی فعال کنید که Configuration واقعاً به Reboot نیاز دارد.

روش امن Rollout برای ۴۰ تلفن

به‌جای اعمال یک تغییر روی همه دستگاه‌ها، Deployment را مرحله‌ای انجام دهید.

مثلاً:

مرحله 1:
1 تلفن آزمایشگاه

مرحله 2:
3 تلفن IT

مرحله 3:
5 تلفن یک بخش

مرحله 4:
باقی دستگاه‌ها

هر مرحله باید حداقل Registration، تماس ورودی، تماس خروجی، TLS و Reboot را آزمایش کند.

قبل از هر تغییر Backup بگیرید

نسخه Configuration قبلی را نگه دارید.

برای مثال:

archive/
└── 2026-10-11-before-tls/
    ├── y000000000096.cfg
    ├── 00156574b150.cfg
    └── 00156574b151.cfg

بهتر است تغییرات Configuration در یک Git Repository خصوصی هم ثبت شوند؛ اما Secretها را در Repository عمومی قرار ندهید.

Rollback واقعی چگونه انجام شود؟

اگر Configuration جدید مشکل ایجاد کرد:

فایل Last Known Good را به مسیر فعال برگردانید.

روی یک تلفن Pilot Provisioning را اجرا کنید.

نتیجه را بررسی کنید.

بعد سایر دستگاه‌ها را به نسخه قبلی برگردانید.

اما یک نکته مهم وجود دارد: حذف یک خط از CFG همیشه به معنی پاک‌شدن مقدار فعلی تلفن نیست.

چرا حذف Parameter لزوماً Rollback نیست؟

فرض کنید فایل خراب این مقدار را ایجاد کرده است:

account.1.sip_server.1.address = wrong.example.com

اگر در نسخه Rollback فقط این خط را حذف کنید، ممکن است تلفن مقدار فعلی را نگه دارد.

برای Rollback قابل پیش‌بینی بهتر است مقدار صحیح را صریحاً دوباره تعیین کنید.

در مواردی که لازم است یک مقدار حذف شود، Yealink برای برخی تنظیمات استفاده از:

%NULL%

را مستند کرده است.

نمونه پاک‌کردن Account در صورت نیاز

#!version:1.0.0.1

account.1.enable = %NULL%
account.1.label = %NULL%
account.1.display_name = %NULL%
account.1.auth_name = %NULL%
account.1.user_name = %NULL%
account.1.password = %NULL%
account.1.sip_server.1.address = %NULL%

این کار را فقط وقتی انجام دهید که واقعاً قصد پاک‌کردن Account را دارید؛ استفاده تصادفی از %NULL% می‌تواند Configuration فعال کاربران را حذف کند.

روی Windows Server هم می‌توان Provisioning Server ساخت

اگر زیرساخت شما Windows Server است، می‌توانید همان معماری را با IIS اجرا کنید.

روی PowerShell با دسترسی Administrator:

Install-WindowsFeature Web-Server,Web-Basic-Auth,Web-Mgmt-Console

سپس:

یک Site یا Virtual Directory برای فایل‌های Provisioning بسازید.

HTTPS Binding و Certificate معتبر اضافه کنید.

Anonymous Authentication را غیرفعال و Basic Authentication را فعال کنید.

Permission پوشه را Read-only برای Identity وب‌سرور تنظیم کنید.

Basic Authentication را فقط روی HTTPS استفاده کنید.

Provisioning Server را قابل نوشتن برای تلفن‌ها نکنید

اگر فقط قرار است تلفن Configuration دانلود کند، Endpoint به Upload Permission نیاز ندارد.

اصل Least Privilege را رعایت کنید:

GET  → مجاز
HEAD → مجاز
PUT  → غیرمجاز
POST → غیرمجاز
DELETE → غیرمجاز

اگر بعداً قابلیتی مانند Upload MAC-local CFG استفاده می‌کنید، آن را در Endpoint یا مسیر جداگانه‌ای با Permission محدود پیاده کنید.

Directory Listing را خاموش کنید

نباید کاربر بتواند با بازکردن:

https://provision.example.com/

فهرست تمام MAC Addressها و فایل‌های Configuration را ببیند.

در Nginx:

autoindex off;

را فعال نگه دارید.

Provisioning Server را در صورت امکان با Firewall محدود کنید

اگر تمام تلفن‌ها از یک دفتر یا VPN مشخص متصل می‌شوند، می‌توانید HTTPS Provisioning را فقط برای IPهای موردنیاز مجاز کنید.

اما اگر تلفن‌ها روی اینترنت‌های مختلف با IP پویا هستند، IP Allowlist ممکن است عملی نباشد.

در آن حالت HTTPS، Authentication قوی، Config Encryption و Monitoring اهمیت بیشتری دارند.

Access Log را بررسی کنید

برای Nginx:

sudo tail -f /var/log/nginx/access.log

سپس Auto Provision Now را روی یک تلفن بزنید.

باید درخواست‌هایی مانند این ببینید:

GET /y000000000096.cfg
GET /00156574b150.cfg

اگر:

404

می‌بینید، نام فایل یا مسیر اشتباه است.

اگر:

401

می‌بینید، Username یا Password دسترسی اشتباه است.

اگر هیچ Requestی ندارید، تلفن احتمالاً به Provisioning Server نمی‌رسد یا URL صحیح را دریافت نکرده است.

دقت کنید Access Log شامل MAC دستگاه‌ها می‌شود

چون نام فایل MAC-Oriented از MAC Address ساخته می‌شود، Web Server Log نیز ممکن است MAC دستگاه را ثبت کند.

Logها را عمومی نکنید و دسترسی و Retention آن‌ها را مدیریت کنید.

HTTP 404 در Provisioning معمولاً از چیست؟

طبق راهنمای عیب‌یابی رسمی Yealink، سه مورد مهم را بررسی کنید:

Server درست راه‌اندازی شده است.

URL صحیح است.

فایل در Server واقعاً وجود دارد.

برای مثال:

curl -u yealink_ro:'PASSWORD' \
https://provision.example.com/00156574b150.cfg

اگر Browser یا curl هم فایل را دریافت نمی‌کند، تلفن نیز نمی‌تواند آن را بگیرد.

اگر HTTPS Authentication Fail شد چه؟

اول Credentials را بررسی کنید.

بعد Certificate را ببینید.

اگر Yealink فقط Trusted Certificates را قبول می‌کند و CA سرور داخل Trust Store تلفن نیست، Download متوقف می‌شود.

راه صحیح Import کردن CA معتبر به Trusted Certificates است.

PCAP و Syslog برای Auto Provisioning

اگر Server Log می‌گوید تلفن هیچ Requestی ندارد، از خود Yealink Diagnostic بگیرید.

در بسیاری از مدل‌ها:

Settings → Configuration
→ Export All Diagnostic Files

در PCAP این مراحل را بررسی کنید:

DNS
TCP
TLS
HTTP/HTTPS

برای HTTPS محتوای Request رمزگذاری می‌شود، اما می‌توانید مشخص کنید آیا TCP و TLS Handshake انجام شده‌اند یا خیر.

چک‌لیست قبل از اضافه‌کردن تمام تلفن‌ها

یک معماری امن نهایی برای ۵۰ تلفن

اگر بخواهیم کل مقاله را به یک طراحی عملی تبدیل کنیم، ساختار پیشنهادی چنین است:

50 Yealink Phones
        │
        │ HTTPS / 443
        ▼
provision.example.com
        │
        ├── TLS Certificate
        ├── Authentication
        ├── Read-only Access
        ├── No Directory Listing
        │
        ├── Common CFG per model
        │
        ├── MAC CFG per phone
        │
        ├── Encrypted sensitive CFG
        │
        └── Versioned backups
                │
                ├── Current
                ├── Previous
                └── Last Known Good

در این معماری حتی اگر تعداد تلفن‌ها از ۳۰ به ۱۰۰ دستگاه افزایش پیدا کند، روش مدیریت تغییر نمی‌کند.

پرسش‌های متداول درباره Yealink Auto Provisioning

برای Auto Provisioning یالینک Common CFG بهتر است یا MAC CFG؟

هر دو کاربرد متفاوت دارند. Common CFG برای تنظیمات مشترک تلفن‌های یک مدل است و MAC CFG برای اطلاعات اختصاصی یک تلفن مانند SIP Account مناسب است.

نام فایل MAC تلفن Yealink چگونه ساخته می‌شود؟

MAC Address را بدون علامت دو نقطه یا خط تیره و با حروف کوچک بنویسید. برای MAC برابر 00:15:65:74:B1:50 نام فایل برابر 00156574b150.cfg خواهد بود.

آیا می‌توان Provisioning Server را روی VPS راه‌اندازی کرد؟

بله. یک VPS لینوکس با Nginx و HTTPS می‌تواند Provisioning Server باشد. برای دستگاه‌های اینترنتی باید Authentication، Certificate Validation، Firewall و حفاظت فایل‌های Configuration جدی گرفته شود.

آیا TFTP برای ده‌ها تلفن انتخاب خوبی است؟

برای شبکه محلی کنترل‌شده ممکن است استفاده شود، اما وقتی Configuration شامل Credentials است یا Server روی اینترنت قرار دارد، HTTPS امکان رمزگذاری مسیر و اعتبارسنجی Server را فراهم می‌کند و انتخاب مناسب‌تری است.

هر چند وقت یک بار تلفن‌ها Provision شوند؟

بستگی به محیط دارد. Yealink از Power On، Repeatedly و Weekly پشتیبانی می‌کند و Repeat Interval پیش‌فرض در مستندات فعلی بسیاری از مدل‌ها ۱۴۴۰ دقیقه است. برای محیط پایدار Provisioning بسیار پرتکرار معمولاً ضروری نیست.

چگونه Password داخلی‌ها را در Provisioning امن کنیم؟

از HTTPS استفاده کنید، دسترسی Server را احراز هویت کنید، Passwordها را داخل Common CFG قرار ندهید و در صورت پشتیبانی مدل و Firmware از Configuration File Encryption رسمی Yealink استفاده کنید.

اگر Config اشتباه روی تمام تلفن‌ها اعمال شد چه کنیم؟

Last Known Good Configuration را برگردانید و ابتدا روی یک تلفن Pilot Provision کنید. برای Parameterهایی که در Configuration خراب ایجاد شده‌اند، فقط حذف خط از فایل همیشه کافی نیست و ممکن است لازم باشد مقدار صحیح یا %NULL% صریحاً اعمال شود.

چرا Yealink از Provisioning Server فایل نمی‌گیرد؟

URL، DNS، HTTPS Certificate، Username و Password، وجود فایل، نام Common CFG و MAC CFG و Web Server Log را بررسی کنید. خطاهای 401 و 404 معمولاً سرنخ خوبی درباره محل مشکل هستند.

جمع‌بندی

Yealink Auto Provisioning زمانی ارزش واقعی خود را نشان می‌دهد که تعداد تلفن‌ها از چند دستگاه بیشتر شود. به‌جای اینکه هر تلفن جداگانه مدیریت شود، تنظیمات مشترک را در Common CFG، اطلاعات اختصاصی کاربران را در MAC CFG و فایل‌های موضوعی را در Custom CFG قرار می‌دهید.

برای محیط عملیاتی، Provisioning Server را فقط یک پوشه فایل ساده نبینید. HTTPS، Certificate Validation، Authentication، Permission فقط‌خواندنی، غیرفعال‌بودن Directory Listing و محافظت از SIP Passwordها بخش اصلی طراحی هستند.

در نهایت مهم‌ترین بخش یک Deployment حرفه‌ای، Rollback است. ابتدا یک تلفن Pilot را Provision کنید، سپس چند تلفن محدود و فقط بعد از تأیید تماس ورودی، خروجی، Registration و Reboot تغییر را روی همه دستگاه‌ها اعمال کنید. با این روش Auto Provisioning از یک ابزار صرفاً راحت به یک سیستم مدیریت متمرکز، امن و قابل بازگشت برای ده‌ها تلفن Yealink تبدیل می‌شود.