Nat статус зондирование dns что это
Чтобы ответить на этот вопрос нужно понимать как происходит подключение.
Облачный сервис для видеонаблюдения - это система для организации удаленного видеонаблюдения через сервера "облака", включает в себя сервера с базой данных, на которых хранятся учетные записи пользователей сервиса, доступ к серверам осуществляется через сеть интернет. Облачный сервис может предоставлять услуги хранения видеозаписей с камер видеонаблюдения. Как правило, online просмотр с камер бесплатный, а резервирование (сохранение) записи на сервера облачного сервиса - услуга платная.
Как происходит подключение? Допустим вы приобрели регистратор, цифровую ip камеру или другое подобное устройство с облачным сервисом. Подключаем его к интернету. Устройство уже имеет уникальный идентификационный номер или этот номер может генерироваться в момент подключения к облаку. Для безопасности не забудьте установить пароль. При наличии интернет камера или регистратор устанавливают связь с серверами облачного сервиса. Устройство в облаке.
Чтобы удаленно иметь доступ к камере или видеорегистратору, вам нужно установить приложение того облачного сервиса, который вы решили использовать. Приложение можно установить на мобильные устройства: смартфоны, планшеты или компьютер. Далее в приложении вы указываете ваш идентификационный номер, который закреплен за вашим регистратором или камерой. В добавок, не забываем указать пароль, который мы придумали. Устанавливаем соединение и получаем удаленный доступ.
Облачный сервис выполняет связующую роль между вашим устройством и приложением. Со всем перечнем услуг и расценками можно ознакомиться на сайте облачного видеонаблюдения. На платных облачных ресурсах функционал значительно шире: архив записи невозможно похитить, т.к он располагается на надежных серверах в data центрах, можно предоставить гостевой доступ знакомым или друзьям к определенным камерам видеонаблюдения на период вашего отпуска или отъезда. Можно настроить онлайн трансляцию с вашей камеры на сайт, можно привязать камеру к карте местности и открыть к ней доступ всем желающим и многое много другое.
Рассмотрим бесплатный облачный сервис для видеонаблюдения: XMeye.
С его помощью можно бесплатно просматривать видео в реальном времени, а так же смотреть архив записи с жесткого диска установленного на регистраторе.
Сперва настраиваем видеорегистратор, в соответствии с краткой инструкцией. Полную версию всегда можно скачать на сайте производителя!
Далее заходим на вкладку Info (Сведения) -> Версия или в Настройки -> Информация -> версия, расположение и название вкладки может немного отличаться из-за версии прошивки и от производителя. Там мы можем наблюдать: Serial Number (Серийный номер). он имеет вид 5f630155c89a10ga - набор цифр и букв состоящий из 16 знаков, если серийный номер в другом виде, значит у вас облачный сервис не XMeye, а другого производителя.
Сохраняем наш серийник, он нам понадобится для облачного подключения к видеорегистратору.
Так же на этой же вкладке, можно увидеть Net (Nat) статус: связанный (если регистратор успешно подключился к облачным серверам).
Net статус: Зондирование DNS - означает что мы не подключены к облаку, возможно, что неверно настроена локальная сеть или у вас отсутствует интернет.
Устанавливаем на смартфон из Appstore или Google Play приложение: XMeye (иконка в виде домика)
Запускаем приложение. В нижнем левом углу есть кнопка local login, нажимаем.
Далее в верхнем правом углу нажимаем "+" и добавляем нашу учетную запись.
Login: admin (можно не вводить, стоит по умолчанию).
Serial number/Ip: 5f630155c89a10ga [вводим наш серийник, у вас он будет другой].
Password: пароль, который вы задали в настройках регистратора.
Подключаемся и удаленно просматриваем бесплатно все наши камеры и архив записи.
Автор: Дмитрий Самохвалов, технический редактор компании Rucam-Video.
Если вы не помните свой пароль, то введите ваш email и получите ссылку для входа. После авторизации укажите свой новый пароль в настройках профиля.
Настройка DDNS
Роутеры устанавливают соединение с сетью провайдера Интернет по технологии NAT, в которой используются два вида адресов:
- внешние (WAN) назначаемые провайдером при установке соединения;
- внутренние (LAN), которые роутер отдает сетевым устройствам;
Для нормального функционирования проброса портов WAN адрес не должен попадать в зоны IP-адресов начинающихся с 10.0, 192.168. и 172.16.
Если внешний адрес входит в указанные диапазоны придется приобрести статический «белый» IP-адрес или сменить провайдера.
Резервирование локальных адресов
Поскольку при каждом подключении сетевым устройствам назначается новый динамический IP, то для доступа через DDNS нужно преобразовать текущий IP-адрес в «локальный статический», иначе мы не сможем получить постоянный доступ, т.к. роутер меняет адрес при переподключении или перезагрузке:
Уникальный MAC-адрес должен быть указан в документации и сетевых параметрах. Данную процедуру повторяем для всех устройств, к которым планируется доступ через Интернет.
Настраиваем проброс портов
Переходим в меню «Forwarding» => «Virtual Servers» и добавляем новый порт («Add New…»):
- Service Port – вводим порт устройства для перенаправления;
- IP Adress – локальный IP, который мы зарезервировали для данного MAC-адреса;
- Status и Common Service Port – оставляем без изменений.
Нажимаем сохранить. Повторяем для всех используемых портов.
Настройка безопасности
Отключаем межсетевой экран роутера:
Настройка проброса портов произведена.
Автоматическое перенаправление
Упростить процесс проброса можно используя функцию UPnP. По умолчанию она активирована в большинстве роутеров и выглядит следующим образом:
Здесь мы видим, что порты Skype и программы uTorrent автоматически перенаправлены. Если видеооборудование поддерживает режим UPnP, то большая часть портов будет перенаправлена без вашего участия.
Проброс портов
Проброс, или перенаправление портов (Port Forwarding) – обязательное условие для доступа через Интернет к подключенным через роутер сетевым устройствам.
Если проброс портов не настроен, возникает ситуация, когда обратившись напрямую по адресу роутера или через сервис DDNS доступны только вход в админчасть и ничего более.
Переход по локальному адресу камеры, регистратора или локального сервера также ничего не дает – видны только папки или пустая страница. Только назначение отдельных портов и настройка перенаправления в роутере, дает возможность «достучаться» до нужной камеры или компьютера.
Облачный сервис для видеорегистратора
Служба Облачного сервиса должна быть включена. В регистраторах данный вопрос задаётся при включении/перезагрузки регистратора, и в видеорегистраторах и в IP камерах данный сервис включен по умолчанию, проверить это Вы можете во вкладке «Службы»-> «Облако», двойным нажатием левой кнопки мыши заходим в данный сервис.
Для IP камеры.
Для регистратора.
Существует 3 способа подключения, используя «Облачный сервис».
Способ первый.
В ПО CMS имеется возможность использования Облачного сервиса.
Для начала создаём группу, в которую будем добавлять устройства:
Вы увидите окно Зона(Область или Группа)
Вводим название группы, мы ввели единицу. Жмём ОК. После чего станет активно окно Доб. устройство:
Для использования Облачного сервиса необходимо во вкладке Устройства сменить галочку с IP адреса на Cloud:
,
далее остается ввести Серийный номер камеры/регистратора (ID, который указан в Информации о системе-> Версия), логин и пароль устройства.
Способ второй.
Программное обеспечение VMS (на примере регистратора)
Далее выбираем добавление устройств вручную (Manual Add).
В открывшемся окне необходимо выбрать тип подключения CloudID,
прописать Имя устройства (произвольное), серийный номер ID устройства, логин и пароль (если установлен).
После чего устройство будет добавлено.
Подключение камер через облако. Далее заходим во вкладку Монитор (Monitor) и двойным щелчком мыши по камере выводим в выбранное окно видеопоток с камеры.
Способ третий.
Сервисы очень похожи в использовании. Хотим отметить, что заведя Личный кабинет в одном из них, Вы можете авторизоваться на любом из этих сайтов, то есть Личный кабинет является общим. После входа у Вас будут доступны все Ваши устройства для работы с ними. Соответственно если один из сервисов не доступен, а такое, может быть, и бывает периодически, проводятся всякого рода профилактические работы и т.д., Вы можете использовать второй, тот, что работает. Недоступность обоих данных сервисов мало вероятна.
Способ четвёртый.
Необходимо активировать Active X, где пишет «Небезопасно», необходимо установить «Предлагать». Зайдя на данный сайт, откроется страница регистрации.
Существует два режима работы, зарегистрировавшись на сайте, Вы заводите Личный кабинет, либо можете зайти от имени устройства введя его ID, логин и пароль устройства.
Зайдя в свой Личный кабинет, откроется следующая страница.
В «Управлении устройством» Вы можете добавлять устройства, вводя их данные, добавлять эти устройства в список устройств. В «Мои устройства» Вы видите Ваш полный список устройств, имеется возможность проверить Подключение устройств, редактирование данных устройств, возможность подключения к устройствам двойным нажатием ЛКМ.
Примечание: значок означает отсутствие соединения с устройством.
Примечание: для корректной работы облачного сервиса не рекомендуется блокировать следующие порты 80, 8765, 8777, 8000, 7999, 7892, 15002 (TCP/UDP).
Если вы не помните свой пароль, то введите ваш email и получите ссылку для входа. После авторизации укажите свой новый пароль в настройках профиля.
Несколько дней не работает облачный видеосервис в то время как не было проблем более двух лет. Настройки не трогал. Как быть?
Андрей Ответить Добрый день. Данная проблема может быть связана с тем что на регистраторе не включено облако. Проверьте в службах(на устройстве) включено ли облако. Nat статус подключен на устройстве?
svyaz-taganrog Ответить NAT статус «Зондирование DNS» означает что камера пытается, но не может подключиться к облаку.
Проверьте стоит ли галка в пункте «Cloud» в разделе Сервисы
Вы должны авторизоваться, чтобы оставлять комментарии.
Следите за нашими постоянно развивающимися функциями и технологиями. Введите свой e-mail и подпишитесь на нашу рассылку.
®™ Официальный сайт торговой марки "Polyvision" © Все права защищены ООО "Бизнес Центр Алгоритм", 350047, г. Краснодар, ул. Красных Партизан, д. 249, офис 312, ИНН 2311218490, ОГРН 1162375029013 ООО "Бизнес Центр Алгоритм" является владельцем торговой марки "Polyvision" и официальным импортером продукции в Россию.
Развитие Интернета не обошло стороной системы видеонаблюдения и теперь удаленный контроль объектов доступен из любой точки мира. IP-камеры подключаются напрямую к сети, видеоархивы записываются в облачное хранилище, и тарифы доступны для всех категорий пользователей, например, от компании Ivideon.
Облачные решения, кроме несомненных преимуществ, имеют и существенные недостатки:
Как пример, мы используем TP-Link TL-WR740N. Этот роутер с неплохим соотношением цена/качество широко распространен среди домашних пользователей и малого бизнеса, и часто предлагается Интернет-провайдерами с собственной прошивкой. Используем англоязычный интерфейс, чтобы не было путаницы т.к. настройка DDNS и наименования разделов одинаковы на оборудовании любого производителя, а русский перевод иногда отличается.
Технология DDNS или DynDNS подключится через Интернет к видеокамерам и видеорегистраторам, находящихся в локальной сети с помощью роутера и динамических IP-адресов.
Данная формулировка большинству пользователей непонятна, поэтому подробно разберем процесс сетевого подключения.
Каждый роутер содержит внутренний список IP-адресов, которые в автоматическом режиме назначаются каждому подключенному сетевому устройству (компьютер, смартфон, IP-видеокамера, видеорегистратор и т.д.). При каждом новом подключении адрес выбирается случайным образом – это и есть динамические IP-адреса:
Кроме динамических используются постоянные или статические IP-адреса, как для роутера так и для подключенных устройств:
По такой же схеме распределения IP-адресов работают и Интернет-провайдеры. При установке соединения компьютер или роутер включается в глобальную сеть провайдера и через DHCP сервер получает новый динамический IP-адрес:
Статический IP-адрес предоставляется провайдерами на платной основе и бывает, что получить адрес невозможно:
Сервисы DDNS контролируют изменение динамического адреса роутера для постоянного доступа к локальным сетевым устройствам через специальный статический домен 3 уровня:
Подробнее схема доступа через DDNS выглядит следующим образом:
Облачный сервис
Вся линейка IP/гибридного/мультигибридного оборудования Polyvision начиная с 2013г. имеет поддержку «Облачного сервиса».
Что даёт данная технология?
Если у Вас нет статического IP адреса данный сервис позволяет подключиться к камерам/регистраторам, используя «Серийный номер» Вашего устройства (ID). Облачный сервис позволяет подключаться к устройству, смотреть видео в реальном времени - мониторинг, изменять конфигурацию и просматривать архив, с жёсткого диска установленного в регистратор, либо с камеры, если она с поддержкой карты памяти и пишет на неё.
Если вы планируете подключаться с ПК на базе ОС Windows к IP видеокамере, то вначале необходимо добавить её в ПО CMS в локальной сети для настройки.
Подробнее в данной теме:
Использование Облачного сервиса. Что для этого нужно?
Для этого необходимо, чтобы ваше устройство IP камера/регистратор были в сети Ethernet, это можно проверить, зайдя в «Конфигурацию устройства»->«Информация»->«Версия». Организуем видеонаблюдение через облако.
«Nat статус» должен быть связанный, «Nat код статуса» должен быть присвоен. Здесь так же Вы можете увидеть Серийный номер (ID) Вашего устройства. Если «Nat статус» к примеру зондирование DNS, то проверяйте настройки Вашего роутера и сетевые настройки IP камеры/регистратора в локальной сети. Можете воспользоваться для получения корректных настроек сети функцией DHCP, если она присутствует в Вашем роутере и включена и получить корректные сетевые настройки автоматически. Можете обратиться за помощью к системному администратору, либо поискать необходимую информацию в интернете.
Настройка DDNS в IP- камерах и видеорегистраторах
Камеры и видеорегистраторы поддерживают прямое подключения через отдельное Интернет-соединение без дополнительного оборудования. Настройка DDNS идет по той же схеме, как и в роутерах: создаем DDNS-домен и прописываем его настройки в WEB-интерфейсе устройства.
Пример для IP-камеры RVi-IPC22DN:
и для видеорегистратора Dahua HCVR4104C-W-S2:
Как видим все параметры стандартны и настройка не вызывает затруднений. Единственное отличие от роутера – через DDNS-домен возможен только к одному устройству, так как разделение по портам в данном случае не используется.
[help]Возникает закономерный вопрос: зачем такие сложности, если для установки соединение с камерой и доступа к видеоархиву достаточно набрать в браузере цифровой IP-адрес? [/help]
Два аргумента в пользу DDNS:
Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес
Смерть сетевого нейтралитета и ослабление правил для интернет-провайдеров по обработке сетевого трафика вызвали немало опасений по поводу конфиденциальности. У провайдеров (и других посторонних лиц, которые наблюдают за проходящим трафиком) уже давно есть инструмент, позволяющий легко отслеживать поведение людей в интернете: это их серверы доменных имен (DNS). Даже если они до сих пор не монетизировали эти данные (или не подменяли трафик), то наверняка скоро начнут.
«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.
Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.
Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.
Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.
Для пользователей подключить DNS-шифрование не так просто, как изменить адрес в настройках сети. В настоящее время ни одна ОС напрямую не поддерживает шифрование DNS без дополнительного программного обеспечения. И не все сервисы одинаковы с точки зрения софта и производительности.
Как работает DNS
Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.
Как выглядит типичный обмен данными между устройством и DNS-резолвером
«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.
Наиболее очевидный способ уклонения от слежки — использование VPN. Но хотя VPN скрывают содержимое вашего трафика, для подключения к VPN может потребоваться запрос DNS. И в ходе VPN-сеанса запросы DNS тоже могут иногда направляться веб-браузерами или другим софтом за пределы VPN-тоннеля, создавая «утечки DNS», которые раскрывают посещённые сайты.
Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.
Поэтому если хотите погрузиться в шифрование DNS, то лучше взять для DNS-сервера в домашней сети Raspberry Pi или другое отдельное устройство. Потому что вы наверняка обнаружите, что настройка одного из перечисленных клиентов — это уже достаточно хакерства, чтобы не захотеть повторять процесс заново. Проще запросить настройки DHCP по локальной сети — и указать всем компьютерам на одну успешную установку DNS-сервера. Я много раз повторял себе это во время тестирования, наблюдая падение одного за другим клиентов под Windows и погружение в спячку клиентов под MacOS.
Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows
Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.
«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.
«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».
Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.
Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom's Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.
По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).
Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.
С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.
С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.
Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.
Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».
TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки
У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.
Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.
Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.
Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.
Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:
После установления TCP-соединения клиента с сервером через порт 853 сервер представляет свой сертификат, а клиент сверяет его с хэшем. Если всё в порядке, то клиент и сервер производят рукопожатие TLS, обмениваются ключами и запускают зашифрованный сеанс связи. С этого момента данные в зашифрованной сессии следуют тем же правилам, что и в DNS по TCP.
После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.
Переключаемся с обычного трафика DNS на шифрование TLS
Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.
Здесь тоже имеется проблема с управлением сертификатами. Если провайдер удалит сертификат и начнёт использовать новый, то в настоящее время нет чистого способа обновления данных SPKI на клиентах, кроме вырезания старого и вставки нового сертификата в файл конфигурации. Прежде чем с этим разберутся, было бы полезно использовать какую-то схему управления ключами. И поскольку сервис работает на редком порту 853, то с высокой вероятностью DNS по TLS могут заблокировать на файрволе.
Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS
Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек
Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.
Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.
А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.
Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.
Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.
Другая проблема в том, что, хотя прекрасные ребята из сообщества DNSCrypt проделали большую работу, но такая приватность по-прежнему слишком сложна для обычных людей. Хотя некоторые из этих DNS-клиентов для шифрования оказалось относительно легко настроить, но ни один из них нельзя назвать гарантированно простым для нормальных пользователей. Чтобы эти услуги стали действительно полезными, их следует плотнее интегрировать в железо и софт, который покупают люди — домашние маршрутизаторы, операционные системы для персональных компьютеров и мобильных устройств.
Интернет-провайдеры наверняка постараются активнее монетизировать обычный DNS-трафик, и никуда не исчезнут государственные агентства и преступники, которые стремятся использовать его во вред пользователю. Но маловероятно, что крупные разработчики ОС стремятся надёжно защитить DNS доступным для большинства людей способом, потому что они часто заинтересованы в монетизации, как и интернет-провайдеры. Кроме того, эти разработчики могут столкнуться с сопротивлением изменениям со стороны некоторых правительств, которые хотят сохранить возможности мониторинга DNS.
Так что в ближайшее время эти протоколы останутся инструментом для тех немногих людей, кто реально заботится о конфиденциальности своих данных и готов для этого немного потрудиться. Надеюсь, сообщество вокруг DNSCrypt продолжит свою активность и продвинет ситуацию вперёд.
Облачный сервис для IP камеры.
Решение возможных проблем
- Антивирусные средства и файрволл должны быть отключены или добавлены исключения на все проброшенные порты;
- Необходимые порты могут быть открыты провайдером только для статических IP-адресов;
- Проверьте включение функции NAT-соединения с провайдером;
- При ручной настройке сетевых параметров убедитесь, что в устройстве, на который идет проброс портов, адрес шлюза совпадает с IP-адресом роутера;
Вводим E-mail, логин и пароль. Имя статического домена (хоста) через который будет осуществляться доступ можно задать при регистрации или выбрать позднее ( «Create my hostname later» в форме регистрации). Выбираем бесплатный тарифный план для ознакомления с сервисом. Для подтверждения регистрации переходим по ссылке присланной на электронную почту.
Заходим в созданный аккаунт, выбираем «Add Host», вводим имя хоста и выбираем доменную зону из раздела «Free DNS domain». Остальные параметры оставляем без изменения.
Включаем пункт «Port 80 Redirect» и указываем новый порт, через который DDNS обращается к роутеру.
Для нового порта управления обычно используется значение 8080. Настройки в админчасти:
Настройка аккаунта No-IP закончена, возвращаемся в админчасть роутера и выбираем сервис из списка поддерживаемых DDNS:
Вводим данные открытого аккаунта и наименование домена. Включаем «Enable DDNS», нажимаем «Login» и после установки соединения с сервером, сохраняем параметры.
Теперь обратившись через сайт с указанием порта камеры, мы получаем доступ к видеотрансляции:
В сетевом оборудовании может быть поддержка фирменного сервиса, например, от компаний D-Link и ASUS. Вот как выглядит настройка D-Link DDNS:
Читайте также: