چرا تنظیم خودکار تلفن یالینک اجرا نمی‌شود؟ رفع خطاهای HTTP و HTTPS

در یک Provisioning سالم، تلفن ابتدا باید آدرس سرور را داشته باشد، نام دامنه را با DNS پیدا کند، اتصال HTTP یا HTTPS را برقرار کند، در صورت نیاز احراز هویت شود، فایل CFG صحیح را درخواست کند، پاسخ موفق سرور را بگیرد و در پایان محتوای فایل را Parse و Apply کند. بنابراین «Provisioning Failed» می‌تواند از DNS، TLS، Username و Password، Permission، نام فایل، Redirect، Syntax فایل یا حتی این واقعیت باشد که Yealink نسخه جدید فایل را از نظر محتوا تغییریافته تشخیص نمی‌دهد.

در این آموزش هر مرحله را جداگانه آزمایش می‌کنیم. با Web Server Log، curl، Packet Capture و Syslog خود Yealink مشخص می‌کنیم تلفن دقیقاً چه URL و فایلی را درخواست کرده، چه HTTP Status دریافت کرده و آیا فایل بعد از دانلود واقعاً روی دستگاه اعمال شده است یا نه.

قبل از عیب‌یابی، دو نوع خطا را از هم جدا کنید

اول مشخص کنید تلفن اصلاً فایل CFG را دانلود نمی‌کند یا فایل دانلود می‌شود اما تنظیمات آن اعمال نمی‌شوند. این دو مشکل علت‌های متفاوتی دارند.

Auto Provisioning سالم چه مراحلی دارد؟

جریان ساده برای یک Provisioning Server روی HTTPS تقریباً چنین است:

Yealink
↓
Provisioning Trigger
↓
DNS Query
↓
TCP Connection
↓
TLS Handshake
↓
HTTP GET
↓
Authentication
↓
HTTP 200
↓
CFG Download
↓
CFG Parse
↓
Apply Configuration

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

مرحله اول: URL واقعی Provisioning را بررسی کنید

در بسیاری از تلفن‌های Yealink از رابط وب وارد بخش زیر شوید:

Settings → Auto Provision

Server URL را دقیق بررسی کنید.

مثلاً:

https://provision.example.com/

یا اگر فایل‌ها داخل مسیر خاصی هستند:

https://provision.example.com/yealink/

وجود یا نبودن یک مسیر فرعی می‌تواند باعث 404 شود.

برای مثال فایل واقعی در این مسیر قرار دارد:

/srv/yealink-provision/00156574b150.cfg

اما Nginx روی URL زیر منتشر شده است:

https://provision.example.com/phones/

اگر تلفن فقط این URL را داشته باشد:

https://provision.example.com/

ممکن است فایل مورد انتظار را در مسیر اشتباه درخواست کند.

URL را از یک سیستم معمولی آزمایش کنید

خود Yealink نیز در راهنمای عیب‌یابی پیشنهاد می‌کند URL Provisioning را خارج از تلفن آزمایش کنید. اگر مرورگر یا Client دیگر نمی‌تواند فایل را از آن URL بگیرد، انتظار نداشته باشید تلفن بتواند آن را دریافت کند.

با curl تست کنید:

curl -v https://provision.example.com/00156574b150.cfg

اگر Authentication دارید:

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

به این موارد دقت کنید:

HTTP Status
TLS Certificate
Redirect
Content Length
Requested Path

HTTP Status سریع‌ترین سرنخ است

اگر Request تلفن به سرور رسیده، HTTP Status معمولاً محدوده مشکل را بسیار کوچک می‌کند.

خطای 404 یکی از رایج‌ترین مشکلات Provisioning است

خود Yealink در راهنمای Auto Provisioning برای HTTP 404 سه مورد اصلی را پیشنهاد می‌کند:

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

Access URL درست باشد.

فایل مورد درخواست واقعاً روی Server وجود داشته باشد.

برای بررسی فایل:

ls -lah /srv/yealink-provision/

مثلاً باید فایل زیر را ببینید:

00156574b150.cfg

از Web Server Log بفهمید Yealink دقیقاً چه فایلی می‌خواهد

اگر Nginx دارید:

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

سپس روی تلفن:

Auto Provision Now

