Тест ноутбука DNS 0133066: в меру мощный заменитель домашнего компьютера с приятным дизайном | Ноутбуки | Обзоры
Ноутбуки прочно вошли в жизнь всех слоев общества. Многие уже давно отказались от полноценного домашнего компьютера в пользу компактной системы с меньшим количеством проводов и возможностью некоторое время работать без подключения к электрической сети. Специально для тех, кто собирается покупать ноутбук только для домашнего использования (но с возможностью быстрого переноса с места на место), существуют очень особые модели с большими дисплеями. Как, например, DNS 0133066 — помимо исполинского экрана, устройство может похвастаться вполне приличной конфигурацией, которая подходит для практически любых задач. Но обо всем по порядку.
Технические характеристики DNS 0133066:
Диагональ экрана — 17.3″
Разрешение экрана — 1600×900
Тип процессора — Intel Pentium B940, 2 ядра, 2000 МГц
Оперативная память— 3072 Мб DDR3
Объем жесткого диска — 500 Гб
Оптический привод — DVD-RW
Видеокарта — NVIDIA GeForce GT 520M, 1024 Мб DDR3
Беспроводные интерфейсы — Wi-Fi 802.
11n, Bluetooth,
Веб камера — есть
Устройство для чтения флэш-карт — есть
Слоты расширения/интерфейсы — 2х USB 3.0, 2х USB 2.0, HDMI, выход VGA (D-Sub), аудиопорты
Тип аккумулятора — Li-Ion, 4400 мАч
Габариты — 416х270х39 мм
Вес — 3 кг
Внешне
В стандартной коробке с ноутбуком лежит адаптер питания, диск, несколько бумажек, вытащенный аккумулятор в пупырчатом пакете и само габаритное устройство. Несмотря на весьма массивный корпус, DNS 0133066 собран достаточно хорошо (не скрипит, панели не отходят). К слову, обозначенная модель — это перебрендированная система MSI MS-1754, сделанная на контрактных заводах тайваньского производителя со всеми вытекающими особенностями.
Ноутбук весит около трех килограмм и вряд ли поместится в обычную сумку — система толщиной почти 4 сантиметра явно предназначена для домашнего использования. Как говорят в зарубежной IT-прессе, перед нами полноценный Desktop Replacement для не слишком требовательной публики.
Важное достоинство устройства — матовое покрытие крышки. На нем особо не заметны отпечатки пальцев и пыль, логотип DNS по традиции красуется в самое середине. Для того, чтобы открыть крышку, нужно приложить некоторое усилие, при этом систему приходится придерживать за нижнюю часть, чтобы она не наклонялась под усилием тугого шарнира — баланс ни к черту.
С точки зрения интерфейсных разъемов у DNS 0133066 все в порядке. На левой стороне есть два USB 3.0 (контроллер Renesas), HDMI для подключения к домашнему телевизору, два аудиопорта, прикрытое пластиковой заглушкой устройство для чтения карт памяти SD/MMC. Здесь же расположено отверстие системы вентиляции, отверстие для блока питания и отверстие замка Кенсингтона. Стоит сказать, что порты расположены очень близко друг к другу — едва ли у вас получится подключить USB-флэшку рядом с уже подключенным адаптером беспроводной мышки.
На правой стороне DNS 0133066 есть еще два USB, но уже USB 2.0, расположенные по двум сторонам от лотка привода (привод DVD-RW в ноутбуке расположен в необычном положении, ближе к передней части) — проблем с подключением внешней периферии точно не возникнет. Наконец, здесь же есть порт VGA для подключения к архаичному монитору и гигабитный сетевой порт.
К счастью, передняя панель ноутбука обошлась без дополнительной нагрузки. Все, то здесь есть — это, слава богу, тусклые индикаторы работы системы.
Открываем крышку, справляясь с усилием, и обнаруживаем большой глянцевый 17,3-дюймовый дисплей с разрешением 1600х900 точек. Да, могло бы быть и Full HD, но весовая категория все же не та. Впрочем, даже 1600х900 при таком размере экрана смотрится вполне адекватно — на рабочем столе можно открыть сразу несколько документов и поместить их друг рядом с другом, пространство позволяет. Что касается характеристик… говорит тут особо не о чем — перед нами стандартная TN-панель производства Samsung. С неплохими углами обзорами, обычной цветопередачей и легким перекосом в синеву (лечится в панели управления драйверов графического чипа).
В качестве дополнительной приятности — система оснащена стереомикрофоном. Два отверстия расположены на приличном расстоянии от веб-камеры над дисплеем.
Блок клавиатуры DNS 0133066 может похвастаться наличием полноценной цифровой панели Num Pad. Сами кнопки — это полюбившийся публике Chiclet-style (так называемая, островная). Кнопки выполнены в непривычной форме прогнувшихся к середине ровных квадратов, что на практике могло бы сказаться на юзабилити. Но это не так — нам не пришлось долго привыкать, чтобы начать печатать этот самый текст. Клавиши хорошо нажимаются, почти не шумят.
Отдельно хочется рассказать про раскладку. В компании MSI ее слегка видоизменили. Так, слева от длинного пробела появилась дополнительная кнопка, позволяющая ставить знаки «<» и «>» без переключения в английскую раскладку. К счастью, левый Ctrl находится в правильном крайнем положении. Еще один важный момент — полноразмерные стрелки. Этого ой как не хватает во многих других системах.
Тачпад DNS 0133066 слегка утоплен в корпус, что позволяет хорошо чувствовать сенсорную зону и не выходить за границы. Встроенная в него сдвоенная кнопка нажимается не очень плавно, к ней нужно привыкать. Сам тачпад вполне хорошо справляется с задачей — обрабатывает перемещения, поддерживает базовые жесты Multi-touch. Прорезиненное покрытие тачпада (а также всей внутренней панели ноутбука) не позволяет пальцу проскальзывать, при этом ощущается вполне комфортно.
Сразу над клавиатурой идут дополнительные кнопки, позволяющие (слева направо): открывать каретку привода (да, аппаратной кнопки на приводе нет), отключать дисплей, включать продвинутый экономичный режим работы, открывать программную панель с некоторыми дополнительными функциями (об этом позже), активировать предустановленные настройки для просмотра видео, включать любую заданную программу (настраивается из софта), включать/выключать систему.
По бокам от мультимедийной панели расположены вполне громкие стереодинамики. Ноутбук не хрипит на максимальной громкости, мощности акустики хватает для базовых функций, вроде незамороченного на басах просмотра фильмов. Но не более того.
Внутренне
Система задействует двухъядерный процессор Intel Pentium B940 из новейшей линейки бюджетных чипов на основе микроархитектуры Intel Sandy Bridge. Пугаться названия «Pentium» не стоит, перед нами очень современный процессор под старым добрым названием. Данная модель работает на частоте 2 ГГц и предлагает все скоростные преимущества Sandy Bridge, за исключением автоматического разгона Turbo Boost.
В отличие от старших моделей Core i3/i5/i7 процессор оснащен интегрированным графическим чипом HD Graphics 2000, задействующим вдвое меньше потоковых блоков и работающий на сниженной частоте по сравнению с HD Graphics 3000. С другой стороны, беда невелика — ноутбук оснащен дискретной видеокартой NVIDIA GeForce GT 520M с 1 Гб собственной памяти DDR3 и поддержкой технологии автоматического переключения NVIDIA Optimus. Все это вполне прекрасно работает — дискретное видео подключается при запуске игр, при этом желающие смогут настроить принудительную активацию GeForce GT 520M в обычных приложениях (в драйверах предусмотрен особый пункт на этот счет).
Сказать, что GeForce GT 520M — это геймерская видеокарта, значит, соврать. Данная модель оснащена всего 48 потоковыми процессорами, которые обеспечивают лишь базовую производительность. Впрочем, даже этого будет достаточно, чтобы запускать игры на средних и низких настройках качества в разрешении 1280х800 точек.
Мы убедились в игровой пригодности ноутбука, запустив несколько популярных игр в указанном выше разрешении со средними настройками качества графики.
Конечно, полноценно играть в родном для монитора разрешении 1600х900 вряд ли удастся, придется идти на компромисс. С другой стороны, если уж сильно хочется, то играть даже в современные тайтлы все же можно.
С точки зрения производительности, ноутбук подходит для почти любых задач — это полноценная современная система, предназначенная для мультимедийных и рабочих нужд, с большим дисплеем, удобной клавиатурой.
Программное обеспечение
Обычно мы упускаем этот пункт в обзорах ноутбуков DNS, потому что рассказывать, в общем-то, не о чем. С DNS 0133066 немного другая история — ноутбук идет с предустановленными надстройками от MSI. Так, во время первого запуска, мы заметили странную синюю звездочку посреди рабочего стола. Если подвести к ней курсор, из-под верхней границы экрана выпадет слегка унылого вида панель с кнопками и картинками.
Отсюда можно быстро запускать приложения, но это лишь вторичная функциональность — панель позволяет переключать режимы работы. Среди остальных интересна функция «TurboBattery+». При его активации, система переходит на пониженное энергопотребление и отключает буквально все, что может (по мнению программы) негативно сказываться на продолжительности работы от аккумулятора. Картинка рабочего стола пропадает, панель «Пуск» уезжает вниз, спецэффекты отключаются, яркость дисплея ставится на абсолютный минимум, беспроводные интерфейсы переходят в standby и так далее.
Работа от аккумулятора
В обычном режиме с настройкой «сбалансированная производительность» компьютер живет почти четыре часа без подключения к розетке питания. Разумеется, речь идет о работа в стандартных редакторах текста, интернет-серфинге, прослушивании музыки.
При включении TurboBattery+ система преображается — со всем-всем-всем отключенным компьютер работает больше шести часов, что вполне неплохо в современных условиях. Хоть и не рекордно. Напомним, в ноутбуке используется вполне обычная батарея на 4400 мАч (MSI-1727, 48800 мВт/ч).
Итого
В последнее время ноутбуки изрядно подешевели, однако даже в этом случае найти адекватного конкурента DNS 0133066 получается с трудом. К примеру, в каталоге DNS появился ноутбук HP Pavilion g7-1151er — очень, очень похожая по характеристикам система, буквально немного дороже, но с предустановленной Windows 7. Все остальные схожие модели используют устаревшие процессоры из линейки Intel Pentium P6000, менее мощные видеокарты и так далее.
Иными словами, DNS 0133066 обойдется все же дешевле, чем аналогичные системы на рынке. При этом нельзя сказать, что ноутбук будет в чем-то хуже. Наоборот, все соответствует стандартам современности — и качество сборки, и производительность, и установленные компоненты.
Все запчасти для DNS
Любой складИркутскАнгарскБлаговещенскБратскВладивостокВологдаЕкатеринбургИжевскКазаньКомсомольск-на-АмуреКрасноярскКурганМагнитогорскМоскваМосква (Митинский)МурманскНаходкаНижний НовгородНовокузнецкНовосибирскОмскОрёлОренбургПетрозаводскРостов-на-ДонуСанкт-ПетербургСтерлитамакУлан-УдэУссурийскХабаровскЧелябинскЧереповецЧитаЯкутск
Среди отечественных потребителей российский бренд DNS пользуется стабильной популярностью. В ассортимент товаров молодой компании входят самые востребованные в современном мире гаджеты. Их большой плюс – доступная цена. Но поскольку стоимость такой электронной техники невысока, качество изготовления несколько хуже, чем у более известных, поддерживающих высокое качество, брендов.
Владельцам мобильных устройств чаще приходится сталкиваться с ремонтом: например, с переустановкой драйверов dns. Но поскольку работа сервисной службы бренда налажена достаточно хорошо, подавляющее большинство задач, связанных с ремонтом dns телефонов и прочих девайсов успешно решается.
Наиболее распространенные причины неисправностей моделей Dns – дефекты сборки и небрежное обращение с техникой. Последнее нередко приводит к серьезным механическим повреждениям. Например, трещинам, царапинам, потертостям. Попадание влаги внутрь корпуса – еще одна причина обращения в сервисный центр. Как показывает практика, намокшие Dns планшеты, мобильные и лэптопы подвержены коррозии, и нередко вообще выходят из строя.
В зависимости от вида гаджета, ему может потребоваться замена следующих комплектующих:
- сенсорного стекла, тачскрина;
- матрицы экрана;
- корпусных деталей;
- аккумулятора dns;
- разъема зарядки;
- микрофона, динамиков, камеры;
- контроллеров, микросхем, материнской платы;
- клавиатуры, кнопок;
- лампы подсветки в ноутбуке dns;
- внутренних шлейфов;
- корпуса, крышки;
- и, кончено, всегда актуальна переустанка любого драйвера dns.
Это лишь примерный перечень, поскольку видов проблем достаточно много и каждая требует индивидуального решения. Чтобы правильно обнаружить причину неисправности (нерабочий аккумулятор dns, некачественная прошивка и т. д.), необходимо провести профессиональную диагностику оборудования.
Оригинальные запчасти – залог успешного ремонта!
Самый хороший специалист не сможет нормально отремонтировать ноутбук dns, если у него не будет качественных комплектующих. На ресурсе всегда можно приобрести любые детали к продукции бренда ДНС. Огромный ассортимент рассчитан на ремонт dns планшетов, смартфонов, лэптопов самых разных моделей.
На сайте есть как запчасти для новинок рынка электроники, так и для моделей, которые были актуальны несколько лет назад. Если подходящих изделий на dns телефоны и прочие гаджеты нет в наличии – их привезут под заказ в самое ближайшее время. Онлайн консультант через форму обратной связи быстро окажет квалифицированную помощь в подборе и поиске изделий, подскажет, как правильно оформить заказ.
Dns поддержка драйвера для ноутбуков
Для операционных систем Windows 10, Windows 8, 8.1, Windows 7, Windows Vista, XP (32-bit, 64-bit)
Как определить (узнать) модель ноутбука DNS и скачать нужные драйверы
Для скачивания драйверов узнайте код модели или название платформы ноутбука DNS, которые указаны на нижней части его корпуса (см. фото), а затем выберите их из списка и скачайте драйверы.
- Название платформы (PRODUCT CODE) это комбинация латинcких букв и цифр, например «M815P», «C5100Q»;
- Код модели это число вида «01234645», «1243567» и др.
ВАЖНО: на основе одной платформы может быть сделано несколько моделей ноутбуков DNS (использующих одинаковые драйверы). Поэтому удобней
Оригинальные драйверы всех моделей ноутбуков DNS: драйвер видео карты, драйвер звуковой карты, материнской платы (чипсет), драйвер сетевой карты, веб камеры, Wi-Fi, Bluetooth, USB и др.
Список платформ / их моделей и ссылки для скачивания драйверов:
(список платформ в алфавитном порядке – для удобства поиска)
Ноутбук DNS – 101 / 0122306, 0122310, 0123875, 0123957, 0123959, 0127811
Ноутбук DNS – 101G / 0122311, 0122312
Ноутбук DNS – 253_270EGQ (W253EGQ, W253EGQ, W253EFQ) / 0151002, 0161133, 0161140, 0161504, 0161712, 0161880, 0161881, 0162832, 0164713, 0164714, 0164926, 0165245, 0165246, 0165249, 0165546, 0165751, 0170723
Ноутбук DNS – 9070DX / 0117753, 0117754, 0119863, 0121155, 0121157
Ноутбук DNS – 9270D / 0121158, 0123952, 0124089, 0124090, 0124091, 0124092, 0125652, 0126579
Ноутбук DNS – A15A / 0157908, 0158636, 0161110, 0161500
Ноутбук DNS – A15FD / 0153300, 0164775, 0164781, 0164785, 0164796, 0165250, 0800520, 0801015, 0801016, 0801018, 0801019, 0801031
Ноутбук DNS – A15HC ( A15HE ) / 0127914, 0127916, 0133243, 0133836, 0142750, 0142786, 0143198, 0144430, 0144516, 0145148, 0147450, 0154711, 0154745, 0157917, 0158957, 0160939, 0163059
Ноутбук DNS – A17FD / 0153733, 0153735, 0154217, 0164777, 0164788, 0164792, 0164799, 0164924, 0170742, 0170754
Ноутбук DNS – A17HC / 0133844 0133845 0133846 0134363 0138075 0138409 0138410 0138562 0138595 0140701 0140708 0143196 0144092 0144869 0144972 0149526 0151359 0163026
Ноутбук DNS – A17YA / 0153734, 0153737, 0153783, 0158275, 0158276
Ноутбук DNS – A24HB / 0133239, 0133240, 0133244, 0145710, 0142776, 0142778, 0145712
Ноутбук DNS – A25PA / 0133272, 0133841, 0133842, 0138401, 0139775, 0144734
Ноутбук DNS – A35 / (драйверы для модели 0154207 – скачать здесь)
Ноутбук DNS – A35FB / 0151279, 0151280, 0154744, 0155725, 0156796, 0156797, 0157296, 0158637, 0158738
Ноутбук DNS – A35FE / 0156798, 0156812, 0151831, 0154207, 0154212, 0155650, 0156461, 0156462, 0156463, 0161145, 0164711, 0165168
Ноутбук DNS – A35YA / 0153782, 0158172, 0158173, 0158956, 0154897, 0155728 ,0157640
Ноутбук DNS – B14Y / 0150931, 0150939, 0150941
Ноутбук DNS – B34Y (B34FB, B34) / 0151433, 0151435, 0155768, 0155782, 0156456
Ноутбук DNS – B5100M / 0122211, 0122549, 0123231, 0123233, 0123266
Ноутбук DNS – B7110 / 0123954, 0124039, 0127376
Ноутбук DNS – B74FD / 0157843, 0157906, 0160837
Ноутбук DNS – B74Y / 0157903, 0157905
Ноутбук DNS – BL11 / 0133830, 0143203, 0147031
Ноутбук DNS – BL211 / 0133835
Ноутбук DNS – BLB3 / 0151560, 0152041, 0152042, 0152043, 0152044, 0152045, 0152046, 0161129
Ноутбук DNS – C15-C17B / 0801143, 0801149, 0801188, 0801480, 0801481, 0803082
Ноутбук DNS – C15A / 0170694, 0170699, 0800529, 0801147, 0801148, 0801479
Ноутбук DNS – C17A / 0170702, 0170703, 0170704, 0170705, 0174241, 0174242, 0174243, 0800931, 0800932, 0800933
Ноутбук DNS – C4505 / 0118740, 0118741
Ноутбук DNS – C4805 / 0118742, 0123247, 0125558, 0125559, 0125560, 0127365
Ноутбук DNS – C5100Q / 0123995, 0126387
Ноутбук DNS – C5500Q / 0123975
Ноутбук DNS – C5501Q / 0129431
Ноутбук DNS – CT50A / 0124002, 0126580, 0127476
Ноутбук DNS – CX11 / 0153784
Ноутбук DNS – Compal QAT11 / 0157257, 0161263, 0161264
Ноутбук DNS – E14RV0 / 0153736
Ноутбук DNS – E7130 / 0132013
Ноутбук DNS – h216 / 0145898, 0147412, 0157281, 0158634, 0158635
Ноутбук DNS – h46FD / 0123974, 0123997, 0124795, 0126409, 0128548
Ноутбук DNS – h46Q / 0123257, 0123259
Ноутбук DNS – h46T / 0123260, 0123261, 0123262, 0123263, 0124021, 0126388, 0126389, 0132392
Ноутбук DNS – h46Y / 0123304, 0123308, 0125746, 0127611, 0138425, 0138429, 0138440, 0138450, 0138490, 0138497, 0138502
Ноутбук DNS – H54Z / 0123894, 0126554
Ноутбук DNS – H70J / 0123871
Ноутбук DNS – H90K / 0155288, 0158629
Ноутбук DNS – H90M (H90MB) / 127618, 0127618, 0129680, 0138569
Ноутбук DNS – I38II-ID2 / 0123971, 0127604
Ноутбук DNS – I42SI / 0119429, 0119430, 0121250, 0123940
Ноутбук DNS – I43SI / 0122927, 0123948, 0119432, 0121251
Ноутбук DNS – J10 / 0123960, 0123961
Ноутбук DNS – JW2_UMA / 0156827, 0156828, 0156832, 0156834, 0156837, 0161505
Ноутбук DNS – JW6 / 0164084, 0161261, 0161262, 0164083
Ноутбук DNS – JW830 / 0120801
Ноутбук DNS – KHLB2 / 117104
Ноутбук DNS – Kangaroo-PCA51 / 0122658, 0132814, 0138413, 0138416, 0138423
Ноутбук DNS – Kangaroo-PCA52 / 0121263
Ноутбук DNS – Kangaroo-PCA55 / 0124000, 0127606, 0129989
Ноутбук DNS – Kangaroo-VME50D / 0119433, 0119435, 0119436, 0123253, 0123955
Ноутбук DNS – M100 / 0800154, 0800155, 0801182, 0801183
Ноутбук DNS – M1000 / 0114712, 0114713, 0114714, 0117756, 0117759, 0119849, 0119850, 0119852
Ноутбук DNS – M1100Q / 0121596, 0121597, 0121905, 0121906, 0121598
Ноутбук DNS – M110B / 0802284
Ноутбук DNS – M1110Q (M1110Q-C) / 0130181, 0123869, 0128279, 0128280, 0130178, 0130182, 0131339, 0132917
Ноутбук DNS – M1115 (те же драйверы, что и для M1110Q. Драйвера для всей М111х-х серии идентичны)
Ноутбук DNS – M116CC / 0155930, 0155938, 0155951, 0155952, 0158630, 0158632, 0158633
Ноутбук DNS – M500B / 0802885, 0802886
Ноутбук DNS – M500BN / 0802887
Ноутбук DNS – M740TUN / 117446 117447 117448 0121034 0117446 0117447 0117448
Ноутбук DNS – M745K / 0125081, 0122302
Ноутбук DNS – M748TG / 117444
Ноутбук DNS – M771CUH / 0121038, 0123953, 0123235, 0123234
Ноутбук DNS – M771K / 0120941, 0120942
Ноутбук DNS – M771S / 0116103, 0116104, 117437, 117438, 117439, 0119308, 0120320, 0120943, 0121030, 0123248, 0123249, 0126562
Ноутбук DNS – M771SUA / 0118738, 0118739, 0121033, 0124034
Ноутбук DNS – M771SUB / 0123250, 0123251
Ноутбук DNS – M771SUN / 0116105, 0116106, 0116107, 117116, 117440, 117441, 117442, 117443, 0119110, 0119121
Ноутбук DNS – M815P / 0117620, 0117621, 0117622
Ноутбук DNS – MB40II / 0133831, 0135731, 0145696, 0148745
Ноутбук DNS – MB50 (MB50IA1, MB50II) / 0133245, 0133246, 0133247, 0136281, 0137818, 0139151, 0139155, 0139774, 0142820, 0145842, 0151275, 0151276, 0165165
Ноутбук DNS – MS-1457 / 0123323, 0123327, 0124894
Ноутбук DNS – MS-1682 / 0123316, 0119437, 0119439, 0119440
Ноутбук DNS – MS-168A / 0123313, 0123316
Ноутбук DNS – MS-1733 / 0123317, 0123320, 0123321, 0124064, 0126413, 0127608, 0128907
Ноутбук DNS – MS-1754 / 0133066, 0133067
Ноутбук DNS – MS-1771 / 0801483
Ноутбук DNS – MT50II1 / 0165439, 0157892, 0157894, 0158175, 0161104
Ноутбук DNS – MT50IN ( mt50in1 ) / 0157896, 0157899, 0164780, 0164783, 0165387, 0170146
Ноутбук DNS – N13A / 0119113, 0119119, 0121910
Ноутбук DNS – NBLB2120001 (NBLB2) / 0119076, 0119102, 0119103, 0127685, 0127922, 0127923, 0127924
Ноутбук DNS – NBLB51 / 0123999, 0127275, 0129991, 0130080
Ноутбук DNS – NCL61 / 0123956, 0123958, 0127274, 0127617
Ноутбук DNS – NH5KB11 / 0801052, 0801232, 0801233
Ноутбук DNS – NH5KS02 / 0802340
Ноутбук DNS – O40 (O40II1) / 0123270, 0133236, 0134693, 0135730, 0135735
Ноутбук DNS – P10B / 0123962, 0128811
Ноутбук DNS – P10QC / 0158199
Ноутбук DNS – P10QD / 0140413, 0154705
Ноутбук DNS – P116 ( P116K ) / 0127620, 0127624, 0127625, 0127627, 0127628, 0133292, 0133837, 0134339, 0135689, 0139810, 0151943
Ноутбук DNS – P150EM / 0134360, 0134361, 0134362, 0143818, 0143819, 0149954, 0151825, 0151826, 0161713, 0164927, 0164928
Ноутбук DNS – P170NM (Clevo P170HM) / 0133270, 0133271, 0133849, 0142058, 0146270
Ноутбук DNS – P520 / 0121245
Ноутбук DNS – PBL00 / 0150672
Ноутбук DNS – PCW20 / 0149265
Ноутбук DNS – PNS1010 / 0127614, 0128055, 0128057, 0129908, 0129909, 0139454
Ноутбук DNS – PUMA-PCA55 / 0124020, 0126412
Ноутбук DNS – PUMA-VME50D / 0123252
Ноутбук DNS – QAT11 / 0157257, 0161263, 0161264
Ноутбук DNS – R121 / 0117923, 0117924
Ноутбук DNS – SW9D / 0129300, 0129304
Ноутбук DNS – SWH / 0152061, 0155679, 0152058, 0152059, 0133238, 0135740, 0139148, 0139772, 0139773, 0144743, 0152054
Ноутбук DNS – T30IL / 0121192, 0121194
Ноутбук DNS – TW9D / 0129303, 0129306, 0129307, 0130082, 0130083, 0133383, 0133384
Ноутбук DNS – TWC-GT / 0164784, 0164794, 0164797
Ноутбук DNS – TWC-N13P-GS / 0155953, 0155956, 0155959, 0162830, 0162831, 0165357
Ноутбук DNS – TWH_N12P_GS / 0133241, 0143199, 0144091, 0142782, 0152285, 0164779, 0165295
Ноутбук DNS – U10IL1 / 0121176, 0121177
Ноутбук DNS – UW3 / 0126561, 0136475
Ноутбук DNS – V10IS1 / 0121178
Ноутбук DNS – V10IS2 / 0123274, 0123274, 0123277, 0123281, 0123288
Ноутбук DNS – V40SI2 / 0123970, 0126555, 0133226, 0133230
Ноутбук DNS – W150ER-W170ER (W150ERQ) / 0164800, 0169860, 0170738, 0170744, 0800662, 0150174, 0150614, 0150999, 0151000
Ноутбук DNS – W170ER (те же драйверы, что и для W150ER)
Ноутбук DNS – W170HR / 0133847, 0134218, 0137514, 0137903, 0140505
Ноутбук DNS – W210xx&w215xx / W210. w215. (W210CUQW, W215CU и другие платформы, название которых начинается с W210. W215. ) / модели: 0144442, 0144443, 0144444 и др.
Ноутбук DNS – W253BWQ / 0150166
Ноутбук DNS – W253BZQ / 0165597
Ноутбук DNS – W253ENQ (W253EUQ, W270ENQ) / 0149447, 0150993, 0150995, 0151353, 0155012, 0155013, 0155015, 0155287, 0157280, 0157638, 0157639, 0164761, 0164763, 0164766, 0164772, 0165169, 0800160
Ноутбук DNS – W270BUQ / 0146174
Ноутбук DNS – w270EL (W271ELQ) / 0151559, 0151829, 0151830, 0161102, 0161114, 0162129, 0162824, 0801009, 0164768
Ноутбук DNS – W270HPQ / 0133852
Ноутбук DNS – W270HUQ / 0133850, 0133851, 0136631, 0137235, 0137530, 0143195, 0144434, 0144437, 0147455
Ноутбук DNS – W271BUQ / 0155833
Ноутбук DNS – W350STQ_W370ST / 0170717, 0170720, 0170727 , 0170728
Ноутбук DNS – W350_W370SSQ / 0802724, 0802724
Ноутбук DNS – W370ET_W350ET / 0164801 , 0164802
Ноутбук DNS – W350ETQ (он же W370ET, W350ET)
Ноутбук DNS – W550EU (W550EU1-C) / 0802734
Ноутбук DNS – W650EH / 0801041, 0801042, 0801044, 0801046, 0801047, 0802892, 0804317, 0804673
Ноутбук DNS – W650SR_670SR / 0170724, 0170726, 0801006, 0801065, 0801152, 0801153, 0801190, 0801191, 0801192
Ноутбук DNS – W650_W670SJQ / 0802872, 0802723
Ноутбук DNS – W670SFQ / 0802883
Ноутбук DNS – W670SH / 0804575, 0802882
Ноутбук DNS – W761TUN / 0117432, 0119109, 0119112, 0120955, 0121037
Ноутбук DNS – W765CUH / 0118724, 0118730, 0118731, 0119111, 0119830
Ноутбук DNS – W765K / 0116092, 0116093, 0117425, 0118736
Ноутбук DNS – W765S / 0116094, 0116095, 0116096
Ноутбук DNS – W765SUA / 0119107
Ноутбук DNS – W765SUB / 0119117, 0123272
Ноутбук DNS – W765SUN / 0119116, 0117429, 0118734
Ноутбук DNS – W765T[G] / 117107
Ноутбук DNS – W765T[H]B / 0119118
Ноутбук DNS – W832T / 0121674
Ноутбук DNS – W841T1 / 0119106
Ноутбук DNS – W842T / 0119104, 0119105
Ноутбук DNS – W860CU / 0120885, 0120934
Ноутбук DNS – W970TUQ / 0802870
Ноутбук DNS – WA50SRQ / 0802722, 0801150, 0801196, 0801258, 0801007, 0801056, 0801186, 0801187, 0802723
Ноутбук DNS – X300 (X300V) / 0157253, 0163031
Ноутбук DNS – w1100er / 0154185, 0154194, 0154195
Драйверы от официального производителя, входят в комплект ноутбуков DNS.
Программное обеспечение – . С помощью драйвера операционная система получает доступ к аппаратному обеспечению устройства.
Платформа ноутбука DNS (Pegatron): C15-C17B (C15B / C17B)
Он же: Pegatron C15B / C17B
Модели DNS: 0801143 / 0801149 / 0801188 / 0801480 / 0801481 / 0803082 и др. с платформой C15B / C17B
| Название | Группа | Тип | Размер |
Руководства и прочее
Драйверы для Windows 7 (32-bit)
Драйверы для Windows 7 (64-bit)
Драйверы для Windows 10, 8 / 8.1 (32-bit)
Драйверы для Windows 10, 8 / 8.1 (64-bit)
Устали искать драйверы?
DriverPack автоматически подберет и установит нужные драйверы
Популярные ноутбуки и нетбуки DNS
Все ноутбуки и нетбуки DNS
- Главная /
- ноутбуки /
- ноутбуки DNS
Устали искать драйверы для ваших устройств?
DriverPack Online автоматически найдет и установит нужные вам драйверы
Почтовое отделение для малого офиса: OMS + SpamPal + MS Outlook::Журнал СА 8.2008
Александр Емельянов
Почтовое отделение для малого офиса:
OMS + SpamPal + MS Outlook
Почтовый сервер с фильтром спама и хранением архива писем, а в качестве платформы – Windows XP. Стабильная и быстрая работа многие месяцы без отказа, плюс эффективная защита от спама и быстрый поиск важных почтовых сообщений, утраченных пользователями. «Бред!», – скажете вы, глядя на заголовок статьи. Не торопитесь делать выводы.
Вспоминая статью [1], посвященную бесплатному почтовому серверу Office Mail Server, с жалостью отмечу, что поддержка и развитие проекта сошли на нет. Однако функционал его по-прежнему актуален, и малая требовательность к ресурсам компьютера вкупе со стабильной работой заставляют обратить на него внимание.
OMS верой и правдой служил в нашей компании почтовым голубем. Время шло, и запросы сотрудников компании менялись. Однажды, когда некое важное письмо было утеряно сотрудником, стало понятно, что есть необходимость иметь общий архив писем с быстрым поиском по заданным условиям. Благо, что общий поток электронной почты укладывался не более чем в 100 писем в день, включая спам. Количество почтового хлама росло с каждым днем.
Спам-фильтр сервера OMS лишь превращал борьбу со спамом в игру в кошки-мышки. Нужно было искать какие-то решения, и, как всегда, все должно было быть дешево, но качественно.
Собственно, почти все оказалось под рукой. В качестве хранителя почтового архива и программы, обеспечивающей быстрый поиск старых писем, был выбран всем известный MS Outlook, который входит в стандартный набор MS Office. Антиспам-фильтром была выбрана программа SpamPal. Для лучшего понимания всей схемы рассмотрим каждый компонент отдельно.
Office Mail Server
Чтобы понять принципы работы OMS, достаточно прочитать статью [1]. В нескольких словах, этот сервер имеет в себе перечень компонентов, обеспечивающих транспорт, сортировку и фильтрацию почтового потока: SMTP- и POP3-серверы, SMTP- и POP3-клиенты, сортировщик и фильтр спама, а также IP-фильтр, позволяющий разрешить или ограничить доступ к серверу, отдельному хосту или целой подсети.
Вкратце, схема взаимодействия такова. Имеется виртуальный почтовый домен, при упоминании которого в адресе получателя письмо «падает» в почтовый ящик компании, заведенный на сервере провайдера. POP3-клиент сервера OMS по расписанию забирает письма с этого ящика и при помощи сортировщика раскладывает их по папкам конечных получателей. Доступ к этим папкам осуществляется с помощью встроенного POP3-сервера, посредством которого клиенты получают предназначенные им письма. При отправке письма клиент подключается к встроенному SMTP-серверу, и его сообщение ставится в очередь на отправку. Затем SMTP-клиент, используя транспорт провайдера, отправляет письма из очереди по назначению.
SpamPal
Этот проект, аналогично OMS, не имеет полноценного развития уже несколько лет. Однако функциональность работы SpamPal заставляет рассматривать его как серьезного кандидата для борьбы со спамом. В качестве рабочей была использована версия 1.594 этого продукта, но есть и более свежие бета-версии.
Для фильтрации спама SpamPal использует так называемые DNSBL (DNS blacklists, «черные списки» DNS), которые используются провайдерами для блокировки почты с серверов, замеченных в рассылке спама. Попросту говоря, SpamPal, получая письмо из почтового ящика, делает запрос на наличие IP-адреса сервера отправителя в списке DNSBL, и, при положительном ответе помечает его как спам.
Помимо этого после включения фильтра RegEx (от regular expressions – регулярные выражения), есть возможность фильтровать почту по вхождениям слов. В помощь к этому можно использовать, например, новостную систему электронного журнала «Спамтест» (spamtest.ru) от Лаборатории Касперского. Каждую неделю они публикуют самые популярные тематики спама с примерами писем, на основе которых вы можете строить регулярные выражения для фильтрации. Нужно отметить, что SpamPal требует некоторого первоначального обучения, потому что спамом, по его мнению, вполне могут оказаться доверенные отправители.
После установки SpamPal является посредником между почтовой программой и сервером, с которого получается почта. Сортируя сообщения на ликвидные и спам, программа ничего не удаляет и оставляет право выбора конечному пользователю. Она лишь помечает сообщение, расцененное ей как спам, и пересылает его дальше. Практически все самые известные почтовые клиенты могут работать со SpamPal. Именно поэтому программа оказалась именно тем, что нужно. Напомню, что OMS имеет встроенный POP3-клиент и для транспорта почты от провайдера к ящику конечного получателя использует связку POP3-клиент – фильтр спама – POP3-сервер. Теперь мы добавляем еще одно звено.
Процесс установки SpamPal предельно прост, и его запуск в работу, при правильном понимании всех манипуляций, дело пары минут. Однако есть один нюанс. После установки программа работает только в контексте пользователя, то есть для ее запуска (пусть даже и автоматического) необходимо войти в систему. Но нас это не совсем устраивает, все должно функционировать независимо от того, был выполнен вход в систему или нет. Для решения этой задачи будем использовать утилиту WinService Manager [2]. Ее нужно запустить после установки SpamPal и указать имя сервиса, а также место расположения файла spampal.exe и рабочей папки. В результате наш спам-фильтр будет работать как сервис. Вдобавок к этому нужно удалить SpamPal из автозагрузки, куда он прописывает себя после установки.
Нужно отметить, что для первоначальной работы программа уже имеет минимальную конфигурацию. Поэтому зачастую пользователю, пытающемуся «прикрутить» антиспам к почтовому клиенту, достаточно следовать инструкциям соответствующего раздела руководства к программе [3]. Как настроить SpamPal для нашего случая, будет описано дальше.
Microsoft Outlook
Этот продукт в представлении не нуждается. Более того, существует большая вероятность, что у человека, который будет отвечать за архивацию почты, он уже установлен в составе MS Office. Я заострю внимание лишь только на нужных нам особенностях программы. Как уже говорилось, в нашей схеме он будет выступать хранилищем электронных сообщений и обеспечивать поиск необходимой корреспонденции.
Всю информацию MS Outlook хранит в PST-файлах (файлы личных папок). Причем это автономное хранилище, и его преспокойно можно перемещать с диска на диск и даже переносить на другой компьютер и работать с ним как на личной машине. Это первый плюс для нашей задачи. Второй плюс – PST-файлы могут быть сжаты как средствами Outlook, так и при помощи архиваторов. Для примера, файл личных папок размером 3 Гб может быть сжат архиватором WinRAR вдвое.
Поскольку PST-файлы будут содержать большое количество писем, то будет вполне уместным рассказать об ограничении размера этих файлов. На данный момент существует два формата этих файлов – ANSI и Unicode. Возможность создания файлов личных папок в формате Unicode появилась в MS Outlook 2003. Это позволило увеличить максимальный размер с 2 Гб (для формата ANSI) до 20 Гб (для формата Unicode). Однако существует одна проблема с использованием PST-файлов. При приближении к максимальному размеру файла личных папок MS Outlook начинает работать нестабильно. Рассмотрим параметры реестра, которые помогут не допустить этого.
Параметры реестра для указания максимального размера PST-файлов
Имя | Тип | Допустимый диапазон значений | По умолчанию |
MaxLargeFileSize | REG_DWORD | 0x00000001-0x00005000 | 0x0000500020480 (20 Гб) |
WarnLargeFileSize | REG_DWORD | 0x00000000-0x00005000 | 0x00004C0019456 (19 Гб) |
MaxFileSize | REG_DWORD | 0x001F4400-0x7C004400 | 0x7BB044002075149312 (1,933 Гб) |
WarnFileSize | REG_DWORD | 0x00042400-0x7C004400 | 0x744044001950368768 (1,816 Гб) |
В таблице первые два параметра относятся к файлам в формате Unicode. Параметр MaxLargeFileSize служит для указания абсолютного максимального размера для файлов PST. По достижении этого размера увеличение файла прекращается. Параметр WarnLargeFileSize служит для указания максимального количества данных в файлах PST. После достижения этого предела добавление данных в файлы PST невозможно, однако физический размер файлов может увеличиваться из-за внутренних процессов.
Два следующих параметра относятся к файлам в формате ANSI. MaxFileSize, WarnFileSize – то же самое, что и параметры MaxLargeFileSize и WarnLargeFileSize соответственно. Приращение значений параметров для файлов в формате Unicode осуществляется в мегабайтах (Мб), а для файлов в формате ANSI – в килобайтах (Кб).
Значения данных параметров устанавливаются в реестре в следующих ветках:
Outlook 2003:
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\PST;
- HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\PST.
Outlook 2007
- HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\PST;
- HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\PST.
Если таких параметров не существует, их можно создать.
Собираем компоненты воедино
Для начала рассмотрим, как каждая программа должна быть настроена для построения задуманного, а затем уточним нюансы.
OMS является в этой схеме центральным звеном, с него и начнем. Для получения почты с ящика провайдера в настройках POP3-клиента должны быть указаны соответствующие параметры: имя или IP-адрес POP3-сервера провайдера, порт подключения (110 по умолчанию), данные авторизации, тайм-аут подключения, используемый сортировщик, спам-фильтр и др. Но помня о том, что между провайдером и нашим клиентом должен располагаться SpamPal для фильтрации спама, обратимся к руководству по его настройке [3]. В случае, когда SpamPal и почтовая программа (в данном случае ей выступает POP3-клиент OMS) находятся на одном компьютере, применяется следующая конфигурация. Вместо адреса POP3-сервера провайдера указывается 127.0.0.1, а в качестве номера порта должно быть указано число 110, но… На 110 порту на локальной машине ждет подключений POP3-сервер OMS, поэтому для исключения конфликта укажем другой номер порта, например 11010. Все остальное остается без изменений.
Далее обратимся к SpamPal. В настройках программы в пункте «Соединения» удаляем стандартные настройки и добавляем новый порт (стоит отметить, что если вы используете или будете использовать несколько POP3-клиентов OMS, то для каждого подключения нужно будет создать новый порт). На вкладке «Установки» отмечаем «Конкретное имя сервера» и указываем имя сервера провайдера и порт (в нашем случае 11010). Таким образом, используя авторизационные данные POP3-клиента OMS, SpamPal подключается к ящику, куда идет вся почта, забирает ее, проверяет каждое сообщение на принадлежность к спаму и передает далее клиенту. В случае, если письмо оказывается, по мнению SpamPal, спамом, оно не удаляется, но в тему письма добавляется «**SPAM**», а также добавляется заголовок «X-SpamPal:», в котором указывается фильтр, по мнению которого данное сообщение – спам.
Что касается MS Outlook, здесь все предельно просто. Напомню, что вся почта, проходящая через OMS, копируется в учетную запись, которая является архивной. Это задается опционально в настройках почтового сервера. Минус ее в том, что все письма хранятся в файловой системе в виде .eml-файлов в соответствующей архивному мейлбоксу папке. Это затрудняет оперативный поиск нужного электронного сообщения. Поэтому на машине, которая будет выступать репозиторием корпоративной почты, нужно в MS Outlook создать отдельный PST-файл, настроить учетную запись для доставки почты из архива. Одновременно можно создать правило, согласно которому письма из архива будут складываться в папку, например, с названием «Текущая почта». Также можно создавать еще PST-файлы, в которые будет перемещаться архивная почта из папки «Текущая почта». Допустим, каждый такой файл будет соответствовать году и содержать папки «1-й квартал», «2-й квартал» и т. д. Например, закончился первый квартал года, и вся текущая почта перекочевала в соответствующую папку. По окончании года можно получившийся PST-файл «отцепить» и скопировать на сервер до востребования. Все это поможет не только упорядочить весь корпоративный почтовый поток, но и ускорить поиск необходимой корреспонденции.
Итог
Что в итоге мы получим? Электронное сообщение, пройдя проверку на спам, доставляется на сервер OMS, а именно в папку получателя, а копия письма – в архивную папку. После этого письмо выкачивается почтовым клиентом и появляется у получателя. А копия письма «летит» в папку с текущей почтой и хранится в PST-файле.
Такая схема обеспечивает некоторую гибкость управления почтовым потоком. Так, например, администратор может отсеивать спам на сервере OMS при помощи встроенного спам-фильтра: копировать в специально созданный ящик или просто удалять. Либо предоставить право пользователям сортировать сообщения при помощи правил непосредственно на этапе получения почтовым клиентом.
Приложение
Замечания по SpamPal
- После создания порта будет лучше, если вы отметите в настройках опцию «Подавить сообщения об ошибках соединения у клиента». Иначе при частых запросах к серверу провайдера, отсутствующей связи SpamPal может буквально «захлебнуться» сообщениями об ошибках и «повиснуть». После чего, даже при восстановлении связи, входящий почтовый поток будет остановлен до тех пор, пока вы не перезапустите SpamPal.
- В той версии, которая описана в статье, есть ошибка в интерфейсе. Меню «Инструменты» содержит два подменю: «В черный список» и «В белый список». Они по смыслу перепутаны местами, то есть, выбрав добавление адреса или домена в черный список, вы на самом деле добавите его в белый список.
- Емельянов А. Организуем работу офисного почтового сервера на платформе Windows. //Системный администратор, №12, 2006 г. – С. 40-43 – http://www.samag.ru/cgi-bin/go.pl?q=articles;n=12.2006;a=02.
- http://winservice.ucoz.ru.
- http://www.spampal.org/manual-rus.
Все о MDaemon (#3) | В помощь системному администратору
Помогите разобраться с настройкой антиспама в Mdaemon10. Стояла 8ка с настроенным баесовым фильтром,и всё было отл. Перешел на 10ку,настройки антиспама сбросились. Обучил баесовов фильтр(около 1000 спама и неспама),включил эвристику,DNS-BL — ничего не помогает — не считает очки спама! Сейчас настройки антиспама на умолчании,баесов фильтр вкл,стоит Antispam Security Plus 3.06 и вот полюбуйтесь:SMTP in:
Tue 2008-09-23 11:01:48: ———-
Tue 2008-09-23 11:01:53: Session 23; child 1; thread 5332
Tue 2008-09-23 11:01:07: Accepting SMTP connection from [220.169.253.5:26446]
Tue 2008-09-23 11:01:07: —> 220 contora.ru ESMTP MDaemon 10.0.0; Tue, 23 Sep 2008 11:01:07 +0400
Tue 2008-09-23 11:01:14: <— EHLO [220.169.253.5]
Tue 2008-09-23 11:01:14: —> 250-contora.ru Hello [220.169.253.5], pleased to meet you
Tue 2008-09-23 11:01:14: —> 250-ETRN
Tue 2008-09-23 11:01:14: —> 250-AUTH=LOGIN
Tue 2008-09-23 11:01:14: —> 250-AUTH LOGIN CRAM-MD5
Tue 2008-09-23 11:01:14: —> 250-8BITMIME
Tue 2008-09-23 11:01:14: —> 250 SIZE 0
Tue 2008-09-23 11:01:23: <— MAIL FROM:<[email protected]>
Tue 2008-09-23 11:01:23: —> 250 <[email protected]>, Sender ok
Tue 2008-09-23 11:01:24: <— RCPT TO: <[email protected]>
Tue 2008-09-23 11:01:24: —> 250 <[email protected]>, Recipient ok
Tue 2008-09-23 11:01:45: <— DATA
Tue 2008-09-23 11:01:45: Creating temp file (SMTP): c:\mdaemon\temp\md50000000016.tmp
Tue 2008-09-23 11:01:45: —> 354 Enter mail, end with <CRLF>.<CRLF>
Tue 2008-09-23 11:01:46: Message size: 1091 bytes
Tue 2008-09-23 11:01:46: Passing message through Spam Filter (Size: 1091)…
Tue 2008-09-23 11:01:47: c:\mdaemon\temp\md50000000016.tmp
Tue 2008-09-23 11:01:47: An error occured during Spam Filter processing
Tue 2008-09-23 11:01:53: Создание сообщения successful: c:\mdaemon\inbound\md50000115999.msg
Tue 2008-09-23 11:01:53: —> 250 Ok, message saved <Message-ID: 01c91d8d$48752200$05fda9dc@qyhfhdhr>
Tue 2008-09-23 11:01:53: <— QUIT
Tue 2008-09-23 11:01:53: —> 221 See ya in cyberspace
Tue 2008-09-23 11:01:53: SMTP session successful (Bytes in/out: 1204/451)
Tue 2008-09-23 11:01:53: ———-
AntiSpam Log:
Tue 2008-09-23 11:01:02: ———-
Tue 2008-09-23 11:01:53: (SMTP) Spam Filter processing c:\mdaemon\temp\md50000000016.tmp…
Tue 2008-09-23 11:01:53: * Message return-path: [email protected]
Tue 2008-09-23 11:01:53: * Message ID: 01c91d8d$48752200$05fda9dc@qyhfhdhr
Tue 2008-09-23 11:01:53: Start SpamAssassin results
Tue 2008-09-23 11:01:53: 00.00 points, 5 required;
Tue 2008-09-23 11:01:53: c:\mdaemon\temp\md50000000016.tmp
Tue 2008-09-23 11:01:53: End SpamAssassin results
Tue 2008-09-23 11:01:53: ———-
Поможите, люди добрые…
DNS MS-1754 Ноутбук | Комната недвижимости
Самовывоз по данной позиции доступен на нашем складе в г. Фармингдейл, Нью-Йорк
| DNS MS-1754 Ноутбук Получите выгодную сделку на этом онлайн-аукционе портативного компьютера, представленного Property Room от имени клиента правоохранительных органов или государственного агентства.
Состояние: Хорошее Срок службы батареи на этом устройстве имеет не тестировался.Может потребоваться зарядить его перед использованием. Из-за лицензионных ограничений этот продукт будет поставляться без какого-либо программного обеспечения, включая программное обеспечение операционной системы. Просмотр информации об условиях товара |
|
|
- Доступные способы доставки (выберите при торгах)
- Цена
- Встреча клиента (в течение 10 дней) на нашем складе в Фармингдейле, Нью-Йорк 11735
- $ 7.95
- Стандартная доставка (5-7 рабочих дней)
- $ 20.95
- Ускоренная доставка (2-4 рабочих дня)
- Не применимо
Вес с упаковкой: 14 фунтов (Вес с упаковкой для этого предмета был рассчитан с использованием наибольшего из значений габаритного веса предмета или фактического веса.Что такое габаритный вес? )
Пожалуйста, внимательно ознакомьтесь с нашей политикой доставки и возврата, прежде чем делать ставки.
Доставка возможна только в пределах континентальной части США. Международная доставка недоступна. Может применяться применимый налог с продаж. Время от времени по собственному усмотрению PropertyRoom.com может изменять преобладающую структуру платы за доставку и обработку.
- Участник торгов
- Дата
- Время
- Цена за единицу
В настоящее время нет вопросов по этому списку.
Есть вопросы по этому предмету? Войдите, чтобы задать вопрос.Отказ от ответственности: Делая ставки на любой товар, вы прямо соглашаетесь с тем, что используете веб-сайт и услуги на свой страх и риск и в соответствии с пользовательским соглашением.Веб-сайт, услуги и любые товары или услуги, приобретенные или полученные через веб-сайт, услуги или любые транзакции, заключенные через веб-сайт или услуги, предоставляются на условиях «как есть» и «как доступно». PropertyRoom от своего имени и, действуя в качестве агента, от имени своего принципала, отказывается от всех гарантий любого рода, явных или подразумеваемых, и, в частности, отказывается от любых подразумеваемых гарантий правового титула, товарной пригодности, пригодности для определенной цели и отсутствия -нарушение.Никакие советы, мнения или информация, устные или письменные, полученные от PropertyRoom или через веб-сайт или услуги, не создают никаких гарантий. В некоторых юрисдикциях не допускается исключение определенных гарантий, поэтому некоторые из вышеперечисленных исключений могут не относиться к вам. Эта гарантия дает вам определенные юридические права, и вы также можете иметь другие юридические права, которые варьируются от юрисдикции к юрисдикции.
Служба Dnscache больше не отправляет пакеты обновления на DNS-сервер
Версия этого исправления на английском языке (США) устанавливает файлы, атрибуты которых указаны в следующих таблицах.Дата и время для этих файлов указаны в формате всемирного координированного времени (UTC). Дата и время для этих файлов на вашем локальном компьютере отображаются в вашем местном времени вместе с вашим текущим смещением на летнее время (DST). Кроме того, дата и время могут измениться при выполнении определенных операций с файлами.
Информация о файлах для Windows 8 и Windows Server 2012 и примечания Важные исправления для Windows 8 и Windows Server 2012 включены в одни и те же пакеты.Однако на странице запроса исправления указана только «Windows 8». Чтобы запросить пакет исправлений, который применяется к одной или обеим операционным системам, выберите исправление, указанное в разделе «Windows 8» на странице. Всегда обращайтесь к разделу «Применимо к» в статьях, чтобы определить фактическую операционную систему, к которой применяется каждое исправление.
Файлы, относящиеся к конкретному продукту, этапу (RTM, SP n ) и ветви обслуживания (LDR, GDR), можно определить, проверив номера версий файлов, как показано в следующей таблице.
Версия
Товар
Веха
Сервисное отделение
6.2,920 0,17 ххх
Windows 8 и Windows Server 2012
RTM
ГДР
6.2.920 0,21 ххх
Windows 8 и Windows Server 2012
RTM
LDR
Файлы МАНИФЕСТА (.manifest) и файлы MUM (.mum), установленные для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах для Windows 8 и Windows Server 2012». MUM и файлы МАНИФЕСТА, а также связанные файлы каталога безопасности (.cat) чрезвычайно важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не указаны атрибуты, подписаны цифровой подписью Microsoft.
Для всех поддерживаемых x86 версий Windows 8
Имя файла | Версия файла | Размер файла | Дата | Время | Платформа |
|---|---|---|---|---|---|
Dnsapi.dll | 6.2.9200.17137 | 458 240 | 09 октября 2014 г. | 03:58 | x86 |
Dnsrslvr.dll | 6.2.9200.17212 | 160 768 | 10 декабря 2014 г. | 05:03 | x86 |
Dnsapi.dll | 6.2.9200.21252 | 462 336 | 4 октября 2014 г. | 03:25 | x86 |
Dnsrslvr.dll | 6.2.9200.21317 | 160 768 | 10 декабря 2014 г. | 00:33 | x86 |
Для всех поддерживаемых 64-разрядных версий Windows 8 и Windows Server 2012
Имя файла | Версия файла | Размер файла | Дата | Время | Платформа |
|---|---|---|---|---|---|
Dnsapi.dll | 6.2.9200.17137 | 623 616 | 09 октября 2014 г. | 03:59 | x64 |
Dnsrslvr.dll | 6.2.9200.17212 | 212 992 | 10 декабря 2014 г. | 06:49 | x64 |
Dnsapi.dll | 6.2.9200.21252 | 606 208 | 4 октября 2014 г. | 04:24 | x64 |
Dnsrslvr.dll | 6.2.9200.21317 | 210 944 | 10 декабря 2014 г. | 00:38 | x64 |
Dnsapi.dll | 6.2.9200.17137 | 458 240 | 09 октября 2014 г. | 03:58 | x86 |
Dnsapi.dll | 6.2.9200.21252 | 462 336 | 4 октября 2014 г. | 03:25 | x86 |
Дополнительная информация о файлах для Windows 8 и Windows Server 2012
Дополнительные файлы для всех поддерживаемых версий Windows 8 для систем на базе x86
Имя файла | Package_1_for_kb3022773_bf ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 1 977 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Package_1_for_kb3022773 ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 2 693 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Пакет_2_for_kb3022773_bf ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 1,775 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Пакет_2_for_kb3022773 ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 2,487 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Пакет_3_for_kb3022773_bf ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 1,775 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Package_3_for_kb3022773 ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 2,487 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Package_for_kb3022773_rtm_bf ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 2 159 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Package_for_kb3022773_rtm ~ 31bf3856ad364e35 ~ x86 ~~ 6.2.1.0.mum | |
Версия файла | Не применимо | |
Размер файла | 2 206 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | Update-bf.мама | |
Версия файла | Не применимо | |
Размер файла | 1,754 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | X86_08cc6a89b9cbf173037b3b0326818d47_31bf3856ad364e35_6.2.9200.17212_none_2dad6b2b31801804.manifest | |
Версия файла | Не применимо | |
Размер файла | 705 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | X86_e841c528d81f863b4f80de0c48f0e6df_31bf3856ad364e35_6.2.9200.21329_none_b12c4a798a006f70.manifest | |
Версия файла | Не применимо | |
Размер файла | 705 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:28 | |
Имя файла | X86_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.17212_none_ | 5d2f45584dc.manifest|
Версия файла | Не применимо | |
Размер файла | 22 281 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:33 | |
Имя файла | X86_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.21329_none_ | 4b80d74f1f8.manifest |
Версия файла | Не применимо | |
Размер файла | 22 281 | |
Дата (UTC) | 10 декабря 2014 г. | |
Время (UTC) | 14:33 | |
Дополнительные файлы для всех поддерживаемых 64-разрядных версий Windows 8 и Windows Server 2012
Имя файла | Amd64_6cdb0a7a96e7481b9ea43117653ffc8d_31bf3856ad364e35_6.2.9200.17212_none_24cfd53f454089d1.manifest |
Версия файла | Не применимо |
Размер файла | 709 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Amd64_d1cbf44fcbfe455424fc833b4ce73c6d_31bf3856ad364e35_6.2.9200.21329_none_a4e41af2ca7c5e61.manifest |
Версия файла | Не применимо |
Размер файла | 709 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Amd64_e4df307445f577f3846cd54a8d1ab828_31bf3856ad364e35_6.2.9200.17212_none_668c516483cc31ba.manifest |
Версия файла | Не применимо |
Размер файла | 709 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Amd64_ef57c8b3e7151167f2bebe6a318b336e_31bf3856ad364e35_6.2.9200.21329_none_7569099a986b2857.manifest |
Версия файла | Не применимо |
Размер файла | 709 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Amd64_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.17212_none_ee9ef156acb2f612.manifest |
Версия файла | Не применимо |
Размер файла | 22 289 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:36 |
Имя файла | Amd64_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.21329_none_ef24c03bc5d2632e.manifest |
Версия файла | Не применимо |
Размер файла | 22 289 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:36 |
Имя файла | Пакет_1_for_kb3022773_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 1,989 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Package_1_for_kb3022773 ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 2 709 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_2_for_kb3022773_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 2 002 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_2_for_kb3022773 ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3 899 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_3_for_kb3022773_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 2 008 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_3_for_kb3022773 ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3 905 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_4_for_kb3022773_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 1,785 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_4_for_kb3022773 ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3,680 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_5_for_kb3022773_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 1,791 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_5_for_kb3022773 ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3 687 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_for_kb3022773_rtm_bf ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3,131 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Пакет_for_kb3022773_rtm ~ 31bf3856ad364e35 ~ amd64 ~~ 6.2.1.0.mum |
Версия файла | Не применимо |
Размер файла | 3 214 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Update-bf.мама |
Версия файла | Не применимо |
Размер файла | 2,191 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:28 |
Имя файла | Wow64_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.17212_none_f8f39ba8e113b80d.manifest |
Версия файла | Не применимо |
Размер файла | 18 399 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:36 |
Имя файла | Wow64_microsoft-windows-dns-client-minwin_31bf3856ad364e35_6.2.9200.21329_none_f9796a8dfa332529.manifest |
Версия файла | Не применимо |
Размер файла | 18 399 |
Дата (UTC) | 10 декабря 2014 г. |
Время (UTC) | 14:36 |
| 194.233,74,68 vmi631400.contaboserver.net. | Сингапур | 141995 Contabo Asia Private Limited | — | 2021-10-11 14:05:54 UTC | действительный | 90% | Кто |
| 210.80.58.67 cache301.ns.uu.net. | 703 УУНЕТ | — | 2021-10-11 14:04:58 UTC | действительный DNSSEC | 100% | Кто | |
| 203.211.150.119 119.203-211-150.static.qala.com.sg. | 17547 M1 NET LTD | — | 2021-10-11 14:03:54 UTC | действительный DNSSEC | 100% | Кто | |
| 203.126.118.38 | Сингапур | 3758 SingNet | Microsoft DNS 6.1.7601 (1DB15EC5) | 2021-10-10 15:18:16 UTC | действительный | 11% | Кто |
| 202.136.162.11 dns01.ntts-idc.net.sg. | 17645 NTT СИНГАПУР PTE LTD | никто | 2021-10-10 10:07:06 UTC | действительный | 100% | Кто | |
| 210.16.120.48 sg.adhole.org. | 7489 HostUS | — | 2021-10-08 21:06:23 UTC | действительный DNSSEC | 89% | Кто | |
| 203.211.150.118 118.203-211-150.static.qala.com.sg. | 17547 M1 NET LTD | 9.3.4-P1.2 | 2021-10-08 21:06:20 UTC | действительный | 73% | Кто | |
| 118.189.211.221 221.211.189.118.static.m1net.com.sg. | Сингапур | 4773 MobileOne Ltd. Провайдер мобильных интернет-услуг Сингапур | DNSServer | 2021-10-08 15:06:14 UTC | действительный | 100% | Кто |
| 143.244,33,74 unn-143-244-33-74.datapacket.com. | Сингапур | 60068 Datacamp Limited | — | 2021-10-08 08:01:44 UTC | действительный DNSSEC | 94% | Кто |
| 119.73.137.211 | Сингапур | 3758 SingNet | — | 2021-10-08 08:00:46 UTC | действительный | 99% | Кто |
| 115.42.228.246 | Сингапур | 3758 SingNet | НЕИЗВЕСТНЫЙ | 2021-10-05 10:20:51 UTC | действительный DNSSEC | 45% | Кто |
| 203.126.107.195 | Сингапур | 3758 SingNet | — | 2021-10-04 13:04:12 UTC | действительный | 48% | Кто |
| 58.185.177.165 | Сингапур | 3758 SingNet | — | 2021-10-04 06:11:40 UTC | действительный | 99% | Кто |
| 2400: 6180: 0: d0 :: 5f6e: 4001 резольвер.tiar.app. | Сингапур | 14061 DIGITALOCEAN-ASN | — | 2021-10-03 03:07:38 UTC | действительный DNSSEC | 100% | Кто |
| 178.128.23.211 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.81 | 2021-10-02 17:27:38 UTC | действительный | 100% | Кто |
| 3.0,211,35 ec2-3-0-211-35.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-02 17:06:10 UTC | действительный | 100% | Кто |
| 128.199.128.150 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-02 16:52:43 UTC | действительный | 100% | Кто |
| 178.128.18.236 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.79 | 2021-10-02 16:43:03 UTC | действительный DNSSEC | 100% | Кто |
| 13.212.182.154 ec2-13-212-182-154.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-02 16:29:19 UTC | действительный | 100% | Кто |
| 207.46.226.177 | Сингапур | 8075 МИКРОСОФТ-КОРП-MSN-AS-БЛОК | dnsmasq-pi-hole-2.81 | 2021-10-02 16:27:17 UTC | действительный | 100% | Кто |
| 45.76.149.223 45.76.149.223.vultr.com. | Сингапур | 20473 АС-ЧООПА | dnsmasq-pi-hole-2.85 | 2021-10-02 16:25:35 UTC | действительный | 100% | Кто |
| 157.230,35,44 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.85 | 2021-10-02 16:17:55 UTC | действительный | 100% | Кто |
| 172.105.116.181 li2009-181.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.80 | 2021-10-02 16:14:55 UTC | действительный | 100% | Кто |
| 128.199.169.223 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.85 | 2021-10-02 16:14:38 UTC | действительный | 100% | Кто |
| 172.104.163.154 li1754-154.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.85 | 2021-10-02 00:32:57 UTC | действительный | 100% | Кто |
| 128.199,98,97 s1.lvl24.net. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.84 | 2021-10-02 00:32:33 UTC | действительный | 100% | Кто |
| 54.251.219.92 ec2-54-251-219-92.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-02 00:27:02 UTC | действительный | 100% | Кто |
| 134.209.97.229 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-02 00:21:30 UTC | действительный | 100% | Кто |
| 139.180.159.227 139.180.159.227.vultr.com. | Сингапур | 20473 АС-ЧООПА | dnsmasq-пи-отверстие-2.86 | 2021-10-02 00:20:11 UTC | действительный | 100% | Кто |
| 139.162.36.231 li1449-231.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.85 | 2021-10-02 00:18:40 UTC | действительный | 100% | Кто |
| 20.188.121.43 | Сингапур | 8075 МИКРОСОФТ-КОРП-MSN-AS-БЛОК | dnsmasq-пи-отверстие-2.86 | 2021-10-02 00:13:25 UTC | действительный | 100% | Кто |
| 209.97.173.243 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.87test2 | 2021-10-02 00:07:54 UTC | действительный DNSSEC | 100% | Кто |
| 209.97.163.58 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.85 | 2021-10-02 00:07:24 UTC | действительный | 100% | Кто |
| 58.185.2.212 lawoc-dns.lawsoc.org.sg. | Сингапур | 3758 SingNet | — | 2021-10-02 00:06:40 UTC | действительный | 60% | Кто |
| 139.180.185.166 139.180.185.166.vultr.com. | Сингапур | 20473 АС-ЧООПА | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:57:23 UTC | действительный | 100% | Кто |
| 139.59,193,77 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.84 | 2021-10-01 23:53:12 UTC | действительный | 100% | Кто |
| 13.229.32.53 ec2-13-229-32-53.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-01 23:52:31 UTC | действительный | 100% | Кто |
| 139.162,52,43 li1465-43.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.84 | 2021-10-01 23:50:27 UTC | действительный | 100% | Кто |
| 104.248.99.145 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-01 23:50:03 UTC | действительный | 100% | Кто |
| 172.104.167.19 li1758-19.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.80 | 2021-10-01 23:44:01 UTC | действительный | 100% | Кто |
| 172.104.54.13 li1634-13.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.80 | 2021-10-01 23:40:13 UTC | действительный | 100% | Кто |
| 128.199.136.201 pi-hole.pgnwis.com. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.84 | 2021-10-01 23:38:14 UTC | действительный | 100% | Кто |
| 52.74.238.51 ec2-52-74-238-51.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-01 23:38:00 UTC | действительный | 100% | Кто |
| 18.141.203.63 ec2-18-141-203-63.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-01 23:37:24 UTC | действительный | 100% | Кто |
| 52.148.95.11 | Сингапур | 8075 МИКРОСОФТ-КОРП-MSN-AS-БЛОК | dnsmasq-pi-hole-2.79 | 2021-10-01 23:36:04 UTC | действительный DNSSEC | 100% | Кто |
| 210.16.120.47 | 7489 HostUS | dnsmasq-pi-hole-2.85 | 2021-10-01 23:32:13 UTC | действительный | 100% | Кто | |
| 159.65.14.150 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:30:28 UTC | действительный | 100% | Кто |
| 188.166.225.103 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:29:52 UTC | действительный | 100% | Кто |
| 167.99.77.116 backups.do. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.81 | 2021-10-01 23:28:16 UTC | действительный | 100% | Кто |
| 139.99,40,84 vps-2a9dcdeb.vps.ovh.ca. | Сингапур | 16276 OVH SAS | dnsmasq-pi-hole-2.85 | 2021-10-01 23:28:00 UTC | действительный | 100% | Кто |
| 139.59.107.147 sgp1.wgmesh.do.juroct.net. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:25:32 UTC | действительный | 100% | Кто |
| 128.199.125.43 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.85 | 2021-10-01 23:25:21 UTC | действительный | 100% | Кто |
| 68.183.235.124 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-01 23:22:59 UTC | действительный | 100% | Кто |
| 54.179.254.32 ec2-54-179-254-32.ap-southeast-1.compute.amazonaws.com. | Сингапур | 16509 АМАЗОН-02 | dnsmasq-pi-hole-2.85 | 2021-10-01 23:22:55 UTC | действительный | 100% | Кто |
| 132.147.92.141 fnet141-f92-access.vqbn.com.sg. | Сингапур | 18106 Viewqwest Pte Ltd | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:22:34 UTC | действительный | 100% | Кто |
| 128.199.220.109 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:21:01 UTC | действительный | 100% | Кто |
| 47.241.117.144 | Сингапур | 45102 Alibaba US Technology Co., Ltd. | dnsmasq-pi-hole-2.85 | 2021-10-01 23:19:21 UTC | действительный | 100% | Кто |
| 157.230.35.194 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.85 | 2021-10-01 23:18:35 UTC | действительный | 100% | Кто |
| 157.230.244.240 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-01 23:17:37 UTC | действительный | 100% | Кто |
| 128.199.255.156 отверстие02.do01.bz05866. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.87test3 | 2021-10-01 23:15:52 UTC | действительный | 100% | Кто |
| 209.182.237.210 | Сингапур | 29802 HVC-AS | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:14:32 UTC | действительный | 100% | Кто |
| 139.99.38.167 ip167.ip-139-99-38.net. | Сингапур | 16276 OVH SAS | dnsmasq-pi-hole-2.85 | 2021-10-01 23:13:24 UTC | действительный | 100% | Кто |
| 192.46.230.27 li2189-27.members.linode.com. | Сингапур | 63949 Линод, ООО | dnsmasq-pi-hole-2.80 | 2021-10-01 23:12:04 UTC | действительный | 100% | Кто |
| 167.99,72,249 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.87test2 | 2021-10-01 23:09:01 UTC | действительный | 100% | Кто |
| 178.128.22.242 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-01 23:08:08 UTC | действительный | 100% | Кто |
| 139.180.215.174 139.180.215.174.vultr.com. | Сингапур | 20473 АС-ЧООПА | dnsmasq-pi-hole-2.85 | 2021-10-01 23:07:25 UTC | действительный | 100% | Кто |
| 206,189,87,85 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:05:28 UTC | действительный | 100% | Кто |
| 165.22.110.221 sgp.wireguard.do.juroct.net. | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 2021-10-01 23:04:47 UTC | действительный | 100% | Кто |
| 165.22.241.78 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-pi-hole-2.80 | 2021-10-01 23:01:20 UTC | действительный | 100% | Кто |
| 52.163,82,71 | Сингапур | 8075 МИКРОСОФТ-КОРП-MSN-AS-БЛОК | dnsmasq-pi-hole-2.81 | 29.09.2021 11:47:55 UTC | действительный | 100% | Кто |
| 66.42.60.59 66.42.60.59.vultr.com. | Сингапур | 20473 АС-ЧООПА | dnsmasq-pi-hole-2.85 | 29.09.2021 11:47:40 UTC | действительный | 100% | Кто |
| 139.59.114.43 | Сингапур | 14061 DIGITALOCEAN-ASN | dnsmasq-пи-отверстие-2.86 | 29.09.2021 11:46:24 UTC | действительный | 100% | Кто |
| 34.126.94.164 164.94.126.34.bc.googleusercontent.com. | Сингапур | 15169 GOOGLE | — | 26.09.2021 15:44:02 UTC | действительный | 100% | Кто |
| 202.136.162.12 dns03.ntts-idc.net.sg. | 17645 NTT СИНГАПУР PTE LTD | никто | 25.09.2021 22:00:55 UTC | действительный | 100% | Кто | |
| 202.136.163.11 dns02.ntts-idc.net.sg. | 17645 NTT СИНГАПУР PTE LTD | никто | 25.09.2021 00:03:32 UTC | действительный | 100% | Кто | |
| 210.80,58,66 cache300.ns.uu.net. | 703 УУНЕТ | — | 2021-09-24 04:31:04 UTC | действительный DNSSEC | 100% | Кто | |
| 202.56.128.30 pridns.d1.com.sg. | Сингапур | 9656 Т-СИСТЕМС СИНГАПУР PTE LTD | 9.11.22 | 13.05.2021 06:31:40 UTC | действительный | 99% | Кто |
| 103.86.99.100 | Сингапур | 136787 TEFINCOM S.A. | — | 2021-05-11 20:28:05 UTC | действительный DNSSEC | 86% | Кто |
| 172.104.59.35 dns.vaguthu.mv. | Сингапур | 63949 Линод, ООО | — | 23-04-2021 22:24:58 UTC | действительный DNSSEC | 98% | Кто |
Страница не найдена — ScienceDirect
Пандемия COVID-19 и глобальное изменение окружающей среды: новые потребности в исследованиях
Environment International, том 146, январь 2021 г., 106272
Роберт Баруки, Манолис Кожевинас, […] Паоло Винеис
Исследование количественной оценки риска изменения климата в городском масштабе: обзор последних достижений и перспективы будущего направления
Обзоры возобновляемых и устойчивых источников энергии, Том 135, Январь 2021 г., 110415
Бинь Йеа, Цзинцзин Цзян, Чжунго Лю, И Чжэн, Нань Чжоу
Воздействие изменения климата на экосистемы водно-болотных угодий: критический обзор экспериментальных водно-болотных угодий
Журнал экологического менеджмента, Том 286, 15 мая 2021 г., 112160
Шокуфе Салими, Сухад А.A.A.N. Алмуктар, Миклас Шольц
Обзор воздействия изменения климата на общество в Китае
Достижения в исследованиях изменения климата, Том 12, выпуск 2, апрель 2021 г., страницы 210-223
Юн-Цзянь Дин, Чен-Ю Ли, […] Цзэн-Ру Ван
Общественное мнение об изменении климата и готовности к стихийным бедствиям: данные Филиппин
2020 г.
Винченцо Боллеттино, Тилли Алкайна-Стивенса, Манаси Шарма, Филип Ди, Фуонг Пхама, Патрик Винк
Воздействие бытовой техники на окружающую среду в Европе и сценарии снижения их воздействия
Журнал чистого производства, Том 267, 10 сентября 2020 г., 121952
Роланд Хишье, Франческа Реале, Валентина Кастеллани, Серенелла Сала
Влияние глобального потепления на смертность апрель 2021 г.
Раннее человеческое развитие, Том 155, апрель 2021 г., 105222
Жан Каллея-Агиус, Кэтлин Инглэнд, Невилл Каллеха
Понимание и противодействие мотивированным корням отрицания изменения климата
Текущее мнение об экологической устойчивости, Том 42, февраль 2020 г., страницы 60-64
Габриэль Вонг-Пароди, Ирина Фейгина
Это начинается дома? Климатическая политика, нацеленная на потребление домашних хозяйств и поведенческие решения, является ключом к низкоуглеродному будущему
Энергетические исследования и социальные науки Том 52, июнь 2019, страницы 144-158
Гислен Дюбуа, Бенджамин Совакул, […] Райнер Зауэрборн
Трансформация изменения климата: определение и типология для принятия решений в городской среде
Устойчивые города и общество, Том 70, июль 2021 г., 102890
Анна К. Херлиманн, Саре Мусави, Джеффри Р. Браун
«Глобальное потепление» против «изменения климата»: повторение связи между политической самоидентификацией, формулировкой вопроса и экологическими убеждениями.
Журнал экологической психологии, Том 69, июнь 2020, 101413
Алистер Раймонд Брайс Сауттер, Рене Мыттус
Сбои подключения TLS — Stubby — Отчеты об ошибках
ДалееDNS
Примеркопать.com @ 127.0.0.1
; << >> DiG 9.11.5-P4-5.1 + deb10u5-Debian << >> example.com @ 127.0.0.1
;; глобальные параметры: + cmd
;; Получил ответ:
;; — >> HEADER << - код операции: QUERY, статус: SERVFAIL, id: 13951
;; флаги: qr rd; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНО: 0
;; ВНИМАНИЕ: рекурсия запрошена, но недоступна
;; РАЗДЕЛ ВОПРОСОВ:
; example.com. IN A
;; Время запроса: 2003 мс
;; СЕРВЕР: 127.0.0.1 # 53 (127.0.0.1)
;; КОГДА: Чт, 26 августа, 22:34:19 AWST 2021
;; РАЗМЕР MSG rcvd: 29
Конфиг
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
—
GETDNS_TRANSPORT_TLS tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 0
idle_timeout: 5000
tls_connection_retries: 5
tls_backoff_time: 900
таймаута: 2000
round_robin_upstreams: 1
#tls_min_version: GETDNS_TLS1_3
listen_addresses:
— 127.0.0.1
— 0 :: 1
upstream_recursive_servers:
— address_data: 45.90.28.0
tls_auth_name: «xxxxxx.dns1.nextdns.io»
— address_data: 45.90.30.0
tls_auth_name: «xxxxxdns.next»
Бревно
[14: 34: 12.
0] STUBBY: чтение конфигурации из файла stubby_noipv6.yml
[14: 34: 12.
[14: 34: 12.2] STUBBY: список транспорта:
[14:34 : 12.
[14:34:12.8] STUBBY: строгий профиль использования конфиденциальности (требуется аутентификация)
[14: 34: 12.
[14: 34: 12.
3] STUBBY: запуск DAEMON ….
[14: 34: 17.436308] STUBBY: 45.90.28.0: Коннект открыт: TLS — строгий профиль
[14: 34: 17.551961] STUBBY: 45.90.28.0: Подтвердить успешно: TLS
[14:34: 19.437698] STUBBY: 45.90.28.0: соединение закрыто: TLS — Resps = 0, Timeout = 1, Curr_auth = Success, Keepalive (ms) = 0
[14:34:19.437771] STUBBY: 45.90.28.0: восходящий поток: TLS — Resps = 0, таймауты = 1, Best_auth = Success
[14: 34: 19.437787] STUBBY: 45.90.28.0: восходящий поток: TLS — Conns = 1, Conn_fails = 0, Conn_shuts = 0, отсрочки = 0
Напротив, используя 1.1.1.1:
dig example.com @ 127.0.0.1
; << >> DiG 9.11.5-P4-5.1 + deb10u5-Debian << >> example.com @ 127.0.0.1
;; глобальные параметры: + cmd
;; Получил ответ:
;; — >> HEADER << - код операции: QUERY, статус: NOERROR, id: 46405
;; флаги: qr rd ra ad; ЗАПРОС: 1, ОТВЕТ: 1, АВТОРИТЕТ: 0, ДОПОЛНИТЕЛЬНО: 1
;; ОПТ-ПСЕВДОЗРЕНИЕ:
; EDNS: версия: 0, флаги :; UDP: 1232
;; РАЗДЕЛ ВОПРОСОВ:
; example.com. IN A
;; РАЗДЕЛ ОТВЕТОВ:
example.com. 71169 ИН А 93.184.216.34
;; Время запроса: 34 мсек
;; СЕРВЕР: 127.0.0.1 # 53 (127.0.0.1)
;; КОГДА: Чт, 26 августа, 22:44:20 AWST 2021
;; MSG SIZE rcvd: 67
Мониторинг Yeti с помощью RIPE Atlas
Одна из тем в повестке дня исследования Yeti DNS касается проблем масштабирования корневого каталога DNS. Однако, когда разные люди говорят о проблеме масштабирования корня, они могут иметь в виду разный контекст. Один касается увеличения и воздействия корневой зоны [1] [2], что тесно связано с программой ICANN New gTLD. Другой — о том, как повсеместно реплицировать и распространять файл корневой зоны [4] [5].Yeti считается более поздним сценарием, но в сочетании с рассмотрением вопросов внешней зависимости и риска наблюдения.
В отличие от соответствующих обсуждений и предложений, Yeti применяет простой подход, устанавливая 25 корневых серверов имен только для IPv6 сверх ограничения магического числа «13». На данный момент наша система мониторинга и конечные пользователи, принявшие сознательное решение присоединиться к экспериментальной, непроизводственной системе, не сообщили о заметных сбоях в работе системы.
В этой статье кратко рассматривается «magic 13» для аудитории без фона, исследуется подходящее число и рассказывается о том, что происходит в Yeti.
Краткая история магического числа «13»
У людей есть вопросы по ограничению количества DNS-серверов. Типичный случай — это 13 корневых букв, имя сервера корня («.»). Помню, 5 лет назад я был тем парнем, который задавал публике именно такие вопросы: «почему всего 13 корневых букв». Сегодня на открытой конференции ICANN RSSAC и в соответствующем списке рассылки вопрос время от времени все еще не решается. Из моего 5-летнего опыта работы с проблемами корня DNS я вижу как минимум 2 аспекта, в которых люди осторожны при масштабировании системы серверов имен DNS, особенно корня.(Дополнительная информация по этой теме Корень DNS и RSSAC028)
1) Исторический выбор и инерция в эксплуатации
RFC1035 часто называют «инициатором» ограниченного пространства для сообщений DNS по UDP. Потому что в то время, 30 лет назад, плохое состояние сети не поддерживало большие датаграммы или фрагменты, частично из-за ограниченного буфера хоста. IPv4 MTU составляет 576 октетов, что требует правильного ограничения размера сообщения DNS. RFC1035 дает выход: если длина сообщения DNS превышает 512 октетов, оно должно быть усечено, запрашивая DNS-запрос по TCP.
С эксплуатационной точки зрения UDP предпочтительнее TCP в качестве протокола передачи для DNS из-за соображений производительности. Так что не превышение предельного размера (512 октетов) стало практическим выбором в то время. Кроме того, это операционная инерция, когда ожидается, что ответ на запрос NS (например, запрос на загрузку) всегда будет нести полную информацию о сервере NS, как записи NS, так и адреса. По-другому это ограничивает количество NS-записей.
После введения IPv6 и DNSSEC нормальный ответ, содержащий все адреса IPv4 / IPv6 и подпись DNSSEC, уже превысил 512 октетов.Ограничение на размер в 512 октетов уже давно прошло. Тем не менее, «Magic 13» как операционный выбор и инерция не была ослаблена даже после того, как EDNS0 была представлена и широко использовалась в течение всех этих лет.
Обратите внимание, что, когда в эти годы стало популярным управление Интернетом, тема «более корневого доступа» стала деликатной политической темой, а инерция усложнилась.
2) Проблема фрагментации IPv6 в DNS
IPv6 имеет модель фрагментации, отличную от IPv4 — в частности, фрагментация всегда происходит на отправляющем узле, а не на промежуточном маршрутизаторе.Фрагментация может вызвать серьезные проблемы; если один фрагмент потерян, это приводит к потере всей дейтаграммы, частью которой был этот фрагмент, а в DNS часто запускается тайм-аут. На данный момент известно, что только ограниченное количество реализаций промежуточного ящика безопасности поддерживает фрагменты IPv6.
Некоторые общедоступные измерения и отчеты [draft-taylor-v6ops-fragdrop], [RFC7872] показывают, что существует значительная скорость отбрасывания пакетов из-за неправильного обращения с промежуточным ящиком на фрагменте IPv6.Одно исследование APNIC [IPv6-frag-DNS] показало, что 37% конечных точек, использующих преобразователь DNS с поддержкой IPv6, не могут получать фрагментированный ответ IPv6 через UDP.
Некоторые корневые серверы (A, B, G и J) усекают ответ, когда размер большого пакета IPv6 превышает 1280 октетов, чтобы избежать проблемы фрагментации IPv6 во время процесса обновления ключа ICANN KSK. Другое исследование APNIC показывает, что во избежание фрагментации, превышающей максимальный размер пакетов Ethernet в 1500 октетов, 1500 октетов станут новым ограничением размера для пакетов DNS, учитывая широкое распространение EDNS0.
Ограничение в 13 записей NS все еще применяется?
После анализа, приведенного выше, вместо 512 октетов кажется практичным и безопасным пределом размера 1500 октетов, позволяющим избежать фрагментации исходящих пакетов как для IPv4, так и для IPv6. Другой расчет необходим, чтобы определить, сколько записей NS (N) можно разместить в этом ограничении размера.
- Заголовок: 12 октетов
--Вопрос: 5 октетов
--Ответ: 31 + 15 * (N-1) октетов [расчетная база по текущей схеме именования: x.root-server.net, который можно сжимать]
--Дополнительно: 16 * N + 28 * N [каждая запись A составляет 16 байтов, а каждая запись AAAA - 28 байтов]
Если 512 октетов все еще применимы, мы должны получить N в следующей формуле:
12 + 5 + 31 + 15 * (N-1) + 16 * N + 28 * N <512, тогда максимальное N = 8
Если мы поставим 1452 октета (1500-40-8) в качестве ограничения размера, мы получим N = 24. Если корни только IPv6, мы получили:
12 + 5 + 31 + 15 * (N-1) + 28 * N <1452, тогда максимальное N = 33
Если учесть подпись DNSSEC (RSA / SHA-256) в ответе, когда бит DO установлен в запросе NS, тогда в пакете DNS требуются дополнительные 286 октетов (RRSIG) и 11 октетов (OPT RR).Тогда мы получили N = 19 для двойного стека, N = 26 для IPv6-only.
Стоит отметить, что все приведенные выше вычисления основаны на предположении, что ответ на запрос NS содержит все записи NS и информацию об адресе. Согласно разделу 4.2 RFC8109, если дополнительный раздел ответа DNS может опускать определенную информацию об адресе корневого сервера, рекурсивный преобразователь может выдавать прямые запросы для A и AAAA RRset для оставшихся имен. Таким образом, если адресная информация не требуется или требуется частично в ответе, остается больше места для переноса NS-записей.На стенде Yeti DNS бывают случаи, когда сервер возвращает только NS-записи или возвращает небольшую часть адресной информации.
На вопрос «Действует ли ограничение в 13 NS-записей?». Можно с уверенностью сказать, что технический предел в 13 записей NS уже давно прошел, но инерция работы в сознании людей существует.
Тест производительности для многих серверов NS
Поскольку ограничение размера DNS принимает UDP в качестве протокола передачи по умолчанию. Люди могут подумать об использовании TCP или DOH (DNS поверх HTTP), чтобы выйти за пределы ограничений.Чтобы понять разницу в производительности UDP и TCP со многими серверами NS, мы проводим для этой цели простой лабораторный тест.
Конфигурация проста: клиент напрямую подключен к серверу (Dell R320, 8G DDR, CentOS6.4, BIND9.9.5). Клиент использует querytcp и queryperf для запуска запросов через TCP и UDP соответственно. tcp_client установлен в значение 10000 в named.conf. Имя в NS-записи строится в формате «x.root-servers.net», в котором x - натуральное число, начинающееся с 1.Когда в NS RR добавляются новые имена, мы записываем qps в качестве показателей производительности. Поскольку EDNS0 поддерживает 4096 октетов, большее количество имен (более 270 имен) вызовет усечение и откат к TCP. Таким образом, мы тестируем только от 13 до 200 имен, чтобы изучить тенденцию. На диаграмме ниже показано, что размер пакетов увеличивается, а количество запросов в секунду для UDP DNS быстро уменьшается.
Независимо от проблемы фрагментации, использование UDP или TCP со многими записями NS повлияет на QPS полномочного сервера.Кроме того, существует опасение, что слишком большое количество записей может потребовать дополнительных ресурсов на рекурсивном сервере для отслеживания состояния каждого сервера, выполнения RTT-сортировки и записи поддержки EDNS0 и т. Д.
Для современного распознавателя ресурсы, связанные с ЦП и ОЗУ, не являются узким местом по сравнению с тайм-аутом и задержкой из-за сбоев сети и переключения с одного сервера имен на другой. Таким образом, практичный и безопасный выбор - продолжать хранить фиксированное количество записей NS (но не 13) и возвращать как можно больше адресной информации, если выбран UDP.
Я действительно рекомендую выбрать TCP или DOH для большого ответа DNS. Это заслуживает особого отношения, особенно в отношении IPv6 DNS. Однажды в технической статье было рассказано, что Ali-Cloud использует эластичную сеть безопасности для защиты от DDOS-атак. Ключевая идея заключается в том, что его система, похожая на DNS, может возвращать тысячи динамических записей NS и A для своих сервисов.
Чемодан Yeti с 25 серверами имен
Как уже было сказано, у Yeti 25 корневых серверов. Люди могут спросить также, почему 25? Это, по-видимому, объясняется предыдущими расчетами для корня IPv6-only, меньшего и равного 26 в пределах ограничения размера пакета в 1500 октетов, содержащих необходимую подпись и opt RR.Фактически Yeti разработал до 25 корневых серверов без такой конструкции.
Ожидалось, что многие варианты экспериментального дизайна Yeti вызовут более широкий отклик:
1) Выбрать корневую схему именования (произвольная форма) не может быть сжато.
2) Ввести дополнительные записи NS для первичного отклика увеличения корневой зоны, содержащего все записи NS и их связующее звено.
3) Эксперимент Yeti DNSSEC, такой как несколько ZSK, обновление KSK и повторное использование ключа IANA и RRSIG, значительно расширяет верхний набор DNSKEY RRSet.
Вначале мы не рассматривали предельный размер какой-либо формы. 25 является первоначальной целью разработки испытательного стенда Yeti, чтобы обеспечить справедливое распространение root на 5 континентах с квалифицированными и ответственными операторами. И число 25 также рассматривается как серьезное испытание для «Magic 13».
Когда Yeti разрабатывалась с 25 серверами, размер первичного ответа составлял до 1754 октетов с RRSIG и всей адресной информацией (с патчем Шейна), что превышает ограничение размера в 1500 октетов.Это подвержено риску фрагментации IPv6, наблюдаемой на испытательном стенде Yeti, у которого коэффициент отбрасывания пакетов составляет около 7%, если размер пакета превышает 1500 октетов. Но благодаря разнообразию тестовых стендов Yeti серверы Yeti по-разному реагируют в зависимости от локальной конфигурации и программного обеспечения DNS.
| Число | Оператор | Размер ответа | примечание |
|---|---|---|---|
| № 1 | БИИ | 1754 | фрагментирован со всеми клеевыми записями |
| № 2 | ШИРОКИЙ | 1782 | фрагментирован со всеми клеевыми записями |
| № 3 | TISF | 1782 | фрагментирован со всеми клеевыми записями |
| № 4 | AS59715 | 1222 | с частичным клеем, 1280 можно установить как предел |
| № 5 | Dahu Group | 1222 | с частичным клеем, 1280 можно установить как предел |
| № 6 | Бонд Интернет Системс | 1754 | фрагментирован со всеми клеевыми записями |
| № 7 | MSK-IX | 1054 | без клейкой записи |
| № 8 | CERT Австрия | 1054 | без клейкой записи |
| № 9 | ERNET | 1054 | без клейкой записи |
| № 10 | dnsworkshop / informnis | NA | NA |
| № 11 | Dahu Group | 2065 | фрагментирован всем клеем |
| № 12 | Аква Рэй SAS | 1222 | с частичным клеем, 1280 можно установить как предел |
| № 13 | ВЫКЛЮЧАТЕЛЬ | 1082 | нормальный ответ BIND9 без привязки записей |
| № 14 | ЧИЛИ НИК | 1054 | без клейкой записи |
| № 15 | BII @ Cernet2 | 1754 | вернуть все записи клея |
| № 16 | BII @ Cernet2 | 1754 | вернуть все записи клея |
| № 17 | BII @ CMCC | 1754 | вернуть весь клей |
| № 18 | Йети @ SouthAfrica | 1754 | фрагментированный возврат всех клеевых записей |
| № 19 | Йети @ Австралия | 1754 | фрагментированный возврат всех клеевых записей |
| № 20 | ERNET | 1054 | без клейкой записи |
| № 21 | ERNET | 1782 | фрагментирован со всеми клеевыми записями |
| № 22 | dnsworkshop / informnis | 1813 | фрагментирован со всеми клеевыми записями |
| № 23 | Monshouwer Internet Diensten | 1668 | фрагментирован всего с 22 клеевыми пластинами |
| № 24 | ДАТЕВ | 1222 | с частичным клеем, 1280 можно установить как предел |
| № 25 | jhcloos | 1222 | с частичным клеем, 1280 можно установить как предел |
Yeti DNS использует имена в произвольной форме для каждого корневого сервера, которые не могут быть сжаты.Согласно протоколу (реализация BIND9) не все клеящие записи необходимо включать в дополнительный раздел. Некоторые корневые серверы используют патч (разработанный Шейном Керром), содержащий все связующие записи, но ответ будет фрагментирован. Некоторые корневые серверы устанавливают 1280 октетов в качестве предельного размера IPv6-пакетов (1222 октета ответа), поэтому они будут содержать как можно больше адресной информации, пока ответ не достигнет предела. Мне интересно, почему никто не использует 1500 в качестве ограничения размера, которое полностью использует комнату для размещения большего количества адресов IPv6.
Что касается ответа сервера без клея, то он в вопросах, потому что все имена находятся под корнем. В дополнительном разделе должно быть не менее 2-х клейких записей. Насколько мне известно, BIND9 / Unbound работают, потому что они принимают адреса, перечисленные в файле подсказок, как доверенные клеевые записи. После проверки rfc1034 # section-5.3.3 подтверждается соответствие спецификации DND: «Если поиск NS RR завершается неудачно, распознаватель инициализирует SLIST с ремня безопасности SBELT». (Ремень безопасности SBELT - это локальный файл конфигурации, файл подсказки)
Заключение
В заключение, предел в 13 не применяется с технической точки зрения.Но у людей все еще есть инерция, что 13 - это фиксированное количество NS-записей. Теперь проблема фрагментации IPv6 вводит новый предел размера, который накладывает ограничение на размер ответа. Теперь практичный и безопасный выбор - сохранить ограничение 19 для двойного стека, 26 для только IPv6, принимая 1500 октетов в качестве ограничения на количество пакетов. Могут содержаться все записи клея. Если вы хотите добавить больше записей NS, вы потеряете некоторую доступность (меньше связанных записей).
Yeti взят в качестве примера в этом контексте. На стенде Yeti теперь 25 корневых серверов имен, что уже превысило лимит.Ответное поведение разных корневых серверов различается. Несмотря на то, что согласованность ответа DNS теряется, для целей тестирования полезно иметь разнообразие.
Система защищенного привратника на основе виртуального IP для Интернета вещей
Abstract
Преимущество использования устройства преобразования сетевых адресов заключается в том, что внутренний IP-адрес, который расширяет пространство IP-адресов устройств Интернета вещей (IoT), является невидимы снаружи и защищены от внешних атак.Однако использование этих частных IPv4-адресов создает проблемы обхода, особенно для мобильных IoT для работы с одноранговыми приложениями. Альтернативным решением является использование технологий IPv6 для будущих устройств Интернета вещей. Однако пакет IPv6, включая IPSec, слишком сложен для применения к устройству IoT, поскольку это технология, разработанная для пользовательского терминала с достаточной вычислительной мощностью. В этом документе предлагается привратник, который позволяет реальным IP-адресам IoT внутри одной и той же подсети не иметь явной адресации и быть видимым снаружи привратника.Каждое устройство IoT публикует свой виртуальный IP-адрес через сервер регистратора или систему доменных имен (DNS), с которыми гейткипер делится информацией о сопоставлении адресов. В то время как привратник поддерживает информацию о сопоставлении для локальных устройств IoT, сервер регистрации или DNS имеет информацию о сопоставлении глобального адреса, чтобы любой партнер мог получить доступ к информации о сопоставлении. Все входящие и исходящие пакеты должны проходить через привратник, отвечающий за преобразование адресов и проверку безопасности на входе.Этот документ направлен на применение нашей системы привратника к платформе беспилотных автомобилей, которая позволяет окружающим камерам Интернета вещей и автономным транспортным средствам безопасно, безопасно и быстро связываться друг с другом. Итак, в этом документе, наконец, анализируется влияние улучшения на задержку, чтобы показать, что наша система привратника гарантирует целевую задержку в 20 мс в среде каналов 5G.
Ключевые слова: привратник , виртуальный IP-адрес, одноразовый ключ AES, граничные эффекты для мобильных устройств, DNS
1.Введение
Современные умные города по-прежнему должны поддерживать устройства Интернета вещей (IoT), подключенные к сети IPv4. Трансляция сетевых адресов (NAT) изначально была изобретена для решения проблемы нехватки адресного пространства IPv4. Кроме того, NAT использовался, чтобы скрыть сеть и хосты от внешней сети. Преимущество использования устройства преобразования сетевых адресов (NAT) заключается в том, что внутренний IP-адрес, который расширяет пространство IP-адресов, невидим снаружи и защищен от внешних атак [1].Однако использование этих частных адресов IPv4 создает проблемы обхода, особенно для мобильных IoT для работы одноранговых приложений [2,3,4,5]. Обычные устройства NAT позволяют конечным узлам внутри локальных сетей не быть явно адресуемыми и видимыми. Мотивация NAT заключается в том, что все устройства в одной локальной сети могут изменять свои адреса и использовать только один IP-адрес (NAT-адрес), уведомляя об этом внешний мир.
В отличие от подхода NAT, каждое устройство в одном домене может использовать разные виртуальные IP-адреса для защиты от внешних атак.Хотя конечные узлы с NAT используют один и тот же IP-адрес с NAT, реальный адрес может быть сопоставлен со случайным виртуальным адресом, видимым для внешнего мира. Есть два существующих направления, связанных с виртуальным IP-адресом: метод защиты от подвижной цели (MTD) и метод балансировки нагрузки в массивной серверной ферме. Один из методов MTD был предложен для сетевой архитектуры на основе программно-определяемой сети (SDN) [6]. Когда IP-пакет от узла электронного блока управления (ECU) доходит до коммутатора SDN, контроллер SDN заменяет IP-адрес случайным виртуальным адресом, а затем виртуальный адрес используется для пересылки пакета.В последнем коммутаторе SDN виртуальный адрес преобразуется в исходный адрес и отправляется в целевой узел ECU [7]. Другой предлагаемый метод МПД на основе SDN направлен на защиту от атак с целью разведки и сканирования сети. Этот метод позволяет хост-машине иметь несколько случайных, изменяющихся во времени виртуальных IP-адресов. Виртуальный IP-адрес полезен для того, чтобы подсистемы балансировки нагрузки серверов могли легко масштабироваться для удовлетворения потребностей огромной фермы серверов по мере роста объема трафика и количества серверов в ферме серверов.Балансировщики нагрузки сервера могут быть масштабируемыми, если входящий трафик данных к шлюзу-маршрутизатору в центре обработки данных перенаправляется в соответствии с назначенным виртуальным IP-адресом [8].
Lightweight Machine-to-Machine (LwM2M) - это протокол для управления устройствами M2M или IoT и предоставления услуг. Стандарт LwM2M определяет протокол связи прикладного уровня между сервером LwM2M и клиентом LwM2M, расположенным в устройстве IoT. Он предлагает подход к управлению устройствами Интернета вещей и позволяет устройствам и системам от разных поставщиков сосуществовать в экосистеме Интернета вещей.Возможности управления устройствами LwM2M включают удаленное предоставление учетных данных безопасности, обновления прошивки, управление подключением, удаленную диагностику устройства и устранение неполадок. Между тем, модель одноранговой сети (P2P) для устройств IoT отличается от клиент-серверной архитектуры LwM2M. Либо датчикам IoT в локальной области, которые имеют выделенный спектр / локальную сеть, управляемую локальным шлюзом, либо приложениям IoT, которые охватывают области, охватывающие большую географическую область, требуются свои IP-адреса, которые легко перехватываются внешним злоумышленник.Первая цель этой статьи - предложить для них двойное использование виртуального IP-адреса и реального IP-адреса. В этом документе предлагается привратник сделать так, чтобы реальные IP-адреса IoT внутри локальных подсетей не были явно адресуемыми и видимыми извне привратника. Устройство IoT публикует свой виртуальный IP-адрес через сервер регистратора или систему доменных имен (DNS). Устройство IoT, привратник и сервер регистратора (или DNS) обмениваются информацией о взаимосвязи между реальным IP-адресом и виртуальным IP-адресом [9,10,11,12,13,14,15].Привратник поддерживает таблицу отображения адресов (AMT), в которой номер соответствия AMT указывает каждую запись, описывающую эту взаимосвязь.
Все входящие и исходящие пакеты должны проходить через привратник в качестве шлюза входа и выхода. В этой статье утверждается, что все устройства Интернета вещей в мире могут быть связаны с их распределенными привратниками. Затем привратник может защитить свои IoT-устройства от атак анализа трафика, которые пытаются сканировать IoT-устройства извне и анализировать их роль [16,17,18,19].Кроме того, поскольку привратник отвечает за проверки безопасности на входе, нижнее устройство IoT внутри привратника освобождается от бремени проверки того, является ли входящий пакет вредоносным. От имени устройства IoT привратник защищает от проникновения этого вредоносного пакета [20].
Устройства IoT могут использовать технологию IPv6 для совместной работы с привратником для использования двойных IP-адресов без использования устройств NAT. В системе привратника с IPv6 происходит преобразование 128-битного адреса, и 128-битная информация о сопоставлении должна обрабатываться на сервере регистратора или в DNS.Работа со 128-битной адресной информацией влияет на увеличение сложности системы привратника. Кроме того, пакет IPv6 слишком дорог в развертывании, в результате чего локальные сети плохо оснащены мобильностью и безопасностью, необходимыми в надежной среде IoT [21,22]. Безопасность интернет-протокола (IPSec) - это набор безопасных сетевых протоколов, который аутентифицирует и шифрует пакеты данных для защиты связи между двумя компьютерами по сети интернет-протокола (IP). Он часто используется в виртуальных частных сетях (VPN).Технология IPSec может быть решением для устройств IoT для управления сквозной безопасностью на сетевом уровне (уровень 3) [23,24]. В частности, IETF рекомендует использовать IPv6 в качестве протокола третьего уровня IoT, где использование IPSec является обязательным при использовании IPv6. В качестве основных функций IPSec IoT, использующие IPv6, должны управлять базой данных политик безопасности и управлением ассоциациями безопасности, чтобы указывать используемые алгоритмы безопасности и секретные ключи. Следовательно, технология IPsec слишком сложна для применения в устройстве IoT, поскольку это технология, разработанная для пользовательского терминала с достаточной вычислительной мощностью [25].Несмотря на то, что в настоящее время прилагается много усилий по разработке облегченных систем с асимметричными ключами, системы с асимметричными ключами (т. Е. Открытые / закрытые ключи) по-прежнему требуют слишком много вычислительных ресурсов для недорогого оборудования IoT [26,27,28,29,30 ]. Следовательно, очевидно, что SSL (Secure Socket Layer) / TLS (Transport Layer Security) не может применяться для обработки сквозной обработки безопасности для IoT [31,32].
На прикладном уровне система с симметричным ключом может предоставлять услуги конфиденциальности для защиты устройства IoT.Ключевым моментом здесь является совместное использование симметричного ключа между двумя конечными узлами. Решением может быть алгоритм обмена ключами Диффи-Хеллмана (DH). Обмен ключами DH - это метод безопасного обмена криптографическими ключами по общедоступному каналу. DH - один из первых практических примеров обмена открытыми ключами, реализованных в области криптографии. Само по себе соглашение о ключах Диффи – Хеллмана является протоколом согласования ключей без аутентификации. Обычно алгоритм DH уязвим для атак «человек посередине» (MITM) при обмене общедоступными значениями DH между двумя устройствами.Третья сторона может вмешаться посередине и манипулировать публичной ценностью ЦТ, обмениваемой друг с другом. Следовательно, алгоритм DH требует дополнительных дополнительных мер для аутентификации [33].
Во-вторых, вкладом этого документа является введение привратника, который может поддерживать сквозные безопасные сеансы между двумя IoT, расположенными за их привратниками. Проблемы безопасности, касающиеся конфиденциальности и аутентификации связи между узлами, решаются с помощью некоторой схемы безопасности, созданной привратником.В документе публичное значение DH устройства IoT также функционирует как соответствующий номер AMT его привратника. Если атака на общедоступное значение DH происходит во время фазы обмена ключами DH, преобразование [виртуальный IP-адрес / реальный IP-адрес] (или [реальный IP-адрес / виртуальный IP-адрес]) в привратнике не работает должным образом. В результате взаимное согласование ключа DH не удастся. Следовательно, привратник оказывает эффект полного блокирования атаки MITM при обмене ключами DH.
Третий вклад в этот документ относится к использованию граничных вычислений на безопасном привратнике.Обеспечение надежности входящих / исходящих сообщений для низкоуровневого IoT-устройства с ограниченной пропускной способностью возможно, если сервер в качестве третьей стороны включает в себя подтверждение вредоносности сообщения. Наш гейткипер на входе в локальную сеть действует как сторонний сервер. Тогда временная задержка связи, которая возникает при обмене данными между транспортными средствами (V2V) через систему привратника, может быть аналогична уровню прямой связи между устройствами (D2D). Эта идея похожа на систему 5G для перемещения вычислительных умов с центральных серверов на базовые станции 5G.Для взаимодействия критичных к задержкам приложений Интернета вещей требуется уровень задержки от 1 до 100 мс [34,35,36]. Беспилотные автомобили могут эффективно предотвращать внезапные аварии, если автомобили и расположенные рядом камеры Интернета вещей взаимодействуют для обмена временной информацией в режиме реального времени [37]. Устройства Интернета вещей, такие как транспортные средства или устройства камеры Интернета вещей, которые работают в локальной области, расположены в подсети в среде автономного вождения. На входе в подсеть их привратник ретранслирует входящие и исходящие пакеты между ними.Автономному транспортному средству требуется мгновенная информация от ближайших устройств Интернета вещей, таких как камеры Интернета вещей, которые оставляют поле зрения с минимальной задержкой в режиме реального времени. Задача нашей безопасной системы привратника - уменьшить задержку связи между устройствами, чтобы связь V2V, IoT-to-Vehicle (IoT2V) или Vehicle-to-IoT (V2IoT) обеспечивала требуемую задержку на уровне 20. РС. Предположим, автомобиль, проезжающий по городу со скоростью 60 км / ч, получает информацию о нештатной ситуации в течение 60 мс и справляется с ситуацией.В этом случае он может среагировать на расстоянии около 1 м. Этот документ направлен на ограничение задержки передачи данных IoT2V по сетям 5G в пределах 20 мс, делая реакцию возможной на расстоянии около 0,3 м.
показывает сравнение подходов NAT и привратника, которые используют невидимые IP-адреса конечных узлов (EN) извне. Операции NAT просты. Без какого-либо сотрудничества с другими системами устройство NAT решает сопоставить IP-адрес и номер порта пакетов в исходящем направлении с новым IP-адресом и номером порта, доступным для внешнего мира.Что касается входящих пакетов, NAT выполняет преобразование адреса и номера порта, обращаясь к этой информации сопоставления, созданной им самим. Сервер ретрансляции в системе NAT должен знать информацию о сопоставлении, необходимую для преобразования сетевых адресов. Другими словами, устройство NAT - это всего лишь исполнитель. Однако привратник передает информацию о сопоставлении адресов серверу регистрации или DNS. В то время как сервер регистрации или DNS имеет информацию о глобальном сопоставлении адресов, привратник поддерживает информацию о сопоставлении для локальных устройств IoT.Кроме того, привратник передает информацию, необходимую для управления безопасностью, серверу регистрации или DNS. В то время как система NAT требует других совершенно иных методов для управления безопасностью или граничных вычислений, привратник хранит информацию управления безопасностью. Он также является лидером в области периферийных вычислений для собственных устройств IoT. Таким образом, подход привратника позволяет перемещать необходимые вычисления для трансляции сетевых адресов и управления безопасностью с центральных серверов на привратники, расположенные на входах в подсеть.Использование привратников выгодно. Например, связь между двумя устройствами IoT, подключенными к одной подсети с использованием идентичного привратника, происходит через привратник. Однако внешний сервер ретрансляции должен быть задействован, даже если два соседних устройства за одним NAT могут обмениваться данными. Аналогичным образом, с точки зрения управления безопасностью, привратники могут выполнять управление безопасностью без помощи внешних серверов. Сервер ретрансляции системы NAT, который полностью отвечает за решение проблем обхода, обычно устанавливается и используется частным образом в коммерческих целях для приложений, связанных с NAT.Это сервер ретрансляции, который обычно используется в верхней части коммерческой вертикальной модели. С другой стороны, сервер регистрации или DNS в качестве горизонтального модельного центра предоставляет общедоступные услуги, чтобы гарантировать независимую работу распределенных привратников.
Сравнение подходов NAT и Gatekeeper, использующих невидимые извне IP-адреса.
Остальная часть этого документа организована следующим образом. В разделе 2 объясняются подходы к использованию виртуальных адресов, ориентированные на безопасный привратник.В разделе 3 этого документа объясняются три разные модели системы безопасного привратника для одноранговой связи, HTTP и IoT2V. В разделе 4 обсуждаются эффекты улучшения для безопасной системы привратника. Этот документ завершается разделом 5.
2. Безопасные подходы, ориентированные на привратник, с использованием виртуальных адресов
Реальные IP-адреса внутри привратника и частные IP-адреса внутри устройств NAT скрыты снаружи. Как показано на рисунке, помощь сервера ретрансляции важна для решения проблемы прохождения NAT для Интернета вещей с NAT.По сравнению с существующим подходом NAT, реальная разница заключается в том, что подход привратника позволяет переносить необходимые вычисления для трансляции сетевых адресов и управления безопасностью с любых центральных серверов на привратники, расположенные на входах подсети.
2.1. Существующие устройства NAT для сокрытия фактического адреса
Приложение, работающее на мобильных устройствах Интернета вещей, подключенных к Интернету из разных мест, не будет иметь фиксированного сетевого адреса. Кроме того, вызывает озабоченность то, как подключать одноранговые (P2P) приложения между двумя разными IoT между подсетями.Эти IoT могут подключаться к Интернету через устройство NAT, если устройства NAT используются для моста между сетями IPv4 и полными IPv6. Вот сценарий: приложению требуются TCP-соединения между двумя устройствами IoT, которые оба находятся за устройствами NAT. Проблема в том, что оба Интернета вещей получают частные IP-адреса и должны отправлять свои сообщения в общедоступный Интернет через устройства NAT. Устройство NAT использует преобразование портов, чтобы определить, какой IoT должен получать ответы. Например, когда устройство NAT получает сообщение с частного IP-адреса и исходного номера порта, оно отправляет сообщение через свой общедоступный IP-адрес на другой порт прокси, о котором известно только ему самому.Затем NAT поддерживает таблицу сопоставлений для потока исходящих пакетов. Однако за пределами Интернета вещей будут возникать трудности с получением информации об отображении NAT назначения, которая позволяет NAT назначения обрабатывать входящие пакеты. Популярные приложения P2P решают эту проблему прохождения NAT по-разному, поскольку проблема прохождения решается вместе с несколькими проблемами, связанными с безопасностью, мобильностью и масштабируемостью.
NAT хорошо подойдет для типичного взаимодействия клиент / сервер, поскольку всегда клиент инициирует сеанс связи.Однако в P2P медиаданные проходят напрямую между двумя одноранговыми узлами. Затем каждый одноранговый узел должен получить адреса общественного транспорта другого однорангового узла вместо своего частного адреса, чтобы установить сеанс для прохождения промежуточного устройства NAT. Устройства NAT, которые работают распределенным образом, не работают единообразно. Таким образом, для разработчика приложений P2P решить проблему обхода непросто.
Обычные устройства NAT позволяют конечным узлам внутри локальных сетей не быть явно адресуемыми и видимыми.Мотивация NAT заключается в том, что все устройства, которые могут изменять свои адреса в локальной сети, используют только один IP-адрес (NAT-адрес), уведомляя об этом внешний мир. Идея NAT заключается в использовании 16-битного поля номера порта для расширения адресного пространства. Таким образом, использование поля номера порта позволяет иметь около 60 000 одновременных подключений с одним NAT-адресом. Однако NAT вызывает споры, потому что устройства NAT должны обрабатывать до четвертого уровня, в то время как типичные маршрутизаторы обрабатывают до уровня 3. Устройство NAT хранит сопоставленную таблицу NAT, которая позволяет входящим и исходящим дейтаграммам изменять их номер порта источника и IP-адрес источника.Таким образом, сопоставленную таблицу NAT, содержащую динамически и локально изменяющуюся базу данных, трудно понять в одноранговой (P2P) сети, когда одноранговый узел хочет инициировать новый обмен данными с другим одноранговым узлом, подключенным к Интернету через NAT. Наиболее значительный недостаток состоит в том, что становится сложно отслеживать взаимные IP-адреса между двумя сквозными узлами. Когда они хотят настроить сеанс, каждая сторона должна получить IP-адрес другой стороны с NAT и внутренний IP-адрес, используемый внутри устройства NAT.Однако, если путь между ними включает несколько маршрутизаторов NAT, становится сложнее отслеживать их реальные IP-адреса. Если локальный узел работает с IP-адресом с NAT, другая сторона не может установить успешный сеанс с этим локальным узлом. Кроме того, маршрутизатор NAT сканирует заголовки уровней 3 и 4 проходящих пакетов, поэтому задержка переключения пути становится больше. Учитывая, что для беспилотного автомобиля, который работает в качестве одного из узлов Интернета вещей, требуются строгие условия по задержкам, для беспилотных транспортных средств непросто работать за маршрутизаторами NAT.
2.2. Предварительные условия для безопасной работы привратника
Существующая телефонная система SIP (протокол инициации сеанса) требует, чтобы сервер-регистратор идентифицировал людей по именам и достигал вызываемого, независимо от того, где перемещается вызываемый абонент, независимо от того, какое IP-устройство он использует в настоящее время. Наш сервер-регистратор может включать приложение для предоставления услуги разрешения имен для устройств IoT, а также пользователей SIP-телефонов. В то же время DNS - это приложение, предназначенное для службы разрешения имен.Затем и сервер-регистратор, и DNS поддерживают записи ресурсов, необходимые для разрешения сопоставления имени и реального адреса. Реальные IP-адреса могут использоваться для определения физического местоположения IoT. Эти адреса также действуют как идентификаторы Интернета вещей, позволяя злоумышленникам отслеживать их в Интернете. Однако наш сервер регистратора и DNS включают разрешение сопоставления имени / виртуального адреса. Запрос / ответ DNS (или сервера регистрации) между двумя разными узлами IoT позволяет инициирующему узлу IoT получить информацию о виртуальном адресе, соответствующую запрошенному имени.С другой стороны, исправление связи виртуального адреса с реальным адресом - это роль привратника. В этой статье не рассматриваются соединения L2 (уровня 2), установленные внутри подсети. Наш привратник всегда ретранслирует пакеты L3 от близких устройств IoT, таких как автомобили или устройства с камерой IoT, которые работают в локальной среде в автономной среде. Поскольку пакетами L3 между близкими устройствами IoT необходимо обмениваться через привратник, привратник может вести себя как защитный агент, компенсируя тот момент, когда устройства IoT не могут напрямую блокировать атаки вторжения вредоносных пакетов из-за их ограниченных вычислительных ресурсов.Привратник вмешивается в обмен данными между всеми устройствами IoT и отслеживает, появляются ли вредоносные пакеты в среде IoT. Этот момент является еще одной причиной, по которой этот документ нацелен на применение системы привратника для связи V2V, IoT2V или V2IoT. Поскольку привратник выполняет роль наблюдателя, автомобили могут доверять данным ближайшего устройства Интернета вещей и использовать их для автономного вождения. Тогда у внутреннего злоумышленника нет возможности атаковать беспилотный автомобиль через соединение L2.
показывает, как устройство IoT (имя - ENA, а доменное имя - ENA.utopia.com) получает информацию о своем адресе от привратника и регистрирует их на сервере регистрации или в DNS. Первоначальная процедура регистрации состоит из 3-х шагов.
Устройство IoT, привратник и сервер регистратора (или DNS) обмениваются информацией о взаимосвязи между реальным IP-адресом и виртуальным IP-адресом.
ШАГ 1: Предположим, конечный узел (EN) желает работать за каким-то привратником. Затем EN выбирает случайное целое число, то есть секретное значение (X_EN), и вычисляет соответствующее слепое значение, то есть Y_EN, где Y_EN = αX_ENmodq.В системе шифрования DH набор глобальных общедоступных элементов включает большое простое число q и целое число α, примитивный корень q . Размер секретных ключей может быть любым значением в диапазоне [1, q − 1]. Предполагая, что каждый привратник обрабатывает максимальное количество из 216 конечных узлов, размер простого числа q должен составлять 16 бит. Перед лицом потребности в новом IP-адресе EN запрашивает IP-адреса привратнику, отправляя его имя и скрытое значение, то есть EN и Y_EN.
ШАГ 2: После получения этого запроса гейткипер назначает реальный IP-адрес (rIP_EN) и виртуальный IP-адрес (vIP_EN) для Y_EN, что составляет новую запись в таблице сопоставления адресов (AMT). Затем привратник поддерживает тройные значения для EN:
16-битный Y_EN,
32-битный rIP_EN,
32-битный vIP_EN.
Конечный узел использует Y_EN в качестве значения шифрования DH для вычисления секретного ключа DH, в то время как привратник считает его совпадающим числом AMT, чтобы найти соответствующую запись в AMT.После получения вышеуказанных тройных значений от привратника EN поддерживает следующую структуру данных:
ШАГ 3: Как только EN получает свои rIP_EN и vIP_EN, он регистрирует эту распределенную информацию непосредственно на сервере регистрации или в AUthoritative (AU). сервер системы DNS. Таким образом, устройство IoT, привратник и сервер-регистратор (или DNS) обмениваются информацией о взаимосвязи между реальным IP-адресом и виртуальным IP-адресом.
2.3. Предлагаемый безопасный привратник
Привратник включает в себя выделение адресной информации в качестве ответа на запрос конечного узла и играет роль агента по изменению адресов заголовков для пакетов, проходящих через привратник.Привратник поддерживает таблицы отображения адресов (AMT). Каждая запись в AMT содержит информацию о сопоставлении [ Y , vIP, rIP], где слепое значение Y указывает на конкретную запись. Когда дейтаграмма от конечного узла проходит через привратник, она обрабатывает только поля заголовка третьего уровня. Для исходящей дейтаграммы и входящей датаграммы гейткипер выполняет преобразования rIP-vIP и vIP-rIP.
Как указано в, когда вызывающее устройство ENA хочет установить связь с вызываемым устройством ENB, ENA должен идентифицировать [соответствующий номер AMT, виртуальный IP-адрес] ENB.Затем ENA начинает процедуру запроса / ответа в отношении системы управления сеансом связи, выбранной устройством. После того, как ENA получит информацию [Y_ENB, vIP_ENB] ENB, ENA может отправить пакет в пункт назначения ENB. Когда ENA отправляет пакет, все четыре поля заголовка пакета, относящиеся к области адреса:
32-битный IP-адрес источника (S.IP),
32-битный IP-адрес назначения (D.IP ),
16-битный вариант 1 (Op.1), который является номером соответствия AMT привратника на стороне ENA для ENA и
16-битный вариант 2 (Op.2), который является номером соответствия AMT привратника на стороне ENB для ENB.
Проверка проходящих пакетов и преобразование IP-заголовков проходящих пакетов через привратник.
ENA отправляет пакет с заголовком [S.IP = rIP_ENA, D.IP = vIP_ENB, Op.1 = Y_ENA, Op.2 = Y_ENB]. Когда пакет достигает привратника на стороне ENA, он заменяет заголовок пакета на [S.IP = vIP_ENA, D.IP = vIP_ENB, Op.1 = Y_ENA, Op.2 = Y_ENB] и отправляет его в направлении пункт назначения.Когда пакет достигает привратника на стороне ENB, обычным образом проходя через Интернет, привратник гарантирует, что пакет квалифицирован для прохождения. То есть он проверяет, соответствует ли поле Op.2 пакета правильной записи в AMT. Напомним, что поле Op.2 содержит 16-битное слепое значение Y_ENB, на которое ответил сервер-регистратор или AUthoritative (AU) сервер DNS. Поскольку они сертифицируют 16-битное слепое значение только для пакета с сертифицированным слепым значением, привратник заменяет заголовок пакета на [S.IP = vIP_ENA, D.IP = rIP_ENB, Op.1 = Y_ENA, Op.2 = Y_ENB]. Проверенный пакет достигает ENB с IP-адресом назначения rIP_ENB.
2.4. Управление безопасностью
Самая простая и оригинальная реализация протокола DH использует мультипликативную группу целых чисел по модулю q , где q - простое число, а α - примитивный корень по модулю q . Эти два значения выбраны таким образом, чтобы гарантировать, что результирующий общий секрет может принимать любое значение от 1 до q − 1.На математическом уровне обмен ключами DH полагается на односторонние функции как основу своей безопасности. То есть ключ DH на стороне ENB (DHKB, A) вычисляется как Y_ENAX_ENBmodq, где Y_ENA = αX_ENAmodq. Это вычисления, которые просто выполнить в одном направлении, но гораздо сложнее произвести в обратном порядке. Здесь в секрете хранятся только X_ENB и X_ENA. Все остальные значения отправляются в открытом виде. Сила схемы проистекает из того факта, что для вычисления αX_ENA · X_ENBmodq = αX_ENB · X_ENAmodq требуется очень много времени, исходя только из знания q , α, αX_ENBmodq и αX_ENAmodq.Такая проблема называется проблемой дискретного логарифмирования. С другой стороны, вычисление αX_ENBmodq известно как модульное возведение в степень и может быть эффективно выполнено даже для больших чисел. Как только ENA и ENB вычисляют общий секрет, они могут использовать его в качестве ключа шифрования, известного только им, для отправки сообщений по одному и тому же открытому каналу связи.
Метод обмена ключами Диффи – Хеллмана позволяет двум сторонам, не зная друг друга заранее, установить общий секретный ключ по незащищенному каналу.Затем этот ключ можно использовать для шифрования последующих сообщений с использованием шифра с симметричным ключом. Само по себе базовое соглашение о ключах Диффи – Хеллмана является протоколом соглашения о ключах без аутентификации. Обычно алгоритм DH уязвим для атак MITM при обмене общедоступными значениями между двумя устройствами. Возможно, что третья сторона вмешается в середину и извлечет публичную ценность DH, которой обмениваются друг с другом. В нашей защищенной системе-привратнике сервер-регистратор (или DNS) хранит общедоступные значения DH для зарегистрированных устройств IoT, позволяя инициатору сеанса получать параметр DH другого однорангового узла при генерации общего ключа.Ответчик сеанса может извлечь общедоступное значение DH, которое содержится в сообщении запроса сеанса. Затем каждая сторона может совместно использовать один и тот же секретный ключ в зависимости от общедоступного значения DH однорангового узла и его самостоятельного секретного значения. Затем каждый конечный узел требует зарегистрировать свое общедоступное значение DH на сервере регистрации или в системе DNS.
Ниже мы объясняем схему аутентификации, выполняемую привратником. Если какой-либо узел может получить общедоступное значение DH целевого узла через сервер регистратора, злонамеренный объект также может получить его.Когда злонамеренный объект (A) использует его для достижения целевого узла (B), A должен представить значение DH B в качестве инициатора сеанса. То есть пакет запроса сеанса должен содержать значение DH B. Когда пакет достигает привратника стороны A, он преобразует реальный IP-адрес A в его виртуальный IP-адрес. Если объект является вредоносным, привратнику не удается выполнить преобразование адреса. Таким образом, злонамеренный объект не может успешно отправить запрос сеанса через свой привратник-источник, если он не использует свое справедливое общедоступное значение DH, которому доверяет сервер регистратора.Когда пакет достигает привратника стороны B, он преобразует виртуальный IP-адрес B в его реальный IP-адрес. Если публичное значение DH изменяется, привратнику не удается выполнить преобразование адреса. Таким образом, запрос сеанса не проходит через привратник назначения, если A пытается использовать общедоступное значение DH, отличное от справедливого общедоступного значения DH. Эта схема является нашей схемой аутентификации, созданной привратником.
С точки зрения безопасности, узел инициатора сеанса создает одноразовый номер на основе сеанса.Цель использования значения nonce - сделать окончательный симметричный ключ одноразовым сеансовым ключом и настроить размер окончательного симметричного ключа до 128 битов, которые можно применить к Advanced Encryption System (AES). Как показано в, ENA создает одноразовый номер (N_ENA размером 112 бит) и вычисляет ключ DH размером 16 бит, то есть DHKA, B = Y_ENBX_ENAmodq. И он объединяет ключ DH и одноразовый номер. В результате получается ключ AES размером 128 бит, то есть AESKA, B = DHKA, B || N_ENA. Прикладной уровень отправляемого пакета состоит из заголовка приложения и полезной нагрузки.Заголовок приложения содержит общедоступное значение в открытой форме (Y_ENA) и N_ENA, зашифрованное с помощью DHKA, B. Полезная нагрузка зашифрована с помощью AESKA, B. В качестве узла назначения ENB принимает пакет, извлекает первую часть заголовка приложения и получает Y_ENA. Затем ENB вычисляет ключ DH размером 16 бит, то есть DHKB, A = Y_ENAX_ENBmodq. И он расшифровывает вторую часть заголовка приложения с помощью ключа DH DHKB, A и получает N_ENA. Теперь ENB может создать свой ключ AES AESKB, A путем объединения DHKB, A и N_ENA.В результате ENB может расшифровать полезную нагрузку с помощью AESKB, A.
112-битный одноразовый номер, 16-битный ключ DH и 128-битный одноразовый ключ AES.
3. Защищенная система привратника
Поскольку существующие подходы NAT полагаются на серверы ретрансляции для решения проблем обхода, EN, как инициатор сеанса, должен получить необходимые параметры от внешних серверов для прохождения привратника на одноранговой стороне и осуществлять сквозное управление безопасностью. Система безопасного привратника (SGS) может работать тремя различными способами для получения этих параметров: RS SGS (система защищенного привратника на основе сервера регистрации), DNS SGS (система защищенного привратника на основе DNS) и SGS MEC (мобильные пограничные вычисления).RS SGS и DNS SGS предназначены для связи между привратниками, а MEC SGS - для связи внутри привратников внутри подсети. RS SGS и DNS SGS используют сервер регистрации и DNS для разрешения соответствующего виртуального IP-адреса и общедоступного значения DH для данного имени IoT, соответственно. Эффекты MEC SGS по сокращению задержки, особенно в среде беспилотных транспортных средств.
3.1. Система безопасного привратника на основе RS
показывает три различных режима работы SGS. показывает P2P (одноранговую) связь между двумя устройствами IoT, подключенными к разным привратникам.Вызывающее устройство использует процесс запроса / ответа для получения общедоступного значения DH вызываемого устройства и виртуального IP-адреса сначала через сервер регистрации. Имя вызывающего устройства - ENA, и его привратник хранит запись AMT [общедоступное значение DH = Y_ENA, виртуальный IP-адрес = vIP_ENA, реальный IP-адрес = rIP_ENA]. С другой стороны, имя вызываемого устройства - ENB, и его привратник поддерживает запись AMT [общедоступное значение DH = Y_ENB, виртуальный IP-адрес = vIP_ENB, реальный IP-адрес = rIP_ENB].Ниже мы перечисляем шаги по открытию безопасной одноранговой связи через систему Secure Gatekeeper на основе RS.
Безопасная одноранговая связь через систему Secure Gatekeeper на основе RS.
Таблица 1
Три различных режима работы защищенной системы привратника.
| Рабочие режимы | Типы защищенных сеансов | Основные характеристики | Надежная третья сторона |
|---|---|---|---|
| Защищенная на основе RS Привратник Система | Межсетевой сервер | 753 Защищенный сторож Реальный IP / виртуальный IP Преобразование | Сервер регистратора задействован |
| Защищенный на основе DNS Сторожевой сервер Система | Межсетевой сервер Защищенный соединения | На основе привратника Реальный IP / виртуальный IP Преобразование | 9475 DNS-сервер |
| на базе MEC Защищенный привратник Система | Intra-привратник Защищенные соединения | на основе привратника преобразование реального IP / виртуального IP и низкая задержка | DNS-сервер или сервер регистрации участвует |
- 900 13
После получения этого запроса сервер-регистратор ищет общедоступную информацию ENB [Y_ENB, vIP_ENB] в базе данных и отправляет (b) ответ на ENA в формате ответа.
Когда ENA получает информацию [Y_ENB, vIP_ENB] ENB, наконец, ENA пытается отправить пакет запроса сеанса в пункт назначения ENB. Используя значение раскрытия, полученное в ответе (Y_ENB), и секретное значение ENA (X_ENA), ENA вычисляет 128-битный ключ AES на стороне ENA, то есть AESKA, B = DHKA, B || N_ENA, где DHKA, B = Y_ENBX_ENAmodq.Для (c) пакета запроса сеанса (SReq), который должен быть отправлен, [Op.1 = Y_ENA, Op.2 = Y_ENB] составляет соответствующие поля заголовка пакета, касающиеся безопасности. Прикладной уровень пакета SReq состоит из заголовка приложения и полезной нагрузки. Заголовок приложения содержит общедоступное значение в открытой форме (Y_ENA) и N_ENA, зашифрованное с помощью DHKA, B. Полезная нагрузка зашифрована с помощью AESKA, B.
Когда этот зашифрованный пакет прибывает через Интернет на гейткипер, принадлежащий ENB, гейткипер проверяет поле заголовка пакета [Op.2 = Y_ENB] и находит фактический IP-адрес ENB. Здесь хакер не может изменить публичное значение Y_ENB. Если значение Y_ENB изменяется, пакет не может быть доставлен в ENB правильно.
Когда ENB принимает зашифрованный пакет, он извлекает значение поля [Op.1 = Y_ENA] и сравнивает его с общедоступным значением Y_ENA начала заголовка приложения. Если ENB подтверждает, что эти два значения совпадают, он считает, что Y_ENA из ENA защищен от хакерских атак. Используя извлеченную информацию об общедоступном значении Y_ENA и секретное значение X_ENB, ENB вычисляет симметричный ключ DHKB, A следующим образом.DHKB, A = Y_ENAX_ENBmodq. Затем ENB получает N_ENA путем дешифрования процесса с использованием ключа DH DHKB, A. Полезная нагрузка расшифровывается с помощью AESKB, A (DHKB, A || N_ENA). Наконец, ENB отправляет (d) Session OK, чтобы дать согласие на открытие безопасного сеанса.
В следующей двусторонней сквозной передаче данных поток зашифрованных данных проходит по пути через два разных привратника.
Вызывающее устройство ENA отправляет (a) запрос на сервер регистратора для получения информации об общедоступном значении и виртуальном IP-адресе ENB.
3.2. Система безопасного привратника на основе DNS
Идея системы защищенного привратника на основе DNS мотивирована тем фактом, что существующая система DNS может определять адрес названного устройства IoT.Однако исходный протокол HTTP не предназначен для IoT-подключений с удаленными местоположениями, где пропускная способность сети ограничена. Среди наиболее часто используемых протоколов приложений в IoT такие протоколы, как IPv6 через беспроводную персональную сеть с низким энергопотреблением (6LoWPAN) и протокол ограниченного приложения (CoAP), предоставляют функцию, с помощью которой интеллектуальные объекты IoT могут интегрироваться в сети, управляемые IP [38]. В этой статье рассматриваются некоторые прикладные протоколы в IoT, которые могут взаимодействовать с существующей системой DNS, и они называются своего рода интеллектуальными протоколами HTTP, в которых управляющее сообщение небольшого размера может нести несколько десятков байтов данных.
показывает, что устройство IoT использует симметричный ключ, сгенерированный безопасно, без использования SSL, чтобы обеспечить безопасную связь HTTP-запроса / HTTP-ответа через DNS. Здесь вызывающее устройство работает как клиент, а вызываемое устройство действует как сервер. Если какое-либо устройство знает имя вызываемого устройства, оно может получить информацию о сопоставлении имени и адреса вызываемого абонента через запрос / ответ системе DNS. Предположим, что имя вызывающего устройства - ENA. Привратник на стороне ENA поддерживает относящуюся к ENA запись AMT [общедоступное значение = YENA, виртуальный IP-адрес = vIP_ENA, реальный IP-адрес = rIP_ENA].Также имя вызываемого устройства - ENB. Привратник на стороне ENB поддерживает связанную с ENB запись AMT [общедоступное значение = Y_ENB, виртуальный IP-адрес = vIP_ENB, реальный IP-адрес = rIP_ENB]. Сервер AU поддерживает базу данных Resource Record (RR), где RR состоит из [Name, Value, Type, TTL (Time-To-Live)]. Предполагая, что ENB принадлежит домену utopia.com, на его авторитетном (AU) сервере хранятся две записи RR: первая и вторая, которые содержат [ENB.IoT.utopia.com, vIP_ENB, IoT, TTL] и [ENB.IoT.utopia.com, Y_ENB, IoT, TTL] соответственно.
Безопасная связь HTTP через систему Secure Gatekeeper на основе DNS.
Ниже мы перечисляем шаги по открытию безопасной одноранговой связи через систему Secure Gatekeeper на основе DNS.
Сначала ENA отправляет информацию DNS-запроса ENB.IoT.utopia.com на авторитетный сервер домена utopia.com (AU), который принадлежит ENB.
Сервер AU в домене utopia.com, который получил его, находит две RR для ENB в базе данных Resource Record (RR).
Сервер AU создает ответ DNS, содержащий эту информацию о двух RR, и отправляет его на ENA.
Когда ENA получает ответ DNS, он получает информацию [общедоступное значение = Y_ENB, виртуальный IP-адрес = vIP_ENB] из ответа DNS.
Наконец, ENA может отправить HTTP-запрос к ENB с [S.IP = rIP_ENA, D.IP = vIP_ENB, Op.1 = Y_ENA, Op.2 = Y_ENB]. Поскольку ENA надежно хранит свое секретное значение (X_ENA) и одноразовый номер (N_ENA), он вычисляет ключ DH размером 16 бит, то есть DHKA, B = Y_ENBX_ENAmodq.В результате процесса конкатенации получается ключ AES размером 128 бит, то есть AESKA, B = DHKA, B || N_ENA. Заголовок приложения пакета HTTP Req содержит общедоступное значение в открытой форме (Y_ENA) и N_ENA, зашифрованное с помощью DHKA, B.
Поскольку пакет HTTP Req проходит через привратник на стороне ENA, он меняет форму S.IP rIP_ENA на vIP_ENA.
Поскольку пакет HTTP Req проходит через привратник на стороне ENB, он меняет форму D.IP vIP_ENB на rIP_ENB. Когда пакет HTTP Req достигает привратника на стороне ENB, если Y_ENB из Op.2 отличается от поля исходного пакета при отправлении, пакет не сможет достичь конечного пункта назначения. Это потому, что неправильное значение Y_ENB вряд ли соответствует правильному rIP_ENB.
Когда ENB получает пакет HTTP Req, он сначала извлекает общедоступное значение Y_ENA из поля Op.1. Во-вторых, он извлекает соответствующее значение, которое включает в себя его заголовок приложения. Сравнивая эти два значения, ENB подтверждает, что источником пакета HTTP Req является ENA в случае, если эти два значения совпадают.С извлеченным общедоступным значением Y_ENA и секретным значением ENB X_ENB, ENB вычисляет симметричный ключ DHKB, A, используя уравнение Y_ENAX_ENBmodq. И он расшифровывает вторую часть заголовка приложения с помощью DHKB, A и получает N_ENA. Теперь ENB может вычислить свой AES-ключ AESKB, A, объединив DHKB, A и N_ENA. В результате ENB может расшифровать полезную нагрузку с помощью AESKB, A. Теперь ENB может отправлять HTTP-ответ на ENA с [S.IP = rIP_ENB, D.IP = vIP_ENA, Op.1 = Y_ENB, Op.2 = Y_ENA]. Кроме того, полезная нагрузка пакета HTTP-ответа содержит содержимое, зашифрованное с помощью AESKB, A.Когда HTTP-ответ приходит в ENA, он может расшифровать полезную нагрузку, используя секретный ключ AESKA, B, где AESKA, B = DHKA, B‖N_ENA.
3.3. Безопасная система привратника для связи V2V, IoT2V или V2IoT.
описывает безопасную систему привратника, которая может применяться к связи V2V и IoT2V. Предположим, что у регистрационного сервера или DNS-сервера AU уже есть адресная информация для автомобиля A (CARA) и автомобиля B (CARB), которые находятся в одной подсети. Затем привратник хранит запись [Y_CARA, vIP_CARA, rIP_CARA] для CARA и [Y_CARB, vIP_CARB, rIP_CARB] для CARB.Когда CARA отправляет пакет V2V в пункт назначения CARB, CARA использует процедуру запроса / ответа для получения адресной информации [Y_CARB, vIP_CARB] через сервер регистратора или систему DNS. Когда CARA отправляет пакет V2V в CARB, он использует значение Y_CARB, полученное запросом / ответом, и секретное значение X_CARA, которое CARA надежно хранит, для вычисления симметричного ключа DHKA, B с использованием функции Y_CARBX_CARAmodq. CARA генерирует одноразовый номер (N_CARA). Затем он создает ключ AES размером 128 бит, то есть AESKA, B = DHKA, B || N_CARA.При создании пакета V2V для отправки соответствующие поля IP-заголовка включают [S.IP = rIP_CARA, D.IP = vIP_CARB, Op.1 = Y_CARA, Op.2 = Y_CARB]. Заголовок приложения пакета V2V содержит общедоступное значение в открытой форме (Y_CARA) и N_CARA, зашифрованное с помощью DHKA, B. Полезная нагрузка прикладного уровня пакета V2V шифруется с использованием симметричного ключа AESKA, B, рассчитанного ранее. Таким образом, пакет V2V перемещается к месту назначения CARB. Когда гейткипер получает этот пакет, зная, что конечный пункт назначения находится в той же подсети, гейткипер ретранслирует его в CARB после операции Op.Процесс преобразования IP-адреса на основе 2 из S.IP = rIP_CARA и D.IP = vIP_CARB в S.IP = vIP_CARA и D.IP = rIP_CARB. Здесь хакерские атаки на публичное значение Op.2 бесполезны, потому что измененное значение публичного значения Op.2 определенно приводит к сбою сопоставления AMT на привратнике. Когда CARB получает зашифрованный пакет V2V, он извлекает общедоступное значение Op.1, то есть Y_CARA. Затем он вычисляет симметричный ключ DHKB, A, используя функцию Y_CARAX_CARBmodq. И он расшифровывает вторую часть заголовка приложения с помощью DHKB, A и получает N_CARA.Объединив DHKB, A и N_CARA, он может вычислить свой ключ AES AESKB, A. В результате он может расшифровать полезную нагрузку с помощью AESKB, A.
Связь V2V и IoT2V, ориентированная на привратник.
Во-вторых, давайте рассмотрим ситуацию, когда IoT-камера 1 (CAM1) отправляет срочную информацию в автомобиль A (CARA) через связь IoT-to-Vehicle в реальном времени. CAM1 может заранее получить информацию об адресе [Y_CARA, vIP_CARA] через сервер регистрации или систему DNS. Таким образом, в срочной ситуации CAM1 может отправить пакет IoT2V без процедуры запроса / ответа.CAM1 использует открытое значение Y_CARA и секретное значение X_CAM1 для вычисления симметричного ключа DHKC1, A с помощью функции Y_CARAX_CAM1modq. Следуя тем же шагам, что и в случае предыдущей связи V2V, CAM1 создает ключ AES (AESKC1, A = DHKC1, A || N_CAM1). Для отправки пакета IoT2V соответствующие поля IP-заголовка включают [S.IP = rIP_CAM1, D.IP = vIP_CARA, Op.1 = Y_CAM1, Op.2 = Y_CARA]. Заголовок приложения пакета IoT2V содержит общедоступное значение в открытой форме (Y_CAM1) и N_CAM1, зашифрованное с помощью DHKC1, A.Полезная нагрузка прикладного уровня пакета IoT2V зашифрована с использованием симметричного ключа AESKC1, A. Когда привратник получает пакет IoT2V, он ретранслирует пакет в CARA после изменения соответствующих полей заголовка IP. Когда CARA получает зашифрованный пакет IoT2V, он последовательно извлекает Y_CAM1, вычисляет симметричный ключ DHKA, C1, и создает свой ключ AES AESKA, C1. В результате он может расшифровать полезную нагрузку с помощью AESKA, C1.
4. Эффекты улучшения защищенной системы привратника
4.1. Проверка пакетов
В защищенной системе привратника EN, привратник и сервер регистратора (или система DNS) совместно используют общедоступное значение DH конечного узла. Сервер-регистратор или DNS вмешиваются, чтобы предоставить инициатору сеанса и респонденту сеанса общедоступное значение DH однорангового узла, которое уже им сертифицировано. Предположим, что информация этих трех не поддерживает согласованность для конкретного конечного узла. В этом случае другие узлы столкнутся с проблемами обхода из-за того, что не смогут пройти через привратник этого конечного узла для правильного достижения этого конечного узла.Любой узел может безопасно получить общедоступное значение DH другой стороны через сервер регистрации (или систему DNS). Однако инициатор сеанса должен содержать свое общедоступное значение DH в IP-заголовке отправляемого пакета. Когда респондент сеанса получает пакет, он проверяет его действительность с помощью механизма запросов / ответов на сервере регистратора (или в системе DNS). В этом документе не предполагается худшая ситуация, когда даже хакерский узел поддерживает согласованность своего общедоступного значения DH между хакерским узлом, своим привратником и сервером регистратора (или системой DNS).
Для узла инициатора сеанса (ENS) и узла ответчика сеанса (END), когда пакет с [Op.1 = Y_ENS] и [Op.2 = Y_END], который отправляется из ENS, прибывает через Интернет в привратник, принадлежащий END, привратник проверяет поле заголовка пакета [Op.2 = Y_END] и находит фактический IP-адрес узла назначения. Здесь внешний хакер не может изменить публичное значение Y_END. Если Y_END поля Op.2 отличается от поля исходного пакета при отправлении, пакет не сможет достичь конечного пункта назначения.Это влияет на то, что привратник блокирует ввод несертифицированных пакетов, потому что неправильное значение Y_END вряд ли соответствует правильному rIP_END. Таким образом, фактический процесс проверки пакета происходит в точке входа привратника назначения. Следующий сценарий относится к случаю, когда ENS является самим хакерским узлом (ENH). Когда пакет с [Op.1 = Y_ENH] и [Op.2 = Y_END], который отправляется из ENH, достигает привратника на стороне ENH, он проверяет поле заголовка пакета [Op.1 = Y_ENH]. Здесь привратник не сможет найти виртуальный IP-адрес хакерского узла, потому что хакерскому узлу сложно поддерживать согласованность своего общедоступного значения DH вместе с привратником и сервером регистратора (или системой DNS). Затем привратник сбросит пакет, имеющий недопустимое значение поля Op.1.
4.2. Аутентификация
В защищенной системе привратника сервер-регистратор или DNS вмешивается, чтобы предоставить инициатору сеанса общедоступное значение DH однорангового узла, которое они сертифицировали.Сервер-регистратор или DNS хранит общедоступное значение DH инициатора сеанса только в том случае, если он удостоверяет его. Затем респондент сеанса может решить, принимает ли он запрос сеанса или нет. В системе защищенного привратника сервер регистратора или DNS функционирует как сервер аутентификации, который предоставляет службу аутентификации ответчику сеанса. IoT-ответчик на сеанс аутентифицирует клиентский IoT, приближающийся к нему с их помощью. Предположим, что в сценарии атаки хакерский узел (ENH) отправляет вредоносный пакет запроса сеанса узлу IoT (ENB).Пакет пройдет привратник на стороне ENB, потому что даже хакер может получить доступ к общедоступной информации ENB [Y_ENB, vIP_ENB] в базе данных сервера регистратора. Однако, когда пакет прибывает в узел назначения (ENB), ENB извлекает идентификационный ENH из полезной нагрузки пакета и проверяет поле заголовка пакета [Op.1 = Y_ENH]. Здесь ENB может добавить процедуру аутентификации для проверки законности ENH, запросив ее на сервере регистратора ((d) и (e) in). Поскольку сервер-регистратор имеет сертифицированные общедоступные значения для всех IoT за распределенными привратниками, ENB объявит пробный сеанс как «Неаутентифицированный», если (e) Ответ неверен.Затем ENB отклоняет запрос сеанса от ENH. В результате любое устройство IoT может попытаться связаться с определенным одноранговым узлом IoT, потому что общедоступное значение DH однорангового узла становится общедоступным через сервер регистратора или DNS. Однако безопасный сеанс успешно установлен при справедливом условии, что общедоступное значение DH инициатора объявлено действительным с помощью процедуры запроса / ответа однорангового IoT.
Эффективность защищенной системы привратника против злонамеренных запросов сеансов.
4.3. Защита от атак анализа трафика
Привратник выделяет согласованную пару реального IP-адреса и виртуального IP-адреса каждому конечному узлу за ним.Для исходящих и входящих дейтаграмм гейткипер выполняет преобразования rIP-vIP и vIP-rIP. Когда два одноранговых узла обмениваются сигнальными сообщениями для установления сеанса, они могут скрыть свои идентификаторы или реальные IP-адреса. В течение периода передачи данных виртуальные адреса, видимые извне, не имеют отношения к соответствующим фактическим IP-адресам. Пока общедоступная ценность DH заслуживает доверия, наша безопасная система привратников способствует защите от атак анализа трафика.
Для подключений IoT трафик обычно несет управляющие сообщения небольшого размера.Атаки анализа трафика не могут не вывести ограниченную информацию об IP-адресе и имени устройства IoT. Следовательно, предлагаемый нами SGS почти безопасен против атак анализа трафика.
показывает параметры сигнализации, видимые злоумышленникам в трех разных случаях: RS SGS показан на, DNS SGS показан на и MEC SGS показан на. Отсутствует риск раскрытия важных параметров во время фазы сигнализации. Учитывая, что противнику открывается только слепое значение [Y_EN] в полезной нагрузке приложения, противник редко использует возможности для идентификации и атаки конкретного устройства.
Таблица 2
Информация, доступная хакерам.
| RS SGS () | [Y_ENA] в (c) |
| DNS SGS () | [Y_ENA] in (i) |
| MEC | (SGS )[Y_CARA] в (а) и (б) |
4.4. Надежность
Предположим, что датчики в автономных транспортных средствах и близлежащие камеры Интернета вещей обмениваются данными через соединения L2. В этом случае надежность полученных данных не может быть гарантирована, потому что, как правило, устройства IoT не обладают достаточной вычислительной мощностью, чтобы определить, прибывают ли вредоносные пакеты.Между тем, поскольку действие проверки происходит на основе перекрестного привратника, привратник заранее защищает от проникновения злонамеренных пакетов. Таким образом, датчики в автономных транспортных средствах и близлежащие камеры Интернета вещей могут безопасно взаимодействовать друг с другом с доверием без необходимости обнаружения вредоносных пакетов.
4.5. Конфиденциальность
Существует проблема, связанная с атаками MITM на аутентификацию при обмене общедоступными значениями DH при обмене ключами DH между двумя устройствами.Однако в нашей защищенной системе-привратнике конечный узел, привратник и сервер-регистратор (или DNS) поддерживают согласованность общедоступных значений DH, позволяя двум сквозным узлам участвовать в регулируемом обмене параметрами DH, предотвращая атаки противника. о генерации общего ключа. С извлеченным общедоступным значением DH, отправленным от аутентифицированного узла-источника, и самостоятельным секретным значением, целевой узел вычисляет симметричный ключ DH. Однако этот общий ключ DH между двумя одноранговыми узлами будет одинаковым для их разных сеансов.Таким образом, безопасная система привратника требует создания одноразового сеансового ключа для отдельного сеанса даже для одних и тех же узлов. Узел, инициирующий сеанс, создает одноразовый номер на основе сеанса. Другая цель использования значения nonce - настроить размер окончательного симметричного ключа до 128 бит, который можно применить к системе Advanced Encryption System (AES). Вот почему размер значения nonce составляет 112 бит, а размер ключа DH - 16 бит. Одноразовый номер безопасно доставляется на узел назначения вместе с общедоступным значением DH исходного узла.Таким образом, одноранговые узлы будут использовать ключ AES размером 128 бит. Следовательно, полезная нагрузка пакета данных содержит содержимое, зашифрованное с помощью симметричного ключа AES, который является одноразовым сеансовым ключом. Атака полным перебором должна включать перебор всех возможных ключей до тех пор, пока расшифровка не будет успешной. Учитывая, что наша безопасная система-привратник использует одноразовый сеансовый ключ размером 128 бит, злоумышленнику необходимо обработать половину всех возможных ключей: 2127 для достижения успеха. Таким образом, наша безопасная система-привратник обеспечивает конфиденциальность даже при атаке методом грубой силы.
4.6. Производительность безопасности
Асимметричные алгоритмы сложны в исполнении и используют больше ресурсов из-за 1024-битных пар ключей закрытого и открытого ключей, чем симметричные алгоритмы. Таким образом, большинство сетей IoT используют симметричные алгоритмы, поскольку их легко реализовать, они используют меньше ресурсов с небольшими накладными расходами и работают быстрее. Однако у него было только одно слабое место, связанное с проблемой аутентификации во время процедуры согласования общего ключа. показывает уровень безопасности, который может обеспечить наша SGS.Обмен ключами Диффи-Хеллмана требует модульных экспоненциальных вычислений, то есть Y_ENAX_ENBmodq для стороны ENA, что с вычислительной точки зрения не требует больших затрат. Кроме того, все целые числа, используемые в этом вычислении, имеют размер 16 бит. Таким образом, вычисление ключа DH накладывает небольшую вычислительную нагрузку на устройства IoT низкого уровня. Между тем, они могут создать 128-битный окончательный общий ключ с помощью 112-битного одноразового идентификатора, для генерации которого требуется небольшая вычислительная нагрузка. Результирующий 128-битный одноразовый общий ключ обеспечивает уровень безопасности, аналогичный AES.Наша SGS дает решение для слабого места обмена ключами DH из-за схемы аутентификации, созданной привратником, при которой привратник включает аутентификацию одноранговых узлов. Кроме того, привратник проверяет вход всех пакетов, обнаруживает вредоносные пакеты и предотвращает их вход.
Таблица 3
| Управление безопасностью | Размер ключа (биты) | Производительность безопасности | |
|---|---|---|---|
| Одноразовый | Вычисление ключа DH | 16 | Небольшая вычислительная нагрузка |
| Общий ключ | Одноразовый одноразовый номер | 112 | Малая вычислительная нагрузка |
| Соглашение | Окончательный общий ключ | 128 | Использование возможной длины ключа до до 128 бит |
| Аутентификация | Привратник задействован Сервер регистрации (или DNS) задействован | ||
| Обнаружение вторжения | Привратник задействован | ||
Метод виртуального IP-адреса применяется двумя способами: метод MTD и метод балансировки нагрузки в массивной ферме серверов.Методика MTD обычно направлена на защиту от сетевых атак и атак сканирования с использованием случайного виртуального адреса для чувствительных к задержкам приложений, таких как автомобильная связь. С другой стороны, виртуальный IP-адрес полезен для того, чтобы подсистемы балансировки нагрузки серверов могли легко масштабироваться для удовлетворения требований огромной фермы серверов по мере роста объема трафика и количества серверов в ферме серверов. Балансировщики нагрузки сервера можно масштабировать, если входящий трафик данных к шлюзу-маршрутизатору в центре обработки данных перенаправляется в соответствии с назначенным виртуальным IP-адресом.Когда запрос поступает на этот набор серверов или серверных ферм, он направляется на конкретный сервер на основе виртуальных адресов. Множественные запросы, поступающие на серверную ферму, должны распределяться между различными серверами. В этом случае анализ производительности должен включать метрику в балансировщиках нагрузки, объясняя, как легко масштабировать несколько виртуальных адресов по мере увеличения количества запросов.
Для правильной работы привратника реальное преобразование IP в виртуальный IP происходит в реальном времени для каждого проходящего пакета.Помимо изменения IP-адреса, привратник должен изменить контрольную сумму IP. Эти две рабочие нагрузки характеризуют масштабируемость привратника, который поддерживает большое количество устройств для данного домена. Учитывая, что наши привратники развернуты распределенным образом и работают с P2P-приложениями, масштабируемость привратника очевидна, в отличие от межсетевых экранов, расположенных на входе в большой интернет-торговый центр. Наша система безопасного привратника нуждается в метрике производительности для описания проблемы задержки, а не проблемы масштабируемости.
4.7. Производительность с задержкой
Следующий анализ относится к задержке связи в трех различных случаях: RS SGS, DNS SGS и MEC SGS. Каждая система вызывает два вида задержки: задержка сигнализации, которая требуется для безопасного установления сеанса, и задержка передачи данных, необходимая для передачи пакета данных от источника к месту назначения. В этом документе предполагается, что три компонента вызывают задержку:
LI: задержка внутридоменного пути, вызванная внутри домена,
LII: задержка, вызванная сквозным путем,
LIII: задержка вынуждены сотрудничать с распределенными серверами, которые разбросаны в междоменных регионах,
где LII = 5LI, а LIII = 10LI.Это предположение основано на данных тестирования служебной программы TraceRT для измерения сетевых задержек в обоих направлениях. Для целевого сайта Google.com тестовые данные инструмента TraceRT показывают задержку приема-передачи не более 6 мс при четырех переходах и не менее 30 мс при десяти переходах. Поскольку программа TraceRT не несет в себе полезной нагрузки приложения, в этом документе представлено только соотношение двух различных типов измеренных задержек для сетевой архитектуры SGS. Тогда единичная задержка LI соответствует задержке пакета для прохождения от определенного конечного узла к его привратнику, а сквозной путь между двумя одноранговыми узлами длиннее в пять раз по сравнению с единичной задержкой.На практике проверка времени отклика DNS выявляет задержку времени отклика на запрос DNS [39]. В этом исследовании время отклика составляет 62 мс. Другой тест эхо-ответа ICMP показывает, что среднее время приема-передачи составляет 85 мс. LIII соответствует сетевой задержке механизма запроса / ответа плюс задержка поиска на сервере Registra или DNS. Основываясь на этих результатах, в данной статье предполагается, что LIII в два раза больше по сравнению с задержкой сквозного тракта. Компания Samsung объявила о достижении максимальной скорости передачи данных 5G в стационарной среде в 7,5 Гбит / с.Компания добилась стабильного соединения со скоростью 1,2 Гбит / с в мобильной среде от транспортного средства со скоростью 100 км / ч на частоте 28 ГГц [40]. Учитывая, что существующая сеть 4G показывает скорость передачи данных 100 Мбит / с и задержку типа LI около 50 мс, задержка типа LI может упасть до 5 мс с технологией 5G. В этой статье предполагается, что единичная задержка LI будет около 10 мс.
Как показано на, задержка сигнализации для установки безопасного сеанса требует 120 мс в RS SGS. DNS SGS и MEC SGS показывают аналогичные уровни задержки 200 мс и 120 мс соответственно.Задержка передачи данных, необходимая для передачи пакета данных от источника к месту назначения, составляет до 50 мс для всех систем.
Таблица 4
| Компоненты задержки | Задержка (миллисекунды) | ||
|---|---|---|---|
| RS SGS () | Сигнализация | LI: (a), (b), LII: (c), (d) (2LI + 2LII) | 120 |
| Данные | LII: (g) | 50 | |
| DNS SGS () | Сигнализация | LII: (i), (j), LIII: (a, b, ⋯, h) (2LII + LIII) | 200 |
| Данные | LII: (j) | 50 | |
| MEC SGS () | Сигнализация | LIII: (a, b), LI: (c), (d) (LIII + 2LI) | 120 |
| Data | LI: (c), (d) | 20 |
Обеспечение надежности возможность ввода / вывода сообщений для устройства IoT с ограниченной пропускной способностью, если сервер в качестве третьей стороны предполагает подтверждение вредоносности сообщения.Сторонние услуги могут быть предоставлены привратником, предложенным в этом документе, или централизованным сервером, расположенным где-то в Интернете. В этом документе предлагается использовать привратник на входе в локальную сеть, который действует как сторонний сервер. Мы построили стенд для получения реальных данных о производительности. На нашем испытательном стенде, показанном на, канал подсети привратника работает через Wi-Fi со скоростью 72 Мбит / с. На нашей испытательной стенде выполняется веб-приложение, в котором CARA отправляет HTTP-запрос, а CARB получает HTTP-ответ и отображает полученный веб-объект.Есть два типа серверов, которые отправляют веб-объект: веб-сервер, играющий привратником, который действует на основе сценария SGS, и централизованный сервер, который работает на основе сценария централизованного управления.
Измерения производительности на стенде SGS.
Сообщения IoT должны быть достаточно маленькими, чтобы помещаться в их пакеты канального уровня [41].
Он должен умещаться в одном IP-пакете, чтобы избежать фрагментации IP (MTU 1280 байт для IPv6). Если учесть размер заголовков, допустимая верхняя граница составляет 1024 байта для размера полезной нагрузки.
Или меньше, чтобы избежать фрагментации уровня адаптации (60–80 байтов для 6LoWPAN).
Предположим, устройству IoT необходимо передавать большие полезные данные, что требует обработки нескольких блоков информации. Мы используем четыре типа сообщений с разным размером полезной нагрузки: 3 Кбайт, 30 Кбайт, 300 Кбайт и 3000 Кбайт. Каждое сообщение имитирует следующие условия.
Полезная нагрузка 3 КБ: [3 блока по IPv6 или 37 блоков по 6LoWPAN],
Полезная нагрузка 30 КБ: [30 блоков по IPv6 или 370 блоков по 6LoWPAN],
300 КБ полезной нагрузки : [300 блоков по IPv6 или 3700 блоков по 6LoWPAN] и
3000 КБ полезной нагрузки: [3000 блоков по IPv6 или 37000 блоков по 6LoWPAN].
Таким образом, сервер-привратник и централизованный сервер хранят 4 изображения JPEG с разными размерами: 3 Кбайт, 30 Кбайт, 300 Кбайт и 3000 Кбайт. В качестве клиентов на испытательном стенде две машины используют одинаковую частоту ядра процессора 1,2 ГГц и версию Android 5.0.2. Веб-сервер, играющий в привратник, работает с ядром ЦП с тактовой частотой 2,90 ГГц. Стенд использует внешний сервер, поддерживаемый компанией, предоставляющей услуги веб-хостинга, для предоставления достаточного количества частных веб-услуг. Мы повторяем сеансы HTTP 30 раз, чтобы получить данные о каждой задержке, то есть о задержке от отправления HTTP-запроса до получения HTTP-ответа.Для этого мы намеренно обработали скорость эксперимента как можно позже. Интервал эксперимента должен был составлять около 30 минут, чтобы исключить влияние веб-кеширования на сервер и распознавание сетевого потока.
показывает экспериментальные данные, которые объясняют, сколько времени требуется двум различным устройствам Интернета вещей для обмена одноразовыми надежными данными друг с другом с помощью привратника или централизованного сервера. Показано, что с увеличением размера сообщения IoT увеличивается задержка.Он достигает почти 100 мс для сообщения размером 30 Кбайт в среде сценария централизованного управления. Кроме того, сценарий SGS показывает меньшее изменение задержки, чем сценарий централизованного управления. При условии, что канал подсети привратника работает через Wi-Fi со скоростью передачи данных 72 Мбит / с, уровень задержки в сценарии SGS соответствует требованию, согласно которому связь V2IoT должна удовлетворять уровню задержки 20 мс, если размер сообщения остается в пределах 30 Кбайт. .
Сравнение задержек между централизованным управлением и сценариями SGS.
объясняет, как может быть достигнута цель задержки в 20 мс, когда наша SGS работает в среде каналов 5G. Учитывая, что канал подсети испытательного стенда работает со скоростью передачи данных 72 Мбит / с, скорость канала 5G может скоро увеличиться примерно до 300 Мбит / с (к 30 апреля 2020 года средняя скорость загрузки 5G пользователя уже достигает уровня почти 500 Мбит / с для случая Verizon в США). Еще более позитивным является то, что размер сообщения IoT может быть ограничен диапазоном 30 Кбайт. Показано, что даже в каналах 5G задержка быстро увеличивается, когда размер сообщения превышает 300 Кбайт.Как обсуждалось в разделе 1, если задержка передачи данных IoT2V ограничена в пределах 20 мс, автомобиль, проезжающий по городу со скоростью 60 км / час, может успешно отреагировать на расстояние примерно 0,3 метра в экстренной ситуации. Область, окруженная линиями стрелок, соответствует нашему целевому показателю задержки в 20 мс. В результате наша SGS может быть решением, подходящим для связи V2IoT, чтобы соответствовать условию задержки 20 мс, если наша SGS работает при следующих условиях.
Расчетная задержка связи по сценарию SGS в каналах 5G.
4.8. Масштабируемость
Привратник покрывает все проходящие пакеты, входящие и исходящие от устройств IoT, расположенных за ним. Таким образом, количество устройств для данного домена соответствует размеру AMT. Учитывая, что реальное преобразование IP-виртуального IP-адреса происходит в реальном времени для каждого проходящего пакета, задержка обработки при поиске записи AMT для данного слепого значения увеличивается по мере увеличения размера AMT. Затем влияние на производительность в отношении размера AMT связано с тем, чтобы определить, выполняется ли обработка поиска на скорости входящего пакета.Обычно скорость входящих пакетов пропорциональна количеству устройств в данном домене при условии, что каждое устройство IoT отправляет сообщения с одинаковой скоростью отправки. Этот анализ масштабируемости относится к дальнейшим исследованиям данной статьи. Однако в обычных маршрутизаторах задержка обработки, необходимая для пересылки IP, составляет менее нескольких миллисекунд. Таким образом, почти наверняка подсчитано, что в системе привратника основная причина задержки связана со всеми задержками передачи вместе со связями канала связи, а не с задержкой обработки для преобразования адреса внутри привратника.Демонстрация показала, что маршрутизатор Cisco ASR9000 может пересылать реальный трафик со скоростью 20 Гбит / с или выше [42]. Эти экспериментальные результаты демонстрируют, что привратник может обрабатывать 20 × 1098 × 30 × 103≅ 83 000 сообщений размером 30 КБ в секунду.