Не пингуется dns адрес no ip

Обновлено: 03.07.2024

При настройке VPN не работает DNS (В смысле сайты грузятся по айпишникам, а по именам не хотят)

Для новичков как вообще в Linux, так и в конкретной теме, к которой относится вопрос.

Модератор: Bizdelnick

При настройке VPN не работает DNS

После всей процедуры было замечено две проблемы:
1. Несмотря на то что адрес DNS прописан в таблице, имена не пингуются. Пингуются только IP-адреса.
2. Добавление в файле /etc/ppp/peers/svitonline строчки defaultroute не привело к автоматическому добавлению маршрута по-умолчанию. Приходится пока-что добавлять ручками.
Почему так? Где-то есть ошибка или что-то не учтено в настройках?
Заранее благодарен полезным советам и наставлениям

вывод
$ ip a; ip n
до и после подключения.
при подключении добавьте pppd-емону опции debug nodetach dump hide-password
и вывод pppd тоже приложите сюда. Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог вывод
$ ip a; ip n
до и после подключения.
при подключении добавьте pppd-емону опции debug nodetach dump hide-password
и вывод pppd тоже приложите сюда.

пардон, опечатался. не «ip n», а «ip r».
а Вы упустили опцию dump

на основании имеющейся информации могу порекомендовать добавить в /etc/ppp/peers/svitonline опции

если вопрос не решится, выложите снова вывод
$ ip a; ip r
до и после подключения.
и вывод
$ pppd call svitonline debug nodetach dump hide-password Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог

Привет!
Попробовал добавлять
usepeerdns
replacedefaultroute

Вот результаты:
После добавления команды usepeerdns интернет заработал, причем на полной скорости, правда работает некоторое время (по разному, бывает 10 минут, бывает час) потом сайты перестают загружаться, при этом pppd продолжает работать. После перезагрузки pppd интернет снова восстанавливается.
Замечена особенность: задержка выполнения скрипта /etc/ppp/ip-up секунд 15 - 20 (раньше такого небыло, наверное связано с DNS).
replacedefaultroute ничего не дает, маршрут по-умолчанию задаю вручную или в скрипте /etc/ppp/ip-up строчкой route add default dev ppp0

Когда инет слетит опять, проверю как пингуются сервера, дабы выяснить - проблема опять с DNS или что-то другое. Ну и логи пинга тоже выложу.

Содержание:

Сравнение бесплатных аккаунтов no-ip и dyndns

Переадресация 80-го порта. Будет полезна тем, кто настроил свой веб-сервер на нестандартный порт. Избавляет от необходимости прописывать номер порта в адресной строке браузера.
TTL равное 4 часа. Подойдет тем, у кого адрес меняется относительно редко (компьютер, маршрутизатор работает целый день или дольше). В этом случае скорость доступа будет выше, т.к. будут задействованы механизмы кеширования DNS.

Теперь перейдем к регистрации на сайте.

Заполняем форму регистрации:

Обязательно требуется заполнить все поля кроме Zip/Postal Code.

После нажатия на кнопку I Accept, Create my Account на ваш адрес будет отправлено письмо с ссылкой для активации акаунта. После активации вновь заходим на сайт и вводим свой логин / пароль. После входа в акаунт переходим в раздел Add a Host:

Переходим в раздел Add a Host

и переходим к настройкам хоста:

Настройка хоста

Теперь осталось настроить маршрутизатор или установить клиент DDNS непосредственно на компьютер.

Установка клиента No-IP DUC

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

Запускаем установщик. Все стандартно: выбираем расположение, отмечаем опцию Launch No-IP DUC (для запуска апдейтера сразу после завершения установки).

Установка No-IP DUC

Переходим к настройке.

Настройка No-IP DUC (1)

Для обновления dns необходимо поставить галочки напротив нужных вам хостов (доменов). Процесс обновления начинается сразу после установки галочки (никаких дополнительных кнопок нажимать не надо). Под списком хостов программа выводит ip-адрес, используемый для обновления (на скриншоте выделено красным).

Для доступа к дополнительным настройкам нажмите кнопку Options.

Закладка Standard. Здесь четыре опции:

Обычным пользователям рекомендую отметить опции Run on startup и Run as system service, чтобы быть уверенными, что клиент всегда загрузиться вместе с системой.

Закладка Connection. Подзакладка Standard. Здесь три опции:

Override automatic connection detection и Override automatic ip detection. Эти опции полезны пользователям у которых несколько сетевых карт и при этом несколько активных подключений. Например подключены по локальной сети и одновременно по wi-fi. Первая опция позволяет вручную определить интерфейс, через который будет осуществляться подключение к серверу no-ip. Вторая опция позволяет вручную определить интерфейс, через который бдет определяться ваш внешний ip-адрес.
Третья опция позволяет изменить частоту с которой клиент проверяет изменения внешнего ip-адреса. По-умолчанию этот интервал равен 30 минутам. Менять эту опцию советую только, если ваш ip меняется очень часто (уменьшить интервал до 5-10 минут).

Закладка Connection. Подзакладка Proxy.

Если подключение к интернет осуществляется через proxy-сервер, то здесь вы можете определить параметры подключения к нему.

Настройка No-IP DUC (4). Закладка Connection/Proxy

Обычно proxy-сервера в домашних сетях почти не встречаются, так что для обычных пользователей эта закладка интереса не представляет. То же можно сказать и про закладки Scheduling/Autodial и Other, их описание я опущу.

Настройка маршрутизатора (D-link DI-804) для работы с DDNS
Настройка очень проста (на других маршрутизаторах с поддержкой DDNS выполняется аналогично).
Переходим в раздел настройки DDNS.

Настройка DDNS в D-link DI-804

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

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

Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.

Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.

Выполните следующую команду.

Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.

Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:

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

Повторите шаг 3.

Проверка неполадок DNS-сервера

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

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

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

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

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.

Если сопоставитель возвращает ответ "сбой сервера" или "Запрос отклонен", зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера" или "нет ответа от сервера", возможно, служба DNS не запущена. Попробуйте перезапустить службу 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.

Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.

Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.

На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:

Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.

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

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

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

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

Сервер, используемый во время запроса, не отвечает.

Сервер, используемый во время запроса, предоставляет неверные данные.

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

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

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

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

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

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

Тестирование неработающего делегирования

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

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

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

Если ответ содержит список записей ресурсов "NS" и "A" для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов "A" в качестве IP-адреса сервера.

Если ответ не содержит запись ресурса NS, делегирование будет разорвано.

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

Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.

Просмотр текущих корневых ссылок

Запустите консоль DNS.

Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.

Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.

Щелкните корневые ссылки.

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

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

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

Проблемы с зонными ошибками

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

Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.

Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.

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

Проверьте наличие проблем на основном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера . Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.

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

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

если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.

Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.

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

Доступ к локальной сети из Интернет - DDNS на примере no-ip

Я, скорее, параноик и до сего момента держу закрытым весь доступ в локалку из Сети. Хотя, с другой стороны, полную гарантию не даёт даже физическое отключение тк остаются сменные носители. А уж если работает transmission, bttorrentsync и пр. В общем, придумалось несколько приложений, требующих доступа извне в локалку - owncloud, удалённый backup по интернет и пр. Начнём с DDNS

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

Начнем с упрощенной теории. В глобальной сети право использовать IPv4 адрес (например 95.24.156.147) можно получить от полномочной организации, IANA. Адресов всего 2^32 (

4 млрд), часть отдана под специальные цели - на всех не хватает. Отчасти поэтому в изолированной домашней сети используются обычно адреса вида 192.168.0.0/16, во всех таких сетях одинаковые. Это позволяет экономить адресное пространство. Но в результате внутри домашней сети и снаружи адреса - разные. Внешний адрес ваша сеть получает один, от провайдера (которому вы платите за интернет). И его выдают в аренду на некоторое время, и могут в любой момент изменить. Поэтому достучаться до вашей домашней сети по IP несколько затруднительно. Есть два основных способа - арендовать у провайдера постоянный (статический адрес). Например, у моего провайдера это стоит 130 руб/мес. Так и стоит сделать, если у вас важные приложения, типа клиент-банк, т.к. статический адрес положительно сказывается на безопасности. Но в большинстве случаев проще второй способ - DDNS.