را اجرا کنید.

ممکن است ببینید:

GET /00156574b150.cfg HTTP/1.1" 404

این نتیجه بسیار مهم‌تر از حدس‌زدن Filename است. تلفن به‌صورت واضح گفته چه فایلی را درخواست کرده و Server هم گفته آن فایل وجود ندارد.

MAC CFG را با MAC واقعی تطبیق دهید

اگر MAC Address تلفن:

00:15:65:74:B1:50

باشد، فایل MAC-Oriented معمولاً باید به شکل زیر باشد:

00156574b150.cfg

بدون:

:
-
space

و با MAC صحیح همان دستگاه.

به‌جای حدس‌زدن، Request واقعی تلفن در Access Log را مرجع قرار دهید.

Common CFG نیز مدل‌محور است

Common CFG بین همه مدل‌های Yealink نام یکسانی ندارد.

اگر فایل Common مربوط به T54W را برای مدل دیگری قرار دهید، آن دستگاه لزوماً همان Filename را درخواست نمی‌کند.

برای همین هنگام داشتن چند مدل Yealink، Access Log و Provisioning Guide همان مدل را بررسی کنید.

Boot File می‌تواند باعث سردرگمی شود

در معماری‌های جدیدتر ممکن است از Common Boot File یا MAC-Oriented Boot File نیز استفاده شود.

Yealink هشدار می‌دهد اگر MAC-Oriented Boot File و Common Boot File هم‌زمان وجود داشته باشند، تلفن می‌تواند MAC-Oriented Boot را در اولویت قرار دهد و فقط Configurationهایی را که در همان Boot File معرفی شده‌اند دریافت کند.

بنابراین ممکن است فایل CFG روی Server وجود داشته باشد اما تلفن اصلاً آن را درخواست نکند.

Web Server Log بهترین روش برای تشخیص این وضعیت است.

مرحله دوم: DNS را بررسی کنید

اگر Provisioning URL بر پایه Domain است:

https://provision.example.com/

تلفن قبل از HTTPS باید Domain را Resolve کند.

از یک سیستم داخل همان VLAN تلفن اجرا کنید:

nslookup provision.example.com

در Linux:

dig A provision.example.com +short

اگر IP اشتباه برمی‌گردد یا هیچ Response وجود ندارد، Provisioning هنوز به مرحله HTTP نرسیده است.

DNS سالم روی لپ‌تاپ الزاماً DNS سالم روی Yealink نیست

ممکن است کامپیوتر DNS متفاوتی از تلفن داشته باشد.

DNS Serverهای خود Yealink را از بخش Network بررسی کنید.

بهترین راه، PCAP خود تلفن است.

در Wireshark:

dns

را وارد کنید.

باید Query مربوط به Domain Provisioning را ببینید.

اگر DNS جواب نمی‌دهد

این موارد را بررسی کنید:

DHCP Option 6.

Primary DNS.

Secondary DNS.

VLAN.

Firewall.

Domain اشتباه.

Split DNS.

اگر Domain فقط داخل شبکه سازمان Resolve می‌شود اما تلفن در شعبه دیگری قرار دارد، DNS Architecture را نیز بررسی کنید.

مرحله سوم: HTTP یا HTTPS واقعاً باز است؟

برای HTTP:

curl -v http://provision.example.com/00156574b150.cfg

برای HTTPS:

curl -v https://provision.example.com/00156574b150.cfg

در Windows می‌توانید Port را هم بررسی کنید:

Test-NetConnection provision.example.com -Port 443

اگر TCP 443 باز نیست، هنوز وارد Certificate Troubleshooting نشوید.

HTTPS باز است اما Yealink فایل نمی‌گیرد

در این حالت Certificate یکی از مهم‌ترین مظنون‌ها است.

Yealink در مستندات فعلی می‌گوید اگر Provisioning Server Certificate توسط تلفن قابل اعتماد نباشد و دستگاه فقط Trusted Certificates را قبول کند، Download می‌تواند متوقف شود.

در رابط وب معمولاً از مسیر:

Security → Trusted Certificates

Trust Store را بررسی کنید.

Certificate سرور را با OpenSSL بررسی کنید

openssl s_client \
-connect provision.example.com:443 \
-servername provision.example.com \
-showcerts

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

Verify return code
Certificate Chain
Not Before
Not After
Subject Alternative Name

اگر Server Certificate برای Domain دیگری صادر شده باشد یا Chain ناقص باشد، Yealink ممکن است اتصال HTTPS را قبل از HTTP GET متوقف کند.

Verification را برای راه‌حل دائمی خاموش نکنید

Yealink برای عیب‌یابی امکان تغییر سیاست Trusted Certificate را دارد، اما اگر با غیرفعال‌کردن Verification Provisioning کار کرد، نتیجه این نیست که Verification باید برای همیشه خاموش بماند.

نتیجه واقعی این است که Certificate یا Trust Store شما مشکل دارد.

CA مناسب را Import کنید یا Chain سمت Server را اصلاح کنید و Verification را دوباره فعال نگه دارید.

مرحله چهارم: 401 Unauthorized را بررسی کنید

اگر Web Server Log چیزی شبیه این نشان می‌دهد:

GET /00156574b150.cfg HTTP/1.1" 401

Yealink به Server رسیده اما Authentication موفق نشده است.

Username و Password را در:

Settings → Auto Provision

بررسی کنید.

در Configuration پارامترهای مربوطه می‌توانند شامل مواردی مانند:

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

باشند.

Credential را با curl تست کنید

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

اگر با همین Credential هم 401 می‌گیرید، مشکل از Yealink نیست.

Password، htpasswd یا Authentication Backend سمت Server را اصلاح کنید.

اگر curl کار می‌کند ولی Yealink 401 می‌گیرد

در این حالت بررسی کنید:

Username داخل تلفن دقیقاً یکسان باشد.

Password دارای Space ابتدا یا انتها نباشد.

Provisioning URL از منبع دیگری مانند DHCP یا RPS Override نشده باشد.

Credential روی همان Server نهایی معتبر باشد.

Redirect تلفن را به Host دیگری نبرده باشد.

مرحله پنجم: خطای 403 Forbidden

403 یعنی Server درخواست را دریافت کرده و فهمیده اما دسترسی را اجازه نداده است.

در Nginx مواردی مثل این‌ها می‌توانند علت باشند:

allow / deny
auth policy
file permissions
location rules
IP restriction

Error Log را بررسی کنید:

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

Permission فایل‌ها را بررسی کنید

برای مثال:

ls -lah /srv/yealink-provision/00156574b150.cfg

اگر Nginx تحت گروه www-data اجرا می‌شود، باید امکان Read فایل و Traverse دایرکتوری را داشته باشد.

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

Directory: 750
File:      640
Owner:     root
Group:     www-data

نمونه:

sudo chown root:www-data \
/srv/yealink-provision/00156574b150.cfg

sudo chmod 640 \
/srv/yealink-provision/00156574b150.cfg

Permission را بی‌دلیل روی 777 قرار ندهید.

با خود User وب‌سرور فایل را تست کنید

روی Ubuntu/Nginx:

sudo -u www-data \
cat /srv/yealink-provision/00156574b150.cfg

اگر Permission Denied دریافت کردید، مشکل فایل‌سیستم دارید.

SELinux هم می‌تواند 403 ایجاد کند

اگر Server از توزیعی با SELinux فعال استفاده می‌کند، Unix Permission به‌تنهایی کافی نیست.

وضعیت را بررسی کنید:

getenforce

اگر Enforcing است، Context مسیر Web Root را هم بررسی کنید.

به‌جای خاموش‌کردن دائمی SELinux، Context و Policy صحیح برای همان مسیر ایجاد کنید.

مرحله ششم: Redirect را بررسی کنید

گاهی Server درخواست HTTP را به HTTPS Redirect می‌کند:

http://provision.example.com/
↓
301 / 302
↓
https://provision.example.com/

یا:

https://provision.example.com/
↓
302
↓
https://www.example.com/login

سناریوی دوم برای Provisioning مناسب نیست.

با curl زنجیره Redirect را ببینید

curl -I http://provision.example.com/00156574b150.cfg

اگر پاسخ:

HTTP/1.1 301 Moved Permanently
Location: https://provision.example.com/00156574b150.cfg

می‌گیرید، Redirect وجود دارد.

برای دنبال‌کردن Redirect:

