Dsn первичный и вторичный что делать

Устранение неполадок с DNS-серверами

Попробуйте наш виртуальный агент . Это поможет вам быстро определить и устранить распространенные проблемы с DNS.

В этой статье описывается устранение неполадок на DNS-серверах.

Проверка конфигурации IP-адресов

Запустите ipconfig /all в командной строке и проверьте IP-адрес, маску подсети и шлюз по умолчанию.
Проверьте, является ли DNS-сервер доверенным для имени, которое ищется. Если да, ознакомьтесь с проверкой проблем с авторитетными данными.
Выполните следующую команду:

nslookup

nslookup app1 10.0.0.1

dnscmd /clearcache

Или в окне администрирования PowerShell выполните следующий командлет:

Clear-DnsServerCache

Проверка проблем с DNS-сервером

Журнал событий

Проверьте следующие журналы, чтобы узнать, есть ли какие-либо записанные ошибки:

Приложение
Система
DNS-сервер

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверка, доступен ли DNS-сервер с клиентских компьютеров.

nslookup

Если сопоставитель возвращает IP-адрес клиента, сервер не имеет проблем.
Если сопоставитель возвращает ответ «Сбой сервера» или «Отказ в запросе», зона, вероятно, приостановлена или возможно, сервер перегружен. Вы можете узнать, приостановлена ли зона, проверив вкладку «Общие» свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ «Время ожидания запроса на сервер» или «Нет ответа от сервера», служба DNS, вероятно, не выполняется. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

net start DNS

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, используемый в запросе nslookup. На вкладке «Интерфейсы» страницы свойств сервера в консоли DNS администраторы могут ограничить DNS-сервер прослушивать только выбранные адреса. Если DNS-сервер настроен, чтобы ограничить службу определенным списком настроенных IP-адресов, возможно, IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Вы можете попробовать другой IP-адрес в списке или добавить IP-адрес в список.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер находится в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию nslookup отправляет запросы на DNS-серверы на порте UDP 53. Таким образом, если DNS-сервер использует любой другой порт, запросы nslookup завершаются ошибкой. Если вы считаете, что это может быть проблема, проверка, используется ли промежуточный фильтр намеренно для блокировки трафика на известных DNS-портах. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через UDP/TCP-порт 53.

Проверка проблем с достоверными данными

Проверьте, является ли сервер, возвращающий неправильный ответ, основным сервером зоны (стандартным первичным сервером для зоны или сервера, использующего интеграцию Active Directory для загрузки зоны) или сервером, на котором размещена вторичная копия зоны.

Если сервер является основным сервером

Проблема может быть вызвана ошибкой пользователя при вводе данных в зону. Или это может быть вызвано проблемой, которая влияет на реплика Active Directory или динамическое обновление.

Если сервер размещает вторичную копию зоны

Проверьте зону на основном сервере (сервер, с которого этот сервер извлекает передачу зоны).

Примечание. Вы можете определить, какой сервер является основным сервером, проверив свойства вторичной зоны в консоли DNS.

dnscmd /zonerefresh

Проверка проблем рекурсии

Для успешной работы рекурсии все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность реагировать и пересылать правильные данные. Если они не могут, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:

Время ожидания запроса истекает до того, как запрос будет выполнен.
Сервер, используемый во время запроса, не отвечает.
Сервер, используемый во время запроса, предоставляет неверные данные.

Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы на другой сервер, проверив вкладку «Пересылка» в свойствах сервера в консоли DNS. Если выбрано поле «Включить пересылки» проверка, а один или несколько серверов перечислены, этот сервер перенаправит запросы.

Если этот сервер пересылает запросы на другой сервер, проверка для проблем, влияющих на сервер, на который этот сервер перенаправит запросы. Сведения о проверка проблем см. в разделе «Проверка проблем DNS-сервера». Когда в этом разделе показано, как выполнить задачу на клиенте, выполните ее на сервере.

Если сервер работоспособен и может пересылать запросы, повторите этот шаг и проверьте сервер, на который этот сервер перенаправит запросы.

Если этот сервер не перенаправит запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:

nslookup server set q=NS

Если сопоставитель возвращает IP-адрес корневого сервера, возможно, у вас есть сломанное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Выполните проверку процедуры сломанной делегирования, чтобы определить, где у вас неработает делегирование.
Если сопоставитель возвращает ответ «Время ожидания запроса на сервер истекло», проверка указывает, указывают ли корневые подсказки на функционирование корневых серверов. Для этого используйте процедуру просмотра текущих корневых подсказок . Если корневые подсказки указывают на функционирование корневых серверов, у вас может возникнуть проблема с сетью, или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет сопоставителям запрашивать сервер, как описано в разделе «Проверка проблем DNS-сервера». Также возможно, что рекурсивное время ожидания по умолчанию слишком короткое.

Проверка неработаемого делегирования

Запустите тесты в следующей процедуре, запросив допустимый корневой сервер. Тест проходит через процесс запроса всех DNS-серверов из корневого каталога на сервер, который вы тестируете для неисправного делегирования.

nslookup server set norecursion set querytype=

Примечание. Тип записи ресурсов — это тип записи ресурсов, которую вы запрашивали в исходном запросе, а полное доменное имя — полное доменное имя, для которого вы запрашивали (завершались на период).

Если ответ не содержит запись ресурса NS, у вас неработает делегирование.
Если ответ содержит записи ресурсов NS, но нет записей ресурсов «A», введите рекурсию и запрос по отдельности для записей ресурсов «A», перечисленных в записях NS. Если у вас нет хотя бы одного допустимого IP-адреса записи ресурса «A» для каждой записи ресурсов NS в зоне, у вас неработает делегирование.

Просмотр текущих корневых подсказок

Запустите консоль DNS.
Добавьте или подключитесь к DNS-серверу, который завершился сбоем рекурсивного запроса.
Щелкните правой кнопкой мыши сервер и выберите пункт «Свойства«.
Щелкните корневые подсказки.

Проверьте базовое подключение к корневым серверам.

Если корневые подсказки настроены правильно, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибкой, может проверять связь корневых серверов по IP-адресу.
Если корневые серверы не отвечают на связь по IP-адресу, ip-адреса для корневых серверов могут измениться. Однако это редко, чтобы увидеть перенастройку корневых серверов.

Проблемы с передачей зоны

Выполните следующие проверка:

Проверьте Просмотр событий для основного и дополнительного DNS-сервера.
Проверьте первичный сервер, чтобы узнать, отказывается ли он отправлять передачу для обеспечения безопасности.
Перейдите на вкладку «Передача зоны» свойств зоны в консоли DNS. Если сервер ограничивает передачу зоны в список серверов, например перечисленных на вкладке «Серверы имен» свойств зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен для отправки передачи зоны.
Проверьте сервер-источник для проблем, выполнив действия, описанные в разделе «Проверка проблем DNS-сервера». Когда вам будет предложено выполнить задачу на клиенте, выполните задачу на сервере-получателе.
Проверьте, выполняется ли дополнительный сервер другой реализации DNS-сервера, например BIND. Если это так, проблема может иметь одну из следующих причин:
- Основной сервер Windows может быть настроен для отправки быстрых передач зоны, но сторонний сервер-получатель может не поддерживать передачу быстрой зоны. Если это так, отключите быструю передачу между зонами на основном сервере в консоли DNS, выбрав поле «Включить привязку вторичных файлов» проверка на вкладке «Дополнительно» свойств сервера.
- Если зона подстановки вперед на сервере Windows содержит тип записи (например, запись SRV), которую дополнительный сервер не поддерживает, вторичный сервер может столкнуться с проблемами с извлечением зоны.
Проверьте, работает ли основной сервер другой реализации DNS-сервера, например BIND. В таком случае возможно, что зона на основном сервере содержит несовместимые записи ресурсов, которые Windows не распознает.

Если главный или вторичный сервер выполняет другую реализацию DNS-сервера, проверка обоих серверах, чтобы убедиться, что они поддерживают одни и те же функции. Вы можете проверка сервер Windows в консоли DNS на вкладке «Дополнительно» страницы свойств сервера. Помимо поля «Включить привязку» на этой странице содержится раскрывающийся список «Имя проверка». Это позволяет выбрать строгое соответствие RFC для символов в DNS-именах.

