ViPNet в деталях: разбираемся с особенностями криптошлюза
Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.
Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD (Dead Gateway Detection) и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим «ключам» можно будет найти в документации.
Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ. 
В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.
Координатор недоступен
«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.
Конверт не доставлен
Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу). Значит, если вы захотите отправить письмо по деловой почте, то клиент упакует его в конверт и отправит сначала на свой координатор. Далее на пути могут быть еще несколько координаторов, и только после этого конверт попадет на узел адресата.
Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.
Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.
Последствия перепрошивки
Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI. Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. Например, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.
Неинформативные конфиги
Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».
Самые популярные выводы это:
iplirdiag -s ipsettings —node-info <идентификатор узла> ##отображение информации об узле
iplirdiag -s ipsettings —v-tun-table ##отображение всех загруженных в драйвер туннелей
Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.
(Un)split tunneling
Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»). Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.
Служебные порты и TCP-туннель
Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.
Замена координатора
Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.
Кластеризация и сбой ноды
Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.
При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.
В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.
Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.
Пересечения адресов
В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.
Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.
Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.
Невозможность работы GRE
Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:
Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).
Не забываем про время
Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.
Нешифрованный трафик вместо зашифрованного
Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:
- пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;
- с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;
- туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.
Обработка прикладных протоколов (ALG)
На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:
- при использовании NAT должен быть включен ALG;
- при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
- при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
- ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.
В заключение
Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.
Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»
ИнфоТеКС IPlir (IP layer interconnection robust)
Стандартизованный протокол безопасности сетевого уровня
IPlir (IP layer interconnection robust) — стандартизованный протокол безопасности сетевого уровня.
2022: Размещение RFC на протокол IPlir на сайте IETF
Проект RFC (от англ. Request for Comments — документ из серии пронумерованных информационных документов интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети), на протокол безопасности сетевого уровня IPlir, разработанный компанией «ИнфоТеКС», размещен на сайте IETF. Проект находится в стадии обсуждения и утверждения профессиональным сообществом. Авторами RFC выступила группа экспертов ИнфоТеКС. Об этом сообщили в компании «ИнфоТеКС» 13 января 2022 года.
Протокол безопасности сетевого уровня — протокол IPlir (IP layer interconnection robust) — обеспечивает конфиденциальность и имитостойкость данных при их передаче в сетях связи с помощью стека протоколов TCP/IP с использованием различных криптографических механизмов.
Протокол IPlir может применяться для создания виртуальных частных сетей (VPN) всех известных видов: как между отдельными узлами, так и с подключением любой комбинации локальных сетей. IPlir позволяет реализовывать различные режимы инкапсуляции трафика, функционирует без установления соединения на каналах произвольного качества, обеспечивает минимальную избыточность IP-пакетов, совместим с IP-протоколом версий v4 и v6 и подходит для применения в СКЗИ различных классов.
Протокол IPlir является результатом многолетней работы специалистов компании «ИнфоТеКС». Он стандартизован в виде рекомендаций по стандартизации Р1323565.1.034-2020 «Информационная технология. Криптографическая защита информации. Протокол безопасности сетевого уровня» согласно Приказу №1325-ст Федерального агентства по техническому регулированию и метрологии (Росстандарт).
2020: Утверждение рекомендаций по стандартизации Росстандартом
Приказом №1325-ст Федерального агентства по техническому регулированию и метрологии (Росстандарт) утверждены рекомендации по стандартизации Р1323565.1.034-2020 «Информационная технология. Криптографическая защита информации. Протокол безопасности сетевого уровня». Об этом 28 декабря 2020 года сообщили в компании «ИнфоТеКС».
Стандартизованный протокол безопасности сетевого уровня — протокол IPlir (IP layer interconnection robust) — обеспечивает конфиденциальность и имитостойкость данных при их передаче в сетях связи с помощью стека протоколов TCP/IP с использованием национальных криптографических механизмов.
Протокол IPlir может применяться для создания виртуальных частных сетей (VPN) всех известных видов: как между отдельными узлами, так и с подключением любой комбинации локальных сетей. Он вобрал в себя современные подходы к сетевой криптографической защите информации, рассказали в «ИнфоТеКС».
По словам представителей компании, от других протоколов аналогичного класса IPlir отличается рядом особенностей: он позволяет реализовывать различные режимы инкапсуляции трафика, функционирует без установления соединения на каналах произвольного качества, обеспечивает минимальную избыточность IP-пакетов, совместим с IP-протоколом версий v4 и v6, подходит для применения в СКЗИ различных классов и др.
Протокол IPlir является результатом многолетней работы специалистов компании «ИнфоТеКС». Он многократно опробован на практике в широком спектре действующих корпоративных и государственных информационных систем.
Если в windows не работает hosts
Сегодня постучался товарищ, просил помочь с hosts. Дело было в том, что как не правь этот файл, системой он не обрабатывался. Перепробовав кучку вариантов, проблему решить все же удалось.
О вариантах решения проблем в таких ситуациях сегодня и пойдет речь.
Во первых, попробуйте закрыть все браузеры и выполнить в консоли команду:Данная команда очищает dns-кеш.
Во вторых, проверьте в «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters» параметр «DataBasePath», он должен иметь тип «REG_EXPAND_SZ» и значение «%SystemRoot%\System32\drivers\etc».
В третьих, убедитесь, что к файлу есть доступ на чтение для всех юзеров.
В четвертых, попробуйте переименовать файл hosts в, например, hosts.bak. Потом создайте новый файл hosts, откройте его блокнотом и напишите туда ручками (именно ручками, а не скопируйте):(porno.com тут приведен для примера, реально надо писать тот сайт, который вы хотите заблокировать)
В пятых, убедитесь, что запущена служба DNS-клиент. Если не запущена, то запустите и поставьте ее в автозапуск.
ЗЫЖ Товарищу помог четвертый пункт.
UPD: Не забывайте, что сначала должны идти IP, а потом, через пробел или таб, имя хоста.
Информация с сайта http://angel2s2.blogspot.com/. Если Вы читаете информацию на другом сайте, пожалуйста свяжитесь с автором сайта http://angel2s2.blogspot.com/.
Похожие статьи
45 коммент.:
Спасибо angel2s2 до такого варианта было реально тяжело додуматься 🙂
Благодарю за советы, помогло. А то ДВА дня парился с этой проблемой. Добавляю твой сайт в избранные.
Рад, что оказалось полезным и рад за вас, что помогло 🙂
Спасибо, дружище! 4 пункт помог!
Рад, что помогло 🙂
4 пункт однозначно решает. Настраивал несколько дней Апачи, не мог понять почему не работают Vhosts (c NameVirtualHost), а все дело в hosts оказалось. Непонятно только, почему hosts перестал работать. Кстати про вписывание руками директив: я все из старого скопировал, и работает, так что видимо можно и без лишнего рукописного ввода обойтись.
Да, я это тоже заметил. У всех комментаторов именно этот пункт.
У меня два предположения почему перестал работать:
1. Файл должен быть в формате ASCII, а он изначально в "UNICODE".
2. Внешнее воздействие: вирус, hotfix либо какой-нибудь антивирус. В смысле, изменил файл из ASCII в "UNICODE".
Ничего из этого я, конечно же, не проверял. Это только мое предположение.
Тут под "UNICODE" я имею ввиду следующее: если сделать экспорт из regedit какой-нибудь ветки, а потом полученный файл открыть, например, в gvim, то будет видно, что между буквами есть еще какие-то символы. Вот такой формат я и имел ввиду. Вроде это UTF-16. Хотя я точно не знаю.
> Кстати про вписывание руками директив
Ручками предложил вписать, чтобы избежать случайных косяков с кодировкой и непечатаемыми (служебными?) символами.
привет,а что мне не делать,если у меня на оборот не заход в контакт,одноклассники!!я уже заходил на host всё делал по инструкции,и всё равно не магу зайти на сайты(( хотя нет в этих строках на счёт того что сайты заблокированы. что делать? заранее спасибо!
Привет. Скорее всего у тебя есть скрытый системный файл hosts, а тот, что видишь ты, называется hosts.txt, но так как в проводнике отключено отображение расширений, то ты видишь просто hosts.
Скачай FAR, включи в настройках отображение скрытых и системных файлов, перейди в папку C:\Windows\System32\drivers\etc. Если увидишь файл hosts.txt значит все так и есть. Удаляй его и правь файл hosts (который без расширения). Так же обязательно проверь комп на вирусы (есть такая зараза, которая этот трюк проворачивает): лучше скачай Dr.Web LiveCD или Kaspersky Rescue Disk на другом компе, запиши на CD диск, загрузи свой комп с этого диска и проверь на вирусы (так на много надежнее, чем из винды, даже из безопасного режима, проверять).
спасибо огромное, ничего не помогало, но 4-й пункт это и правда хоть и нелепо, но работает
Спасибо, и мне 4 пункт помог =)
Спасибо! проблема решилась 4-м пунктом! ))
В основном проблема с файлом hosts в том, что вирусы/трояны заменяют букву "o" латинскую на букву "о" русскую. Вот система и не видит этот файл. А в проводнике всё смотрится окейно.
У меня было такое в свежепроинсаллированной ХРюшке (лицензионной). Не помню только какой там СП был.
Спасибо большое способ переименования помог!
Убил на поиск проблемы полтора часа , перепробовал всё что можно .
. спасибо , помог тоже 4-й пункт
спасибо большое, думал пропаду..
не пашет нихера, семерка, зараза, достала уже..
сижу значит пишу уже который час DynDNS-сервер на .cmd в связке с Netcat, для того чтобы слушать на порту можно было, всё отлично кроме одного — не потдягивают эти драные окна нихера! и руками и скриптом и головой уже в монитор этот фаел и обновлял и руками создавал и пересоздавал и делал через move, и через rename, и ХРЕН!
если найдешь решение или знаешь что-то из того, что тут
не описано — буду офигенно рад если кинешь на мыло!
dasknix много_животных почта_на_гмайл-точка-ком
..ну и все описанные способы, конечно, тоже
перепробовал — не помогло, иначе бы не писал.
офонареть, бьюсь руками об глаза!11
у меня реверсом хосты и ипы были, а не сначала ипы
всем спасибо, пойду покурю.
Да. Такое тоже бывает 🙂
Отдыхай больше 😉
Блин, у меня проблема месяца два уже. Правда раньше не к спеху было, ну я и забил, а сейчас острая необходимость — и сижу бьюсь. Респект, сработал 4 пункт 🙂
Спасибо ГРОМАДНОЕ
Чего только не делал до этой статьи
Помогло создание нового файла hosts
Кому ничего не помогает советую заглянуть в настройки подключения сетевухи. У меня там рядом с настройками Тсp/ip нашлась такая вот дрянь: "lplir lightweight Filter (x64 edition)". Снимаем галку и радуемся жизни.
Что интересно, гугл ничего про дрянь не знает. Откуда оно взялось не ясно.
Спасибо, добавил в пост.
подскажите пожалуйста, можно ли с помощью hosts заблокировать приложения вконтакте? лично у меня не получается. другие адреса блокируются
Можно. Но нужно знать IP адрес, на котором это приложение висит. Дело в том, что сами приложения, как правило, хостятся не на серверах вконтакта, а на сервере разработчика.
Все дело в том, что реальный файл хостс скрыт (сделайте его видимым с помощью соответствующей настройки в свойствах папки) и тогда будете вносить изменения в действующий файл.
Хостс перестал работать после чистки программой Dr.Web CureIt.
Ни что из вышеперечисленного его не воскресило работу файла.
Виндовс XP SP2.
Посоветуете, что либо или дешевле для нервов просто переустановить систему?
Манори, я знаю только один случай, когда делаешь правку файла hosts, а эффекта нет.
В папке было два файла — hosts и hosts.txt, но т.к. в проводнике был отключен показ скрытых файлов и их расширений, пользователь видел только один файл — hosts.txt, но видел его как hosts. Поэтому hosts и не работал.
Roma Shagrov, у меня включен показ скрытых файлов(лечил от вируса-скрывалки папок флешку, которую у соседей к "динозавру" полному вирусов подключал, из-за чего, собственно и использовал Dr.Web CureIt). Скрытых файлов там нет, и он работал до обработки антивирусником Dr.Web CureIt.
Файл имеет атрибут "системный"? Какие права на файл (владелец и тп)?
У меня с cure it такого никогда не было.
А разве эта фича не в Win7 появилась?
Хотя, может, я-нуб, незнающий куда смотреть.
Манори, точно не скажу. Давно винду не юзаю, линуксоид.
яснопонятно. я б тож давно перешёлна линукс, да не охото с эмуляторами возиться. приходится терпеть всю эту фигню ради игор. Т.Т
А у меня проблема оказалась в папках etc\Save1 etc\Save2, в которых я хранил копии hosts.
Пока их не убрал, основной hosts не обрабатывался.
Этот комментарий был удален автором.
Откатить систему помогает. Понятно, что поздно с советом, но может другим поможет после лечения cureit
Olga A, откат системы не всегда поможет, т.к. изменения в системе, связанные с hosts могли произойти давно, а понадобилось, что в hosts менять, только сейчас.
помогло только после nbtstat -R с правами адиминистратора + ipconfig /flushdns
Не вышло у меня все проверил не один раз и как назло когда реально понадобилось, такая магия что без бубна не разберешься, на 7, 10 проверил все гуд, а вынь 8*64 ни вкакую час времени потрачено бесполезно (.
Так и не понял, что именно помогло, но в конце концов оно почему-то заработало, когда я уже забил) Указанный в статье фильтр — это фильтр антивируса, он просто сам блокирует некоторые сайты и по идее не должен влиять на блокировку от hosts.
Товарищи, выручайте, проблема с ПК, сам я уже намучался в край((
Проблема появилась ВНЕЗАПНО месяц 1 назад.
Суть такова: при включении ПК устанавливается Wi-fi соединение и работает на максимальной скорости (150 Мбит/сек).
Спустя некоторое время скорость снижается до 1 мбит/сек и остается такой.
Сменил роутер, сменил провайдера, сменил два адаптера, ВСЕ РАВНО ТАКАЯ ХЕРНЯ!
По проводу от роутера и просто напрямую скорость всегда стабильна и максимальна.
Если дело в компе, то что именно не работает?
4 коммента для минусов внутри
Лучший бу роутер цена/качество
Я устал, я мухожук купил себе новый старый роутер.
Вы спросите, нахуа этот пост, если итак все понятно. Пришел в магазин и что нибудь купил.
Информация в посте будет полезна тем, кто хочет перейти на производительный гигабитный роутер с поддержкой 5ГГц и всякими плюшками вроде поддержки сторонних прошивок за крайне скромный прайс.
Речь о фирменных роутерах от компании Билайн.
Почему именно они?
Многие пользователи билайн брали и берут их в рассрочку. Причем, если авторизоваться в панели управления роутером под стандартными логин и пароль admin/admin будет доступно подключение к провайдеру только по протоколу L2TP, который в моем городе использует исключительно билайн. Но если авторизоваться под SuperUser, используя в качестве пароля серийный номер — становится возможным использовать их с любым провайдером. Об этом почему-то знают не только лишь все. И продают их по цене от 600 рублей за старшие версии. И от 300 рублей за младшие. Например.
Младшая версия — smartbox one.
Отличается более скромными параметрами и портами lan 100мбит. Лично использовал такой несколько лет с разными провайдерами. Нареканий нет. Не зависает, держит скорость, поддерживает частоту 5ГГц. За 300-500 рублей конкурентов нет.
Старшие модели. smartbox giga, smartbox pro и smartbox turbo+.
Все имеют порты 1гбит. У первого всего 2 lan, у второго целых 2 usb, а последний поддерживает скорость до 1800мбит по wi-fi. Реальная же вполне держится на уровне 500 мбит при закачке фильма в мой galaxy s10.
Все три могут быть прошиты сторонними прошивками, но для обычного повседневного использования хватает родной. Инструкции на 4pda здесь.
Все достаточно производительные. И подключаясь по PPPoE вполне выдадут реальных 400-500мбит.
С чем бы сравнить? Например netis wf2780
Один из самых бюджетных гигабитных вариантов. Использовал в течении года. Плохой роутер(очень). Даже 1500 за новый не отдал бы. smartbox turbo + намного лучше.
Если у вас ограниченный бюджет и хочется получить отличный гигабитный двухдиапазонный роутер за шапку сухарей — выбирайте билайн. Авторизация под SuperUser и настройка под любого оператора. После — долгое и счастливое использование. Когда нибудь при желании можно будет прошить openwrt и подключать от usb модема до принтера и жесткого диска. Установить на него торрент и wpn. Заблокировать рекламу и т.д.
Предложений на авито много, но рекомендую поискать. Цена на one начинается от 300. На старшие от 600 и я себе взял за 1000 с доставкой к дому.
P.S. Это не реклама. Покупать их следует исключительно с рук у тех, кто не догадался при смене оператора авторизоваться под суперюзер. Но если каждый мой пост рассмотреть как рекламу, то это не самый страшный пример.
Здесь рекламирую proxmark3. Скорее всего китайцы проплатили.
Здесь очки для дрона и свои услуги.
А здесь разные заготовки для домофонных ключей.
Кошачий туалет catgenie120 и т.д.
P.P.S. Товарищи. Вы там это, если сохраняете в избранное.. значит у вас есть аккаунт на пикабу. Плюсаните что-ли. Так пост поднимается в горячее и его увидит большее количество людей. За рейтингом не гонюсь после отключения рекламы. Но странно, когда сохраняют в избранное на 50% больше, чем поставили плюс.
Так неожиданно и приятно.
Нам нужны специалисты, а не те, кто в гугле ищет
Устраивался я как-то на работу в госконтору «сисадмином». Платили там мало, что-то околоминималки, но пришлось т.к. работа нужна была срочно, и быстро откликнулись. Почему название профессии в кавычках — потому, что то, что работа состояла в основном из 1С + следить за вафлей + мелкий ремонт техники, типа заправки принтеров и т.д. В общем, типичное явление, когда путают сасадмина с техником.
Шел испытательный срок, 4-й день. Звонят мне из одного отдела с просьбой проверить работу вафли, типа не подключается. Опытным путем выяснилось, что проблема такова — в режиме DHCP не получает адрес в принципе устройство, если вручную прописать айпишник и маску, то конектится, но нет доступа к инету, только локалка. Также выяснил, что проблема существует давно уже, с тех пор, как установили вафлю после тендера. Еще прошлый сисадмин пытался решить, но так и не смог, стабильно раз в сутки, только в разное время это происходит. Проблема осложняется тем, что по всей конторе стоит бесшовная вафля от Ubiquity, с которой я не знаком. Впрочем, я про это говорил на собеседовании, на что мне в ответ звучало «да разберешься, ты вот в более сложных вещах шаришь, что тебе та вафля . «.
Как вы поняли, разобраться не смог. Лазил в настройках, переключал типи защиты, менял ширину канала, делал сброс, прошивку обновлял — без толку. Причем ладно, если бы один роутер только глючил — глючит их сразу 4, целый отдел в общем.
Решил я поискать решение проблемы в гугле, а также в телеграме поспрашивать у знакомых сисадминов (именно сисадминов).
И тут возникает ситуация — идет начальник, проходит мимо меня и останавливается. У меня на мониторе 1С, паралельно браузер открыт, в котором запрос «ubiquity не подключается устройство», также в углу телега, в которой висит в конфе сообщение «посоны, подскажите плз, кто-то сталкивался с вафлей такой фирмы, не подключаются устройства в режиме DHCP». Начальник позвал в кабинет.
Прихожу, а там он говорит следующее, типа: «Считай, что на этом твой испытательный срок закончился». Я спрашиваю, почему? Он в ответ: «Нам нужен специалист, а не человек, который в гугле и у знакомых спрашивает, как починить то, что не работает, значит у тебя знаний мало».
Я уже не выдержал и в ответ ему выдал: «Так потому у вас оно и не работает, что прошлые специалисты слишком гордые были и у коллег по профессии помощи не просили, а я не гордый, мне важно чтобы работало, и буду искать все способы для этого».
Естественно, что я ушел с работы, не стал ничего доказывать, если начальник считает, что он найдет на такую зарплату крутого специалиста — то флаг ему в руки. Но до сих пор так и не понял, что я сделал неправильно .