Хорошая новость в том, что в простейшем, годном для дома, варианте услуги DDNS можно найти бесплатные. Выбор провайдера DDNS - тема длинная, начните со списка, который поддерживает ваш роутер. Погуглите ваш, многие роутеры это умеют. Если не умеет - nas4free может взять эту роль на себя, Services|Dynamic DNS (я не настраивал, но там всё аналогично). Мой роутер, например, предлагает следующее

Как видно, я выбрал no-ip. Просто потому, что работает. Его и настроим.

2) Заходим, попадаем в графическое меню

Выбираем "Add Host"

3) Попадаем в диалог ниже (в него же можно попасть через меню - Add Host)

Полей очень много, внизу ещё есть. Но заполнить в простейшем случае надо только два
Hostname - выберите что-то вместо vasia_pupkin
И из длинного списка правее надо выбрать домен второго уровня. no-ip.info годится для бесплатного сервиса. Большинство остальных предложены для возможности попросить у вас денег.
IP address заполнять не надо - система определяет его сама. Но если заполните - ничего не изменится.
Жмём внизу оранжевую кнопку Add Host - готово
Прим - функциональность сервиса шире - может потом пригодиться.

4. теперь осталось настроить роутер (или NAS) стучаться на no-ip и сообщать о своём адресе. На примере моего роутера, у вас (и в nas4free) всё аналогично.

Идём по галочкам - включаем DDNS сервис, выбираем провайдера no-ip из списка, сообщаем имя созданного хоста, логин и пароль для подключения к no-ip, применяем.

5. Проверка связи. Осталось проверить. Естественный порыв - набрать vasia_pupkin.no-ip.info в адресной строке браузера (сделайте это)
Упс! Нам предлагают войти в вебгуй роутера! Это что же, теперь любой кулхацхер будет ко мне в гости ходить как к себе домой.
Ответ - и да и нет. То есть роботы будут ломится и, если вы позже откроете канал, могут подобрать, а то и подслушать пароли.
Нет, потому, что пока вы ничего не открыли. Вы просто привели знающих ваше доменноеё имя vasia_pupkin.no-ip.info к закрытой снаружи двери роутера. Между прочим - причина не светить понапрасну выбранное вами доменное имя.

А вы видите приглашение ввести логин-пароль роутера потому, что к той же двери вы подошли ИЗНУТРИ, из доверенной зоны.
В работоспособности можно убедиться, пинганув ваш домен из командной строки
ping vasia_pupkin.no-ip.info
Если работает, вы получите что-то вроде
PING vasia_pupkin.no-ip.info (96.28.157.147) from 192.168.1.34: 56 data bytes
64 bytes from 95.27.155.134: icmp_seq=0 ttl=64 time=0.283 ms
64 bytes from 95.27.155.134: icmp_seq=1 ttl=64 time=0.292 ms
64 bytes from 95.27.155.134: icmp_seq=2 ttl=64 time=0.198 ms

Здесь видно, что (1) имя (vasia_pupkin.no-ip.info) ресолвится во внешний IP (96.28.157.147) - значит, сервис работает и
(2) что время прохождения очень мало, доли миллисекунды, то есть пакеты ходят локально.

6. Чтобы попасть снаружи - надо выйти наружу :). Что дома не так просто. Надо либо пойти на работу, к соседу или приятелю, либо из дома подключиться к другому провайдеру. Рядовой пользователь может сделать последнее, подключившись через мобильную связь. Я, например, воткнул 3G модем в ноутбук.
Снова сделаем пинг. В результате имя по-прежнему должно ресолвиться в тот же IP, но, если у вас нормальный роутер, пинга быть не должно. Если же у вас роутер из сети уже пингуется это может не так и страшно, но признак плохой и повод подумать о замене. Мой, вариант, напомню, asus rt-n56u с прошивкой от padavan.
Если пинга нет, отключите на роутере брандмауэр или, лучше и если есть, разрешите пинги из WAN. Теперь должно пинговаться.
Включите брандмауэр. На сегодня всё.

Читайте также: