در این آموزش تمام مسیر را بدون Factory Reset تصادفی بررسی میکنیم: IP واقعی تلفن، Ping، پورتهای HTTP و HTTPS، تنظیم Web Server، VLAN و Routing، ACL و Firewall، Certificate، Browser، Secure Domain، Auto Provisioning و در نهایت Firmware. هدف این است که مشخص شود مشکل در لایه شبکه است، TCP Port بسته است، TLS شکست میخورد یا خود سرویس Web یالینک غیرفعال شده است.
یک نکته مهم هم از ابتدا روشن باشد: IP گرفتن تلفن به معنی باز بودن پنل وب نیست. DHCP فقط نشان میدهد تلفن توانسته تنظیمات شبکه بگیرد. Web Server میتواند مستقل از آن خاموش یا محدود شده باشد.
اول مطمئن شوید IP درست Yealink را باز میکنید
قبل از بررسی Firewall یا Firmware، IP را مستقیماً از صفحه خود تلفن بردارید. در بسیاری از Desk Phoneهای Yealink با رفتن به بخش Status میتوانید IPv4 فعلی دستگاه را ببینید.
از IP قدیمی که در DHCP Lease، مرورگر یا دفترچه یادداشت دارید استفاده نکنید؛ ممکن است دستگاه بعد از Reboot آدرس جدیدی گرفته باشد.
| مورد | چه چیزی بررسی شود؟ |
|---|---|
| IPv4 | IP فعلی خود تلفن |
| Subnet Mask | شبکه محلی دستگاه |
| Gateway | برای دسترسی بین VLANها |
| VLAN | Data یا Voice VLAN فعلی |
| Firmware | نسخه Global یا سفارشی Provider |
برای شروع HTTPS را با IP مستقیم امتحان کنید
Yealink در راهنمای فعلی ورود به Web UI پیشنهاد میکند IP تلفن را مستقیماً با HTTPS در مرورگر باز کنید.
برای مثال اگر IP دستگاه این باشد:
| IP تلفن | 192.168.20.50 |
|---|---|
| آدرس HTTPS | https://192.168.20.50 |
آدرس را دقیقاً در Address Bar مرورگر وارد کنید؛ آن را داخل Search Box گوگل جستوجو نکنید.
اگر مرورگر Certificate Warning نشان داد، Web Server احتمالاً زنده است
یکی از حالتهای رایج این است که Browser پیامی مانند Privacy Error یا Certificate Warning نمایش دهد. این پیام با «Connection Timed Out» یکسان نیست.
در اتصال مستقیم به IP خصوصی، Certificate دستگاه ممکن است برای همان IP مورد اعتماد مرورگر نباشد. Yealink نیز در راهنمای رسمی خود اشاره میکند که هنگام ورود با HTTPS ممکن است صفحه Privacy Warning دیده شود.
اگر مرورگر اجازه ادامه اتصال را میدهد و شبکه شما قابل اعتماد است، میتوانید برای عیبیابی وارد Advanced شوید و صفحه را ادامه دهید.
اما اگر Certificate مربوط به دستگاه ناشناس یا غیرمنتظرهای است، قبل از ادامه هویت IP را بررسی کنید.
فرق Timeout، Connection Refused و Certificate Error چیست؟
| علامت | برداشت اولیه |
|---|---|
| Connection Timed Out | Firewall، ACL، Route یا Drop شدن Port |
| Connection Refused | IP قابل دسترس است اما سرویس روی آن Port گوش نمیدهد یا Reject میشود |
| Certificate Warning | HTTPS Server پاسخ داده و مشکل به مرحله TLS/Certificate رسیده است |
| Login Page باز میشود | شبکه و Web Server تقریباً سالماند |
| صفحه سفید یا ناقص | Browser Cache، Firmware یا فایلهای Web UI بررسی شوند |
مرحله اول: Ping بگیرید، اما از نتیجه آن بیش از حد برداشت نکنید
از کامپیوتری که قرار است پنل Yealink را باز کند IP تلفن را Ping کنید.
ping 192.168.20.50
اگر Ping پاسخ میدهد، مسیر ICMP بین PC و Phone برقرار است؛ اما هنوز HTTP یا HTTPS را ثابت نکردهاید.
Firewall میتواند ICMP را اجازه دهد ولی TCP/443 را مسدود کند.
اگر Ping هم پاسخ نمیدهد چه؟
ابتدا Web Server را کنار بگذارید و شبکه را بررسی کنید:
آیا PC و Phone در یک Subnet هستند؟
آیا Voice VLAN از Data VLAN جدا شده است؟
آیا بین دو VLAN Route وجود دارد؟
آیا ACL دسترسی Management را مسدود کرده است؟
آیا IP تلفن عوض شده است؟
آیا ARP مربوط به IP موردنظر به MAC درست اشاره میکند؟
ARP را در Windows بررسی کنید
arp -a
اگر تلفن در همان Broadcast Domain است، MAC مربوط به IP را با MAC روی برچسب یا Status Yealink مقایسه کنید.
این کار جلوی عیبیابی IP اشتباه یا Duplicate IP را میگیرد.
مرحله دوم: Port 443 را مستقیم تست کنید
روی Windows PowerShell:
Test-NetConnection 192.168.20.50 -Port 443
اگر نتیجه TCP موفق باشد، TCP/443 تا خود تلفن قابل دسترس است.
این نتیجه بسیار مهم است؛ چون اگر Browser هنوز صفحه را باز نمیکند، تمرکز از Routing و ACL به HTTPS، Certificate، Browser یا Web UI منتقل میشود.
Port 80 را هم بررسی کنید
Test-NetConnection 192.168.20.50 -Port 80
اما یک نکته مهم وجود دارد: رفتار HTTP بین مدلها و Firmwareهای Yealink یکسان نیست. روی بعضی نسخهها HTTP ممکن است غیرفعال باشد و HTTPS روش مورد انتظار دسترسی باشد.
پس بسته بودن Port 80 بهتنهایی خرابی تلفن را ثابت نمیکند.
نتیجه تست Portها را اینطور بخوانید
| Port 80 | Port 443 | برداشت |
|---|---|---|
| بسته | باز | احتمالاً HTTPS فعال و HTTP خاموش است |
| باز | بسته | HTTP فعال یا HTTPS غیرفعال/تغییرپورت داده شده |
| هر دو بسته | هر دو بسته | Web Server غیرفعال، Port تغییر کرده یا ACL/Firewall وجود دارد |
| هر دو باز | هر دو باز | مشکل Browser، TLS یا Login بررسی شود |
مرحله سوم: HTTP و HTTPS ممکن است روی Port دیگری باشند
Yealink امکان تغییر پورت Web Server را در مدلها و Firmwareهای پشتیبانیشده فراهم میکند.
پورتهای متداول عبارتاند از:
| پروتکل | پورت متداول |
|---|---|
| HTTP | 80 |
| HTTPS | 443 |
اما Administrator یا Provisioning Server ممکن است این Portها را تغییر داده باشد.
برای نمونه اگر HTTPS روی 8443 تنظیم شده باشد، باید آدرس را همراه پورت وارد کنید:
| نمونه | https://192.168.20.50:8443 |
|---|
پارامترهای Web Server در Yealink
در مدلهای پشتیبانیشده، پارامترهای Provisioning مربوط به Web UI شامل این موارد هستند:
static.wui.http_enable
static.network.port.http
static.wui.https_enable
static.network.port.https
وجود دقیق همه این پارامترها و مقدار پیشفرض آنها باید با Administrator Guide همان مدل و Firmware تطبیق داده شود.
اگر HTTP و HTTPS هر دو Disable شده باشند چه؟
در این حالت داشتن IP هیچ کمکی به Web UI نمیکند. تلفن میتواند DHCP بگیرد، SIP Register شود و تماس برقرار کند ولی Browser هیچ پنل مدیریتی نبیند.
در مدلهایی که مسیر Phone UI اجازه میدهد، Web Server Type را مستقیماً از صفحه خود تلفن بررسی کنید.
مسیر دقیق بین مدلها متفاوت است، اما در بسیاری از خانوادهها تنظیم Web Server در بخش Advanced Network قرار دارد.
تغییر Web Server میتواند تلفن را Reboot کند
Yealink در مستندات Provisioning خود برای تعدادی از پارامترهای HTTP/HTTPS اعلام میکند که تغییر آنها برای اعمالشدن نیازمند Reboot دستگاه است.
بنابراین اگر Configuration را از Auto Provisioning تغییر میدهید، Reboot بعدی را در برنامه نگهداری در نظر بگیرید.
مرحله چهارم: با curl مشخص کنید TLS تا کجا پیش میرود
اگر Port 443 باز است اما Browser خطای مبهمی میدهد، `curl` اطلاعات بیشتری نشان میدهد.
curl -vk https://192.168.20.50/
گزینه `-v` جزئیات اتصال و TLS را نمایش میدهد و `-k` فقط برای تست اجازه میدهد خطای Trust مربوط به Certificate مانع ادامه درخواست نشود.
از `-k` بهعنوان راهحل امنیتی دائمی استفاده نکنید؛ هدف آن فقط تشخیص است.
اگر curl پاسخ HTTP گرفت ولی Browser باز نمیکند
در این وضعیت شبکه و Web Server تا حد زیادی سالم هستند.
موارد زیر را بررسی کنید:
Browser Cache.
Certificate Warning.
Proxy مرورگر.
افزونههای امنیتی.
Antivirus HTTPS Inspection.
Policyهای مرورگر سازمانی.
با Browser دیگری آزمایش کنید
Yealink در راهنمای فعلی خود Chrome و Edge را برای دسترسی پیشنهاد میکند.
اگر صفحه در یک Browser باز نمیشود، با Private/Incognito Window یا مرورگر دیگر آزمایش کنید.
این تست ساده میتواند Cache، Cookie یا Extensionهای Browser را از عیبیابی حذف کند.
مرحله پنجم: Certificate HTTPS را بررسی کنید
اگر Port 443 قابل دسترس است ولی TLS Handshake شکست میخورد، Certificate و TLS را جداگانه بررسی کنید.
روی سیستمی که OpenSSL دارد:
openssl s_client -connect 192.168.20.50:443
اگر TLS Handshake کامل میشود و Certificate نمایش داده میشود، Web Server واقعاً روی HTTPS پاسخ میدهد.
Certificate Warning با Certificate Failure یکی نیست
اگر Browser فقط Certificate را Trusted نمیداند ولی امکان ادامه اتصال وجود دارد، Web UI از نظر شبکه Down نیست.
اما اگر TLS Negotiation بهطور کامل شکست بخورد، باید Firmware، HTTPS Server، Algorithmها و Compatibility مرورگر بررسی شوند.
تاریخ و ساعت اشتباه را هم بررسی کنید
Certificate دارای بازه اعتبار زمانی است. اگر ساعت دستگاه یا کامپیوتر بهشدت اشتباه باشد، Certificate میتواند Not Yet Valid یا Expired دیده شود.
در شبکهای که TLS اهمیت دارد، NTP تلفن را نیز بررسی کنید.
مرحله ششم: VLAN میتواند Ping را باز بگذارد ولی Web UI را مسدود کند
سناریوی رایج در شبکههای اداری این است که Yealink داخل Voice VLAN و کامپیوتر Administrator داخل Data یا Management VLAN باشد.
مثلاً:
| دستگاه | VLAN | Subnet |
|---|---|---|
| Yealink | Voice VLAN 20 | 192.168.20.0/24 |
| Administrator PC | Management VLAN 30 | 192.168.30.0/24 |
ممکن است Firewall اجازه ICMP از VLAN 30 به VLAN 20 را بدهد ولی TCP/443 را Drop کند.
در نتیجه:
Ping سالم است.
اما Web UI باز نمیشود.
ACL بین VLANها را بررسی کنید
اگر Router یا Layer 3 Switch بین شبکهها ACL دارد، Portهای مدیریت Yealink باید مطابق Policy سازمان بررسی شوند.
روی Cisco بسته به طراحی میتوانید ACLهای فعال را ببینید:
show access-lists
و Configuration Interface یا SVI مربوط را بررسی کنید.
برای تست موقت Firewall را کامل خاموش نکنید
خاموشکردن کل Firewall برای بازکردن پنل یک تلفن روش مناسبی نیست.
بهجای آن Flow مشخص را بررسی کنید:
| Source | Destination | Protocol | Port |
|---|---|---|---|
| Management PC | Yealink IP | TCP | HTTPS Port |
اگر لازم است Rule تستی بسازید، آن را فقط برای Source IP مدیریتی و IP همان Phone محدود کنید.
Web UI تلفن را مستقیماً روی اینترنت منتشر نکنید
برای دسترسی از راه دور، NAT کردن مستقیم Port 80 یا 443 تلفن به اینترنت عمومی راهحل مناسبی نیست.
پنل مدیریتی Phone باید در شبکه داخلی، Management VLAN یا از طریق VPN قابل دسترسی باشد.
این کار سطح حمله دستگاههای VoIP را کاهش میدهد.
مرحله هفتم: اگر روی همان VLAN باز میشود ولی از VLAN دیگر نه
این تست یکی از بهترین روشها برای جداسازی Phone از Firewall است.
یک Laptop را موقتاً طبق Policy شبکه در همان VLAN مجاز تلفن قرار دهید و Web UI را آزمایش کنید.
اگر:
| محل PC | Web UI | برداشت |
|---|---|---|
| همان VLAN تلفن | باز میشود | Web Server تلفن سالم است |
| Management VLAN | باز نمیشود | Routing، ACL یا Firewall بررسی شود |
مرحله هشتم: Domain را کنار بگذارید و با IP تست کنید
اگر تاکنون از نامی مثل `phone.office.local` استفاده میکردید، ابتدا IP مستقیم تلفن را امتحان کنید.
Yealink در مدلهای جدید پارامتری با نام زیر برای کنترل Domainهای مجاز Web UI دارد:
wui.secure_domain_list
در Firmwareهای پشتیبانیشده، این تنظیم میتواند تعیین کند کدام Domainها برای دسترسی Web UI معتبر هستند.
اگر Domain در لیست مجاز نباشد یا DNS آن به IP اشتباه Resolve شود، دسترسی با Name مشکل پیدا میکند در حالی که ورود با IP هنوز کار میکند.
DNS را بررسی کنید
اگر با Domain وارد میشوید:
nslookup phone.office.local
IP برگشتی باید با IP فعلی Yealink یکسان باشد.
مرحله نهم: Auto Provisioning ممکن است Web UI را دوباره ببندد
فرض کنید Web Server را از روی خود Phone فعال میکنید و پنل باز میشود، اما بعد از Reboot دوباره دسترسی قطع میشود.
در این حالت Provisioning Server را بررسی کنید.
ممکن است Common CFG یا MAC CFG دوباره پارامترهای Web Server را Push کند.
برای نمونه:
static.wui.http_enable = 0
static.wui.https_enable = 1
یا ممکن است HTTPS Port در Provisioning به مقدار دیگری تغییر کرده باشد.
فایلهای Provisioning را قبل از Factory Reset بررسی کنید
اگر دستگاه Managed است، Factory Reset ممکن است فقط برای چند دقیقه مشکل را برطرف کند؛ چون تلفن بعد از Boot دوباره همان Configuration مرکزی را دریافت میکند.
بنابراین Source of Truth را پیدا کنید:
Common CFG.
MAC CFG.
RPS.
PBX Device Management.
Provisioning Platform اپراتور.
مرحله دهم: Firmware سفارشی Provider را جدی بگیرید
Yealink در راهنمای رسمی Web UI توضیح میدهد روش معمول ورود برای Global Firmware است و بعضی Firmwareهای غیرGlobal یا سفارشی ممکن است رفتار متفاوتی داشته باشند.
در تلفنهایی که از ISP، مرکز تماس یا Provider خریداری شدهاند، ممکن است:
Web UI محدود شده باشد.
Username یا Password تغییر کرده باشد.
تنظیمات Web Server توسط Provisioning قفل شده باشند.
امکان دسترسی Administrator محدود شده باشد.
در این حالت تغییر Firmware بدون بررسی Provider و Compatibility میتواند دستگاه را از Provisioning خارج کند.
Firmware را فقط برای Web UI بدون بررسی آپدیت نکنید
قبل از Firmware Update مشخص کنید مشکل واقعاً Firmware است.
اگر TCP/443 بسته است چون HTTPS در Configuration خاموش شده، Update Firmware درمان علت نیست.
اگر مشکل دقیقاً بعد از Firmware Upgrade شروع شده، Release Notes و نسخه مدل را بررسی کنید.
برای ارتقای کنترلشده میتوانید از راهنمای آپدیت امن Firmware تلفنهای Yealink استفاده کنید.
اگر بعد از Firmware Update پنل کاملاً از دسترس خارج شده
اگر تلفن بعد از Upgrade رفتار غیرعادی دارد، Web UI باز نمیشود و علائم Boot یا System نیز غیرطبیعی هستند، ابتدا مشخص کنید خود سیستمعامل Phone سالم بالا آمده است.
اگر Boot Loop یا خرابی Firmware دارید، راهنمای ریکاوری Firmware یالینک مرتبطتر است.
مرحله یازدهم: Browser Cache و Session را حذف کنید
اگر Login Page باز میشود ولی بعد از ورود صفحه سفید، Loop یا خطای عجیب دارید، یک Incognito Window آزمایش کنید.
اگر در Incognito سالم است، Cache یا Cookie Browser محتملتر میشود.
همچنین اگر چند Administrator همزمان روی یک Phone کار میکنند، محدودیت Session را هم در نظر بگیرید.
محدودیت Login همزمان در Firmwareهای جدید
در مستندات جدید Yealink پارامتری برای کنترل Login همزمان Web UI وجود دارد:
wui.check_remote.mode
در مدلهای پشتیبانیشده این گزینه میتواند Login همزمان یک User را محدود کند یا Session قبلی را تحت تأثیر قرار دهد.
اگر پیام مربوط به User Busy یا Login IP دیگری میبینید، مشکل با بستهبودن Port فرق دارد.
مرحله دوازدهم: Username و Password را از مشکل باز نشدن صفحه جدا کنید
اگر Login Page را میبینید، Web Server باز شده است.
اشتباه بودن رمز عبور دیگر «پنل وب باز نمیشود» نیست؛ مشکل Authentication است.
Yealink برای Global Firmware در مستندات خود `admin` را بهعنوان اطلاعات پیشفرض بعضی دستگاهها ذکر میکند، اما در Firmware سفارشی، دستگاه مدیریتشده یا تلفنی که قبلاً راهاندازی شده نباید فرض کنید Credential هنوز مقدار کارخانه است.
روی مدلهای جدید حتی ممکن است در Setup اولیه مجبور به تغییر Password شده باشید.
مرحله سیزدهم: Duplicate IP را بررسی کنید
ممکن است صفحهای که باز نمیشود یا Certificate عجیبی که میبینید اصلاً متعلق به Yealink موردنظر نباشد.
اگر دو دستگاه IP یکسان داشته باشند، رفتار میتواند متناوب باشد.
MAC Address را با ARP، Switch MAC Table و MAC خود تلفن مقایسه کنید.
در Cisco:
show mac address-table
مرحله چهاردهم: اگر Wi-Fi استفاده میکنید Interface درست را بررسی کنید
بعضی مدلهای Yealink مانند T54W Wi-Fi داخلی دارند. اگر Phone از Wi-Fi استفاده میکند ولی شما IP مربوط به Ethernet قدیمی را باز میکنید، طبیعتاً Web UI به مقصد اشتباه میرود.
IP فعلی را همیشه از Status خود تلفن بگیرید.
اگر هم Ethernet و هم Wi-Fi در سناریو دخیلاند، مشخص کنید Management Traffic واقعاً روی کدام Interface است.
یک روش عیبیابی سریع بر اساس نتیجه Port Test
| Ping | TCP 443 | نتیجه احتمالی | مرحله بعد |
|---|---|---|---|
| ناموفق | ناموفق | IP، VLAN، Routing یا ACL | شبکه را بررسی کنید |
| موفق | ناموفق | HTTPS خاموش، Port تغییرکرده یا Firewall | Web Server و ACL |
| موفق | موفق | Web Server قابل دسترس است | TLS، Certificate و Browser |
| موفق | Login Page | شبکه سالم است | Credential یا Session |
سناریوی اول: Ping دارید ولی 443 بسته است
این حالت معمولاً یکی از این موارد است:
HTTPS در Yealink Disable شده است.
HTTPS Port تغییر کرده است.
ACL یا Firewall TCP/443 را Drop میکند.
Provisioning Web Server را غیرفعال کرده است.
Firmware یا Provider Policy محدودیت ایجاد کرده است.
سناریوی دوم: 443 باز است ولی مرورگر Timeout میدهد
ابتدا با `curl` همان IP را بررسی کنید.
اگر curl پاسخ میگیرد، Browser یا Proxy/Inspection باید بررسی شود.
اگر TLS Handshake در curl هم متوقف میشود، Certificate، Firmware و TLS Server Phone را بررسی کنید.
سناریوی سوم: با IP باز میشود ولی با نام باز نمیشود
DNS و `wui.secure_domain_list` را بررسی کنید.
این مشکل ارتباطی با DHCP گرفتن Phone ندارد.
سناریوی چهارم: روی VLAN تلفن باز میشود ولی از شبکه مدیر نه
Web UI Phone سالم است.
Routing، Firewall Rule یا ACL بین Management VLAN و Voice VLAN را بررسی کنید.
سناریوی پنجم: بعد از هر Reboot دوباره پنل بسته میشود
Auto Provisioning مظنون اصلی است.
MAC CFG، Common CFG و Device Management Platform را بررسی کنید و ببینید کدام Parameter بعد از Boot دوباره اعمال میشود.
راهنمای عیبیابی Auto Provisioning یالینک برای بررسی HTTP، HTTPS و فایل CFG میتواند در این مرحله مفید باشد.
سناریوی ششم: فقط یک Yealink پنل ندارد ولی بقیه سالماند
اگر همه Phoneها در همان VLAN و همان Switch قابل مدیریت هستند و فقط یک دستگاه مشکل دارد، احتمال خطای سراسری ACL یا VLAN پایینتر است.
این موارد را مقایسه کنید:
Firmware.
Provisioning Profile.
Web Server Type.
HTTP/HTTPS Port.
MAC CFG.
Certificate.
IP Address.
سناریوی هفتم: همه Yealinkها همزمان پنل وب ندارند
در این حالت تغییر مشترک را پیدا کنید:
Firewall Policy.
ACL جدید.
Provisioning Push.
Firmware Rollout.
Voice VLAN Change.
Management VLAN Change.
Browser/Endpoint Security Policy.
اگر دقیقاً بعد از یک Provisioning Job همه Phoneها از دسترس Web خارج شدند، تکتک دستگاهها را Factory Reset نکنید؛ ابتدا Configuration مرکزی را بررسی کنید.
Factory Reset چه زمانی منطقی است؟
Factory Reset باید نزدیک انتهای مسیر عیبیابی باشد، نه اولین قدم.
قبل از Reset مطمئن شوید:
IP درست را دارید.
Portهای 80 و 443 را تست کردهاید.
ACL و VLAN سالماند.
Web Server Configuration را بررسی کردهاید.
Auto Provisioning دوباره همان مشکل را برنمیگرداند.
اطلاعات SIP و Configuration قابل بازیابی هستند.
بعد از Reset چه خطری وجود دارد؟
اگر Provisioning URL یا تنظیمات PBX را نداشته باشید، ممکن است تلفن از سرویس خارج شود.
در محیط سازمانی قبل از Factory Reset از Device Management، Backup یا فایل Configuration استفاده کنید.
چکلیست نهایی وقتی پنل وب Yealink باز نمیشود
| مرحله | بررسی | هدف |
|---|---|---|
| ۱ | IP از Status تلفن | حذف IP اشتباه |
| ۲ | Ping | بررسی اتصال IP |
| ۳ | TCP/443 | بررسی HTTPS |
| ۴ | TCP/80 | بررسی HTTP در صورت فعال بودن |
| ۵ | HTTPS با IP مستقیم | حذف DNS از تست |
| ۶ | Certificate | تفکیک Warning از Failure |
| ۷ | VLAN و Route | بررسی مسیر Management |
| ۸ | ACL/Firewall | بررسی TCP Management Port |
| ۹ | Web Server Type | بررسی HTTP/HTTPS Enable |
| ۱۰ | Port سفارشی | بررسی تغییر 80/443 |
| ۱۱ | Auto Provisioning | پیداکردن Configuration بازنویسیشونده |
| ۱۲ | Firmware | بررسی نسخه Global یا Provider |
| ۱۳ | Browser | حذف Cache، Proxy و Extension |
| ۱۴ | Factory Reset | فقط پس از حذف علتهای قبلی |
پرسشهای متداول درباره باز نشدن پنل وب Yealink
چرا Yealink IP دارد ولی پنل وب باز نمیشود؟
گرفتن IP فقط سالمبودن DHCP را نشان میدهد. HTTP یا HTTPS ممکن است غیرفعال باشد، Port تغییر کرده باشد، Firewall یا ACL دسترسی را بسته باشد یا Browser در مرحله TLS و Certificate متوقف شده باشد.
برای ورود به پنل Yealink از HTTP استفاده کنم یا HTTPS؟
ابتدا HTTPS با IP مستقیم تلفن را امتحان کنید. رفتار HTTP و HTTPS میتواند با مدل و Firmware متفاوت باشد و Administrator نیز میتواند یکی از آنها را غیرفعال یا Port را تغییر دهد.
چرا Ping تلفن جواب میدهد ولی صفحه وب باز نمیشود؟
Ping از ICMP استفاده میکند ولی Web UI روی TCP کار میکند. Firewall میتواند ICMP را مجاز و TCP/443 را مسدود کرده باشد. Port را جداگانه تست کنید.
هشدار Certificate در HTTPS یعنی پنل خراب است؟
خیر. اگر Browser Certificate Warning نشان میدهد، معمولاً HTTPS Server تا مرحله TLS پاسخ داده است. باید تفاوت هشدار Trust با شکست کامل TLS را در نظر گرفت.
چطور بفهمیم Port 443 Yealink باز است؟
در Windows میتوانید از Test-NetConnection و در Linux یا macOS از ابزارهایی مثل curl یا nc استفاده کنید. اگر TCP Connection برقرار باشد، مسیر شبکه تا HTTPS Port قابل دسترس است.
چرا پنل روی همان VLAN باز میشود ولی از VLAN مدیریت نه؟
این الگو معمولاً به Routing، ACL یا Firewall بین Voice VLAN و Management VLAN اشاره میکند. Web Server خود تلفن احتمالاً سالم است.
چرا بعد از Reboot دوباره Web UI بسته میشود؟
Auto Provisioning ممکن است هنگام Boot تنظیم HTTP/HTTPS یا Port را دوباره اعمال کند. Common CFG، MAC CFG و سیستم Device Management را بررسی کنید.
آیا Firmware اپراتوری میتواند پنل Yealink را محدود کند؟
بله. Yealink نیز اشاره میکند برخی Firmwareهای غیرGlobal ممکن است روش ورود یا دسترسی متفاوتی داشته باشند. در تلفن Provider-managed قبل از تغییر Firmware با سرویسدهنده هماهنگ کنید.
آیا Factory Reset اولین راهحل است؟
خیر. ابتدا IP، VLAN، Port، HTTPS، ACL، Provisioning و Firmware را بررسی کنید. Factory Reset ممکن است تنظیمات SIP و Provisioning را نیز پاک کند.
جمعبندی
وقتی Yealink IP میگیرد اما پنل وب آن باز نمیشود، اول مشخص کنید مشکل در کدام لایه قرار دارد. IP را از خود تلفن بگیرید، Ping کنید و بعد TCP/443 را مستقل از Browser آزمایش کنید. اگر Port بسته است، Web Server، Port سفارشی، ACL و Firewall را بررسی کنید.
اگر 443 باز است اما Browser صفحه را نشان نمیدهد، HTTPS، Certificate، Browser Cache و Proxy یا TLS Inspection را بررسی کنید. Certificate Warning بهتنهایی به معنی Down بودن Web Server نیست.
در شبکههای دارای Voice VLAN، دسترسی Management را نیز جداگانه بررسی کنید؛ ممکن است تماس و SIP کاملاً سالم باشند اما Firewall فقط Web Management را بین VLANها بسته باشد.
در نهایت اگر تنظیم Web Server بعد از هر Reboot تغییر میکند، Auto Provisioning و Firmware سفارشی Provider را بررسی کنید. Factory Reset را فقط زمانی انجام دهید که مطمئن شدهاید Configuration مرکزی دوباره همان مشکل را روی دستگاه اعمال نمیکند.
برای بررسی شبکه و تنظیمات Web Management کمک میخواهید؟
اگر تلفنهای Yealink روی شبکه فعال هستند اما پنل مدیریتی باز نمیشود، میتوانید درخواست بررسی کانفیگ ثبت کنید تا HTTPS، VLAN، ACL، Firewall و تنظیمات مدیریتی دستگاه متناسب با همان مشکل بررسی شوند.
تماس با پشتیبانی ایرانیکاسرور






دیدگاهها (۰)