curl -IL \
https://provision.example.com/00156574b150.cfg

برای Provisioning بهتر است URL نهایی را مستقیم استفاده کنید

رفتار Redirect می‌تواند با مدل، Firmware، Authentication و Host مقصد ترکیب شود.

برای همین اگر آدرس نهایی مشخص است، بهتر است Yealink مستقیماً همان URL نهایی را داشته باشد.

مثلاً به‌جای:

http://provision.example.com

مستقیماً:

https://provision.example.com/

را تنظیم کنید.

Redirect به Domain دیگر خطر بیشتری دارد

اگر Server تلفن را به Host دیگری Redirect کند:

provision.example.com
↓
files.example.net

موارد زیر دوباره مطرح می‌شوند:

DNS.

Certificate جدید.

Credential.

Firewall.

Trust Store.

پس فقط Status 302 را نبینید؛ مقدار Location را نیز بررسی کنید.

مرحله هفتم: Server پاسخ 200 می‌دهد ولی تنظیمات اعمال نمی‌شوند

این نقطه بسیار مهم است.

اگر Access Log:

GET /00156574b150.cfg HTTP/1.1" 200

نشان می‌دهد، مرحله Download احتمالاً موفق بوده است.

اکنون باید خود CFG Processing بررسی شود.

اولین خط فایل CFG باید صحیح باشد

Yealink در مستندات Auto Provisioning تأکید می‌کند Header فایل نباید حذف یا تغییر داده شود و باید در خط اول قرار گیرد:

#!version:1.0.0.1

بنابراین فایل صحیح:

#!version:1.0.0.1

account.1.enable = 1
account.1.label = 201

است.

وجود متن، BOM یا محتوای نامناسب قبل از Header می‌تواند Parsing را خراب کند.

Syntax پارامترها را بررسی کنید

نمونه:

account.1.enable = 1

باید مطابق Configuration Reference همان مدل و Firmware باشد.

پارامتری که برای یک نسل قدیمی نوشته شده ممکن است در Firmware جدید نام متفاوتی داشته باشد یا دیگر کاربرد نداشته باشد.

فایل را با ویرایشگر متن مناسب ذخیره کنید

برای CFG از ابزارهایی مانند VS Code یا Notepad++ استفاده کنید.

Word یا ویرایشگرهایی که کاراکترهای قالب‌بندی‌شده وارد می‌کنند انتخاب خوبی نیستند.

به‌خصوص مراقب این موارد باشید:

Smart quotes
Invisible characters
BOM
تبدیل خودکار کاراکترها

فایل رمزگذاری شده ولی AES Key اشتباه است

Yealink به‌طور رسمی یکی از دلایل «فایل دانلود شده ولی تنظیمات Apply نمی‌شود» را Encryption بدون AES Key صحیح معرفی می‌کند.

اگر CFG را با ابزار Yealink Encrypt کرده‌اید، تلفن باید Key مناسب همان فایل را داشته باشد.

در غیر این صورت Download موفق است اما تلفن قادر به Decrypt و Parse کردن فایل نیست.

این خطا را از HTTPS Encryption جدا کنید

HTTPS ارتباط Server تا تلفن را رمزگذاری می‌کند.

CFG Encryption خود فایل را رمزگذاری می‌کند.

ممکن است HTTPS کاملاً سالم باشد ولی AES Key فایل اشتباه باشد.

MD5 یک نکته کمتر شناخته‌شده است

طبق راهنمای عیب‌یابی رسمی Yealink، تلفن بعد از Download می‌تواند MD5 فایل CFG را بررسی کند.

اگر MD5 فایل با نسخه‌ای که قبلاً روی دستگاه پردازش شده یکسان باشد، تلفن ممکن است تنظیمات را دوباره Apply نکند.

این رفتار زمانی مهم می‌شود که Administrator فکر می‌کند Provisioning اجرا نشده، در حالی که دستگاه تشخیص داده فایل همان نسخه قبلی است.

چطور بفهمیم فایل واقعاً تغییر کرده؟

روی Server:

md5sum 00156574b150.cfg

بعد از ویرایش دوباره:

md5sum 00156574b150.cfg

اگر Hash تغییر نکرده، محتوای فایل نیز تغییر نکرده است.

اگر فقط Comment را تغییر دهیم چه؟

ممکن است تغییر Comment Hash فایل را تغییر دهد ولی هیچ Configuration واقعی تغییر نکند.

برای تست Apply بهتر است یک پارامتر کم‌خطر و قابل مشاهده را تغییر دهید.

مثلاً Label یک Account آزمایشی.

اولویت تنظیمات هم می‌تواند باعث شود CFG ظاهراً بی‌اثر باشد

در بعضی خانواده‌ها و Firmwareهای Yealink، Configuration Methodها اولویت دارند.

ممکن است مقداری از Web UI یا روش مدیریتی دیگری با اولویت بالاتر ثبت شده باشد و مقدار Central Provisioning نتواند آن را Override کند.

اگر فایل با 200 دانلود می‌شود، Syntax صحیح است و Log نیز Parsing را نشان می‌دهد اما یک Parameter خاص عوض نمی‌شود، Configuration Priority را بررسی کنید.

مرحله هشتم: Packet Capture از خود Yealink بگیرید

اگر هنوز علت روشن نیست، از دستگاه Diagnostic کامل بگیرید.

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

Settings → Configuration

سپس:

Export All Diagnostic Files → Start

مشکل را بازتولید کنید.

بعد:

Stop → Export

Yealink در مستندات فعلی توصیه می‌کند PCAP، Syslog سطح 6 و Config.bin برای عیب‌یابی جمع‌آوری شوند.

Capture باید قبل از Auto Provision Now شروع شود

ترتیب صحیح:

Start Diagnostic
↓
Auto Provision Now
↓
صبر تا پایان یا خطا
↓
Stop
↓
Export

اگر Capture را بعد از خطا Start کنید، DNS و TLS Handshake اولیه را از دست می‌دهید.

در PCAP برای HTTP چه چیزی ببینیم؟

اگر Provisioning روی HTTP است، فیلتر:

http

را استفاده کنید.

می‌توانید GET Request، Filename، Host و Status Code را مستقیماً ببینید.

مثلاً:

GET /00156574b150.cfg HTTP/1.1
Host: provision.example.com

و پاسخ:

HTTP/1.1 404 Not Found

در HTTPS چه چیزی می‌بینیم؟

محتوای HTTP داخل TLS رمزگذاری شده است.

اما همچنان می‌توانید موارد زیر را بررسی کنید:

DNS Query.

TCP Connection.

TLS ClientHello.

ServerHello.

Certificate.

TLS Alert.

Connection Close.

برای محتوای HTTP در HTTPS بیشتر به Access Log سرور و Syslog تلفن تکیه کنید.

اگر هیچ TCP Connection به Server ندارید

بررسی کنید Domain به چه IPی Resolve شده است.

Route و Firewall را ببینید.

Server URL داخل تلفن را تأیید کنید.

همچنین بررسی کنید Provisioning Trigger واقعاً اجرا شده باشد.

اگر TCP برقرار می‌شود اما بلافاصله TLS Alert می‌آید

تمرکز را روی:

Certificate Chain.

Trust Store.

Hostname.

Expiration.

TLS Version.

قرار دهید.

در این وضعیت Filename هنوز وارد ماجرا نشده است؛ TLS قبل از HTTP GET شکست خورده است.

مرحله نهم: Syslog دستگاه را بخوانید

Syslog مشخص می‌کند خود Yealink چرا یک مرحله را Fail کرده است.

در فایل Log دنبال عبارت‌هایی مانند این بگردید:

provision
autoprovision
cfg
http
https
download
certificate
AES
MD5
DNS

Timestamp لاگ را با Access Log وب‌سرور مقایسه کنید.

مقایسه Timestamp دو سمت بسیار مهم است

فرض کنید در Syslog تلفن ساعت:

10:14:22

خطای Provisioning ثبت شده است.

در Nginx Log همان لحظه:

10:14:22
GET /00156574b150.cfg
404

در اینجا دیگر نیازی به حدس نیست؛ مشکل Filename یا Server Path است.

اگر Server هیچ Requestی در آن زمان ندارد

مشکل قبل از HTTP قرار دارد.

به ترتیب بررسی کنید:

Provisioning Trigger
Server URL
DNS
Routing
Firewall
TCP
TLS

از Developer Tools مرورگر به‌تنهایی نتیجه نگیرید

اینکه URL روی لپ‌تاپ باز می‌شود مفید است، اما محیط تلفن می‌تواند متفاوت باشد.

کامپیوتر ممکن است:

DNS متفاوت داشته باشد.

CAهای بیشتری داخل Trust Store داشته باشد.

Proxy سازمانی استفاده کند.

Cookie یا Session Authentication داشته باشد.

Redirectهای پیچیده را بهتر دنبال کند.

پس تست مرورگر فقط یکی از مراحل است، نه اثبات نهایی.

یک مشکل رایج: URL به صفحه HTML برمی‌گردد

ممکن است Request با Status 200 پاسخ بگیرد اما محتوای واقعی فایل CFG نباشد.

مثلاً Application یا WAF به‌جای فایل:

<html>
Login required
</html>

برگرداند.

از curl محتوای Response را ببینید:

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

اولین خط باید چیزی شبیه این باشد:

#!version:1.0.0.1

نه صفحه Login یا Error HTML.

Content-Type را هم بررسی کنید؟

برای بسیاری از Web Serverها فایل CFG با Content-Type عمومی ارائه می‌شود و اصل مهم این است که تلفن محتوای صحیح را دریافت کند.

اما اگر Application یا CDN بر اساس Extension فایل را Block یا Rewrite می‌کند، Headerها و Body Response را بررسی کنید.

با:

curl -I https://provision.example.com/00156574b150.cfg

می‌توانید Headerها را ببینید.

CDN و WAF ممکن است Provisioning را خراب کنند

اگر Provisioning Domain پشت CDN، Reverse Proxy یا WAF قرار گرفته، درخواست تلفن ممکن است با Browser رفتار متفاوتی داشته باشد.

موارد محتمل:

Bot Protection.

JavaScript Challenge.

Geo Restriction.

Rate Limit.

Redirect.

Access Policy.

یک IP Phone نمی‌تواند JavaScript Challenge مرورگر را اجرا کند.

برای Provisioning Endpoint بهتر است مسیر فایل‌ها پاسخ ساده و قابل پیش‌بینی داشته باشد.

Cache نیز می‌تواند عیب‌یابی را گیج‌کننده کند

اگر Reverse Proxy یا CDN دارید، ممکن است نسخه قبلی CFG Cache شده باشد.

تاریخ و Hash فایل دریافتی را با Origin مقایسه کنید.

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

چطور یک تست Minimal بسازیم؟

اگر Configuration اصلی بسیار بزرگ است، یک تلفن آزمایشی انتخاب کنید و فایل کوچکی بسازید:

#!version:1.0.0.1

account.1.label = TEST-201

Provision کنید.

اگر Label تغییر کرد، Server، Download و CFG Processing پایه سالم هستند.

سپس Configuration اصلی را مرحله‌به‌مرحله اضافه کنید.

این روش برای پیدا کردن Parameter خراب بسیار مؤثر است

اگر فایل ۸۰۰ خطی Apply نمی‌شود، نصف پارامترها را موقتاً حذف کنید و روی Pilot Test کنید.

با تقسیم مرحله‌ای Configuration می‌توانید Parameter یا Section مشکل‌دار را سریع‌تر پیدا کنید.

هیچ‌وقت این آزمایش را ابتدا روی تمام تلفن‌های سازمان انجام ندهید.

Rollback قبل از تست داشته باشید

نسخه Last Known Good را نگه دارید:

archive/
├── current/
├── previous/
└── last-known-good/

اگر فایل جدید مشکل ایجاد کرد، نسخه قبلی را برگردانید و ابتدا روی یک تلفن Pilot تست کنید.

حذف خط جدید همیشه به معنی برگشت مقدار تلفن نیست؛ در صورت نیاز مقدار صحیح قبلی را صریحاً داخل CFG قرار دهید.

تشخیص سریع از روی Server Log

نقشه عیب‌یابی مرحله‌به‌مرحله

اگر هیچ Request در Server Log نیست، Server URL و DNS را بررسی کنید.

اگر DNS درست است، TCP و TLS را بررسی کنید.

اگر TLS سالم است، ببینید GET ساخته می‌شود یا خیر.

اگر 401 دارید، Credential را اصلاح کنید.

اگر 403 دارید، Permission و ACL را بررسی کنید.

اگر 404 دارید، Filename و مسیر فایل را با Request واقعی تلفن تطبیق دهید.

اگر 301 یا 302 دارید، URL نهایی Redirect را مستقیم تست کنید.

اگر 200 دارید اما تنظیمات Apply نشده‌اند، مشکل را دیگر در DNS و Network جست‌وجو نکنید؛ Header، Syntax، AES Key، MD5 و Configuration Priority را بررسی کنید.

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

چرا Yealink فایل CFG را دانلود نمی‌کند؟

Server URL، DNS، دسترسی شبکه، HTTPS Certificate، Authentication، نام فایل و وجود فایل روی Provisioning Server را بررسی کنید. Access Log وب‌سرور سریع‌ترین روش برای مشخص‌کردن مرحله خطاست.

HTTP 404 در Auto Provisioning یالینک یعنی چه؟

یعنی Web Server فایل یا مسیر درخواست‌شده را پیدا نکرده است. Request واقعی Yealink را در Access Log ببینید و Filename، Web Root و URL را با آن تطبیق دهید.

اگر Server پاسخ 200 بدهد ولی تنظیمات اعمال نشوند چه کنیم؟

در این حالت Download احتمالاً موفق بوده است. خط اول #!version:1.0.0.1، Syntax فایل، AES Key در فایل‌های رمزگذاری‌شده، MD5 و Configuration Priority را بررسی کنید.

چرا HTTPS روی مرورگر کار می‌کند ولی روی Yealink نه؟

Trust Store مرورگر و تلفن یکسان نیست. ممکن است کامپیوتر CA موردنیاز را بشناسد ولی Yealink Certificate Chain را Trusted نداند. Trusted Certificates و Chain سرور را بررسی کنید.

چرا Yealink خطای 401 می‌گیرد؟

Provisioning Server احراز هویت می‌خواهد ولی Username یا Password ارسال‌شده صحیح نیست. Credential را در تلفن و با curl روی همان URL آزمایش کنید.

خطای 403 چه تفاوتی با 401 دارد؟

401 معمولاً به Authentication مربوط است؛ 403 یعنی Server درخواست را شناخته ولی اجازه دسترسی نمی‌دهد. Permission فایل، ACL، IP Restriction و Policy وب‌سرور را بررسی کنید.

Redirect می‌تواند Auto Provisioning را خراب کند؟

بله، مخصوصاً اگر Redirect به Host دیگری با Certificate، Credential یا Access Policy متفاوت برود. هنگام عیب‌یابی URL نهایی را مستقیماً روی تلفن تنظیم کنید.

برای عیب‌یابی دقیق Yealink چه فایل‌هایی لازم است؟

Yealink توصیه می‌کند PCAP، Syslog با سطح 6 و Config.bin جمع‌آوری شوند. Diagnostic را قبل از اجرای Auto Provision Now شروع کنید و بعد از بازتولید مشکل فوراً Export بگیرید.

جمع‌بندی

وقتی Yealink Auto Provisioning اجرا نمی‌شود، همه تنظیمات را هم‌زمان تغییر ندهید. ابتدا مشخص کنید آیا تلفن اصلاً به Server Request می‌فرستد یا خیر. Access Log سرور در این مرحله مهم‌ترین سرنخ است.

اگر Request ندارید، URL، DNS، شبکه و TLS را بررسی کنید. اگر 401 یا 403 دارید، Authentication و Permission مطرح‌اند. اگر 404 دارید، نام فایل و مسیر Server را بررسی کنید. اگر 301 یا 302 دارید، Redirect و مقصد نهایی را ببینید.

اما اگر Server با 200 پاسخ می‌دهد و فایل دانلود می‌شود، عیب‌یابی شبکه را متوقف کنید و وارد خود Configuration شوید: Header فایل، Syntax، Encryption و AES Key، MD5 و اولویت تنظیمات را بررسی کنید. با کنار هم گذاشتن Access Log سرور، PCAP و Syslog سطح 6 تلفن می‌توانید دقیقاً مشخص کنید Provisioning در کدام مرحله متوقف شده است.