Установка и настройка DNS-сервера

ISPmanager работает с реализациями DNS-сервера: BIND (Berkeley Internet Name Domain) и PowerDNS. Они обеспечивают преобразование DNS-имени в IP-адрес и наоборот. Основное преимущество BIND в том, что он реализован в полном соответствии с официальной документацией, которая регламентирует работу DNS-сервера. Согласно этому документу DNS-сервер хранит сведения о доменных зонах в виде файлов. PowerDNS по скорости работы превосходит BIND, т. к. сведения о доменных зонах хранит в базе данных. Поэтому если планируете работать с большим количеством IP-адресов в ISPmanager, то рекомендуем использовать PowerDNS.

ISPmanager выступает в роли первичного (master) DNS-сервера. Первичный DNS-сервер хранит главную копию файла доменной зоны, которую сопровождает администратор системы. Информацию о доменной зоне первичный сервер получает из её конфигурационных файлов зоны. Вторичные серверы (slave) получают настройки доменной зоны с первичного сервера.

Настройки DNS-сервера записываются в его конфигурационный файл. Используются при создании доменных зон. Подробнее см. в статье Создание доменного имени.

Установка сервера доменных имён

Чтобы установить сервер доменных имён:
1. Перейдите в Настройки → Возможности → выберите Сервер имён (DNS) → Изменить.
2. Выберите нужный DNS-сервер.
3. Нажмите Применить изменения и дождитесь окончания установки.
Настройка сервера доменных имён

Чтобы настроить DNS-сервер:
1. Перейдите в Домены → Доменные имена → Настройки.
2. Укажите Серверы имён, которые управляют создаваемыми доменными зонами. Указываются в ресурсных NS-записях создаваемых доменных зон.
3. Укажите Email администратора DNS. Указывается в ресурсной SOA-записи создаваемых доменных зон. Подробнее о доменных зонах и ресурсных записях см. в статье Создание ресурсных записей доменной зоны.
4. Укажите Запись DMARC — шаблон, в соответствии с которым создаётся ресурсная TXT-запись доменной зоны. Используется для настройки механизма DMARC. Этот механизм задаёт политику проверки входящей почты в домене.
5. Укажите Запись SPF — шаблон, в соответствии с которым создаётся ресурсная TXT-запись доменной зоны. Используется для настройки механизма SPF. Этот механизм задаёт политику проверки входящей почты в домене. Используйте в шаблоне макрос «_ip_» для подставления IP-адресов. Адреса указываются в параметре SPFRelayIP конфигурационного файла ISPmanager (по умолчанию /usr/local/mgr5/etc/ispmgr.conf) через пробел. Подробнее см. в статье Конфигурационный файл ISPmanager.
6. Укажите Поддомены, которые будут автоматически создаваться при создании домена. Указываются в ресурсных A-записях создаваемых доменных зон.
7. Укажите Почтовые серверы, на которые будет поступать электронная почта домена. Указываются в ресурсных MX-записях создаваемых доменных зон. Если указываете полное доменное имя, поставьте точку «.» на конце (например, «mail1.mydomain.com.» «mail2.mydomain.com.»). Если указываете запись в текущем домене, точку ставить не нужно (например «mail» «mail»).
8. Если NS-запись лежит в пределах создаваемой доменной зоны, для NS-серверов автоматически создаются ресурсные A и AAAA записи. Укажите IP-адреса для серверов имён, которые будут использоваться при создании записей. Если поле не указано, то для первой NS-записи используется IP-адрес первичной доменной зоны, а для всех остальных — адрес вторичной. Если вторичные серверы имён не настроены или указано недостаточное количество IP-адресов, будет получена ошибка.
9. При создании домена в ресурсной SOA-записи доменной зоны в качестве первичного DNS-сервера (master) указывается сервер с ISPmanager. Чтобы изменить значение по умолчанию, укажите Имя сервера для SOA-записей.
10. Если нужно применить изменения настроек к уже созданным доменным зонам, включите опцию Применить к существующим.
11. Нажмите Ok.
Поддержка технологии DNSSEC

Чтобы настроить DNSSEC:
1. Перейдите в Домены → Доменные имена → Настройки.
2. Включите опцию Поддержка DNSSEC.
3. Укажите настройки ключей. DNSSEC использует 2 типа ключей: ZSK и KSK. ZSK (Zone Signing Key) — ключ для подписи ресурсных записей доменной зоны. KSK (Key Signing Key) — ключ для подписи ключей. Укажите параметры каждого типа ключа. Они будут учитываться при генерации новых ключей:
  1. Алгоритм — метод генерации ключей. Устаревшие алгоритмы: «5 — RSA/SHA-1», «7 — RSASHA1-NSEC3-SHA1». Современные алгоритмы: «8 — RSA/SHA-256», «10 — RSA/SHA-512». Новейшие алгоритмы: «13 — ECDSA Curve P-256 with SHA-256», «14 — ECDSA Curve P-384 with SHA-384».
  2. Длина ключа — указывается в битах.
  3. Период обновления, по истечении которого будет сгенерирован новый ключ. Указывается в месяцах.
  Обратите внимание!
  
  Текущая реализация поддержки DNSSEC позволяет указать только одинаковый алгоритм для всех типов ключей.
  
  Подробнее о технологии см. в статье Настройка DNSSEC.
  
  Первичный и вторичные DNS
  
  Протоколы DNS являются частью основных стандартов Интернета. Они определяют процесс, при котором один компьютер может найти другой компьютер на основе его имени. Реализация протоколов DNS означает, что сервер содержит все программное обеспечение, необходимое для создания запросов и ответов службы доменных имен.
  
  Минимальные требования сохранения данных требуют для каждой доменной зоны, не менее двух DNS серверов. Первый сервер DNS называют первичный, он же primary, а по- новому master . Остальные сервера, а их может быть минимум один, а максимум 12, называют вторичные сервера DNS, или иначе secondary , по- новому, slave . По-новому, это начиная с DNS Bind 8-ой версии.
  
  Примечание: BIND это программа для реализации протоколов системы доменных имен (DNS). Название BIND расшифровывается как “Berkeley Internet Name Domain”, так как программное обеспечение возникла в начале 1980-х годов в университете Калифорнии в Беркли. В последние годы слово BIND стала больше, чем аббревиатура.
  - Первичный и вторичные DNS не обязательно должны находиться на домене, за который отвечают.
  - Первичный и вторичные DNS оба являются авторитативными серверами.
  Первичный и вторичный DNS
  
  Первичный (primary, master) сервер DNS
  
  Master сервер DNS хранит полную, оригинальную базу данных своей доменной зоны. Данные хранятся в файлах.
  
  При запросе к первичному серверу DNS, он дает авторитативный ответ, благодаря которому по домену находится IP ресурса.
  
  Важно понимать, что только на master сервере можно вносить изменения в базу данных DNS. Повторюсь, только на первичном сервере DNS, хранится база данных доменных имен прикрепленной к серверу доменной зоны этого DNS.
  
  Вторичные (secondary, slave) сервера DNS
  
  Как я уже упомянул, для каждой доменной зоны должно быть создано или прикреплено минимум два сервера DNS. Именно минимум. Число вторичных серверов может быть до 12. В большинстве своем, такое количество вторичных серверов это перебор. Как правило, с запасом, достаточно трех вторичных DNS. Да вы и сами видели, что у любого регистратора доменных имен, не больше четырех полей для ввода адресов DNS серверов. Один для первичного сервера, три – для вторичных.
  
  На вторичных DNS серверах база данных имен не храниться, она периодически считывается с первичного сервера, естественно по сети. Периодичность считывания, определяется в записи DNS типа SOA (параметр Refresh, в секундах). Обычно, 3600 секунд, то есть информация на вторичном сервере обновляется каждый час.
  
  Обращу внимание, что считывать данные любой вторичный сервер может не только с первичного сервера, но и любого вторичного. В этом случае, этот сервер с которого считывается информация, будет master сервером для вторичного сервера.
  
  Как лучше разместить первичный и вторичные DNS
  
  Нужно понимать, если DNS сервер «падает», то все сайты, находящиеся в доменной зоне этого DNS падают тоже. Если падает первичный сервер, отвечать на запросы начинают последовательно вторичные DNS сервера. А вот тут и проблема, если все DNS сервера лежат в одной сети, то при падении этой сети, падают все DNS. Отсюда простой вывод, «не нужно хранить все яйца в одной корзине» или в нашем случае, нужно разнесите DNS сервера по разным хостам, а еще лучше по разным территориальным зонам.
  
  Например, хостинг – провайдер предоставил вам два сервера DNS для вашего домена. Правильнее наоборот, он включил ваш домен в доменную зону своих DNS серверов. Найдите в Интернет, сервер вторичных DNS (платный или бесплатный) и дополните свои первичный и вторичный сервера, сторонними DNS серверами. Тем самым, вы обезопасите свой ресурс на случай падения DNS серверов провайдера.
  
  С хотингами могут быть проблемы с добавлением сторонних DNS серверов. У каждого провайдера, своя «песочница» и он устанавливает свои правила. Некоторые хостинги ограничивают клиентов, только своими DNS. Другое дело если у вас, сервер VPS/VDS. Здесь вы полный хозяин и можете сами создавать DNS сервера на своем домене. И опять-таки, на VPS создайте два своих DNS сервера и дополните их двумя сторонними, и лучше разными, DNS серверами.
  
  Где необходимо регистрировать DNS сервера
  
  DNS сервера должны быть прописаны (зарегистрированы) на вашем хостинге или сервере и у регистратора доменных имен. На сервере вторичных доменных имен вы регистрируете только свой домен и берете их вторичные DNS. Независимо от места прикрепления, ваш домен и ваши DNS сервера должны быть зарегистрированы, а, следовательно, связаны:
  - У регистратора имен;
  - На вашем хостинге или сервере (раздел сервера DNS, управление DNS);
  - На сервере вторичных DNS (если используете).
  Выводы
  - Для работы сайта, его домен должен попадать в доменные зоны, которые обслуживают, первичный и вторичные DNS сервера;
  - DNS серверов должно быть, как минимум два. Один первичный и один вторичный DNS. Для более надежной работы сайта, дополните два DNS сервера, еще двумя дополнительными вторичными серверами. Желательно третий и четвертый DNS сервера взять на разных хостингах.
  Сервера вторичных DNS
  
  Приведу несколько серверов, где можно взять вторичные DNS.
  - 2DNSinfo.ru (бесплатно);
  - www.mgnhost.ru/DNS-hosting.php (600 рублей в год за 100 зон);
  - http://toobit.ru/hosting/secondary_name_server.php (100 Slave DNS за 1$ в мес.);
  При аренде сторонних первичных, да и вторичных DNS серверов, с осторожностью относитесь к импортным DNS хостингам. Попробуйте проверить время их отклика на запрос, для этого есть масса online сервисов. Нормальное время ответа на запрос DNS должен быт от 20 до 120 ms. Хоть у импортных хостингов и сервера разбросаны по всему миру, но, к сожалению, этот мир может быть настолько далеко от вас, что время отклика достигает 800-4000 ms. А это не хорошо.
  
  Как проверить DNS сервера сайта
  
  Для проверки своих и чужих DNS воспользуйтесь любым сервисом Whois – сервиса проверки доменных имен. При проверке не забывайте, что при смене DNS кэширующий сервер очищается каждые 24-72 часа.
  
  Другие статьи раздела: Хостинг для WordPress
  - Практичные SQL запросы к базе данных WordPress
  - Как работает система DNS
  - NS сервера CloudFlare – отличный выбор для сайта WordPress
  - Хостинг и сайт WordPress: выбор хостинга для сайта
  - Перенос сайта WordPress на другой хостинг
  Похожие посты:
  - Облачные DNS сервера
  - DNS записи – NS, CNAME, TXT, A, AAAA
  - Как проверить доменное имя
  - Как работает система DNS
  - Домен для WordPress сайта
  - Перенести бесплатный сайт WordPress.com на коммерческий хостинг
  - Как настроить DNS сервера на VDS, VPS сервере
  - Влияние домена на продвижение сайта: как выбрать SEO домен
  - Самый быстрый хостинг для WordPress – 5 лучших провайдера вебхостинга
  Что делать, если мой маршрутизатор TP-Link получил сетевой IP-адрес, но доступ в Интернет отсутствует? (Для DSL или кабельного широкополосного подключения)
  
  Дата последнего обновления: 03-24-2016 15:09:35 PM 580228
  
  Эта статья подходит для:
  
  TL-WR841ND , TL-WR842ND , TL-WR843ND , Archer C5( V1.20 ) , Archer C2( V1 ) , TL-R860 , TL-R460 , Archer C50( V1 ) , TL-WDR3500 , TL-WR720N , TL-WR841N , TL-WDR3600 , TL-WR710N , TL-WR740N , Archer C20i , TL-WR741ND , TL-WR940N , TL-WR743ND , TL-WR1043ND , Archer C7( V1 V2 V3 ) , TL-WR1042ND , TL-WR542G , TL-WR702N , TL-WR700N , TL-WR843N , TL-WR340G , TL-WDR4300 , TL-WR340GD , Archer C20( V1 ) , TL-MR3220 , TL-WR842N , TL-WR2543ND , TL-MR3020 , TL-WR840N , TL-MR3040 , TL-WR841HP , TL-R402M , TL-WDR4900 , TL-WR941ND , TL-WR543G , TL-WR541G , TL-WR802N , TL-WR810N , TL-MR3420
  
  Если вашей модели нет в списке, не переживайте — возможно, её ещё просто не успели добавить. Чтобы точно убедиться в наличии или отсутствии той или иной функции, откройте продуктовую страницу интересующей вас модели и перейдите в раздел «Характеристики».
  
  Чтобы узнать сетевой IP-адрес маршрутизатора:
  
  Шаг 1. Подключите компьютер к маршрутизатору с помощью кабеля Ethernet.
  
  Шаг 2. Войдите в веб-утилиту настройки маршрутизатора через веб-браузер (Internet Explorer, Chrome, Mozilla или Safari). По умолчанию имя пользователя и пароль — “ admin ”.
  
  Примечание : Адрес может отличаться в зависимости от модели маршрутизатора. Проверьте правильность адреса на этикетке на задней/нижней панели маршрутизатора.
  
  Шаг 3. После входа в веб-утилиту в меню слева выберите Status (Состояние) .
  
  Если в разделе WAN в меню Status в полях IP Address/Subnet Mask/Default Gateway/DNS Server ( IP-адрес/Маска подсети/Шлюз по умолчанию/DNS сервер ) отображены цифры (не все «0») , однако доступ к сети Интернет все еще отсутствует, выполните следующие действия.
  
  При наличии вышеописанной проблемы, выполните следующие шаги.
  
  Шаг 1. Введите адрес DNS-сервера:
  Перейдите в DHCP > DHCP settings (DHCP > Настройки DHCP), затем введите 8.8.8.8 в поле Primary DNS (Предпочитаемый DNS-сервер), нажмите Save (Сохранить).
  
  8.8.8.8 – это бесплатный и безопасный общедоступный DNS-сервер, предоставляемый Google. Для получения дополнительной информации нажмите здесь.
  
  Шаг 2. Перезагрузите маршрутизатор для завершения настроек
  
  Перейдите System Tools > Reboot (Системные инструменты > Перезагрузка), нажмите кнопку “Reboot” (Перезагрузка), чтобы завершить настройку.
  
  Шаг 3. Подождите 1-2 минуты, после чего проверьте наличие доступа в Интернет.
  
  Если вам необходима помощь в решении проблемы, свяжитесь со Службой технической поддержки TP-Link, отправив нам запрос на адрес support.ru@tp-link.com.
  
  Был ли этот FAQ полезен?
  
  Ваш отзыв поможет нам улучшить работу сайта.
  
  Что вам не понравилось в этой статье?
  - Недоволен продуктом
  - Слишком сложно
  - Неверный заголовок
  - Не относится к моей проблеме
  - Слишком туманное объяснение
  - Другое
  Как мы можем это улучшить?
  
  Спасибо
  
  Спасибо за обращение
  Нажмите здесь, чтобы связаться с технической поддержкой TP-Link.
  Похожие публикации: