Для обеспечения надежного шифрования трафика, передаваемого между вашим компьютером и VPN-сервером, к которому вы подключаетесь. Используя приложение ExpressVPN, вы можете легко переключаться между протоколами , хотя мы рекомендуем использовать протокол, установленный по умолчанию (это протокол OpenVPN с открытым исходным кодом), или позволить приложению автоматически выбрать настройки, наиболее оптимальные для вашей скорости подключения и безопасности.

(При подключении через стороннее приложение, например через Tunnelblick для Mac OS X или Network Manager или Terminal на Linux , у вас также есть множество вариантов шифрования с использованием протокола OpenVPN.)

Вот некоторые из особенностей шифрования с использованием протокола OpenVPN:

Аутентификация сервера

Протокол OpenVPN функционирует аналогично протоколу TLS или HTTPS, поэтому его можно назвать TLS VPN. (HTTPS - это защищенная версия базового интернет-протокола HTTP, используемая для защиты подлинности сайта в Интернете. Предварительно установленные сертификаты в вашем браузере позволяют проверить целостность веб-сайта , если он использует протокол HTTPS. Чтобы убедиться, что веб-сайт использует протокол HTTPS правильно, найдите значок в виде зеленого замка ( ) в адресной строке браузера.)

Протокол OpenVPN, также как и HTTPS, использует сертификаты для защиты пользователя от . Сертификаты выдаются специализированными центрами, называемыми центрами сертификации или удостоверяющими центрами. Ваша операционная система или браузер криптографически доверяют определенным центрам сертификации, которые выдают и подписывают сертификаты для веб-сайтов. Это работает в HTTPS, потому что существуют общие стандарты для выдачи и отзыва сертификатов, а также методы привязывания доменных имен в выданных сертификатах к именам конкретных веб-сайтов. Клиенты OpenVPN требуют самостоятельной установки сертификата VPN. Для этого обычно необходимо просто сохранить файл сертификата на своем компьютере и указать клиенту OpenVPN, где он находится.

ExpressVPN использует сертификат RSA с длиной ключа 4096 бит, идентифицированный алгоритмом хеширования SHA-512, входящим в семейство алгоритмов SHA-2.

Код HMAC

HMAC - это код аутентификации (проверки подлинности) сообщений на основе хеширования с использованием секретного ключа. Этот код позволяет гарантировать, что данные не будут изменены в процессе передачи злоумышленниками, у которых есть доступ к данным в режиме реального времени. Для обеспечения надежной аутентификации сообщений в протоколах TLS и OpenVPN используются хеш-функции (отсюда буква H в аббревиатуре HMAC).

Шифрование канала управления

Для защиты канала управления ExpressVPN использует алгоритм AES-256-CBC. AES - это один из наиболее широко используемых стандартов шифрования , который основывается на алгоритме Rijndael, разработанном бельгийскими криптографами Йоаном Дайменом и Винсентом Райменом. Цифра 256 означает длину ключа в битах. Эта длина является самой большой из доступных. CBC (от англ. Cipher Block Chaining) означает режим сцепления блоков шифротекста, при котором каждый блок шифруемой информации зависит от предыдущего блока. Таким образом, даже короткое прерывание в канале может быть быстро обнаружено.

Шифрование канала передачи данных

Шифрование канала передачи данных защищает ваши данные от сторонних лиц, через которых они проходят. ExpressVPN использует симметричную схему шифрования , в которой ключ формируется при помощи протокола Диффи-Хеллмана на эллиптических кривых. Сервер ExpressVPN и ваше VPN-приложение используют сложные математические методы для согласования и проверки секретного ключа, который затем используется для шифрования данных всего сеанса.

Полная безопасность пересылки

Полная безопасность пересылки означает, что даже если злоумышленники каким-то образом смогли скомпрометировать ваш компьютер или VPN-сервер во время одного сеанса, они не смогут расшифровать трафик из прошлых сеансов. Поэтому каждый раз, когда вы подключаетесь к ExpressVPN, согласовывается новый секретный ключ. Даже если вы подключены к VPN в течение длительного периода времени, ExpressVPN автоматически согласовывает новый ключ каждые 60 минут .

Процесс повторного согласования ключа каждые 60 минут гарантирует полную безопасность пересылки данных, поэтому все, что смогут получить злоумышленники, если им удастся скомпрометировать ваши ключи, будет 60 минут данных. Остальное останется секретным .

В версии протокола Server Message Block (SMB) 3.0 , представленном в Windows Server 2012 / Windows 8, появилась возможность шифровать данные, передаваемые по сети между файловым сервером SMB и клиентом. Шифрование SMB трафика позволяет защитить от перехвата и модификации данные, передаваемые по недоверенной или открытой сети. Шифрование данных выполняется прозрачно с точки зрения клиента и не требует существенных организационных и ресурсных затрат, как при внедрении VPN, IPSec и PKI инфраструктуры. В последней версии протокола SMB 3.1.1 (представлен в Windows 10 и Windows Server 2016) используется тип шифрования AES 128 GCM, а производительность алгоритма шифрования существенно увеличена. Кроме того осуществляется автоматическое подписывание и проверка целостности данных.

Разберемся в особенностях внедрения шифрования SMB в Windows Server 2012. В первую очередь нужно понять, что в том случае, если клиент и сервер поддерживают разные версии протокола SMB, то при установлении подключения между сервером и клиентом, для взаимодействия выбирается самая высокая версия SMB, поддерживаемая одновременно клиентом и сервером. Это означает, что все клиенты с ОС ниже Windows 8 / Server 2012, не смогут взаимодействовать с сетевым каталогом, для которого включено шифрование SMB.

На файловом сервере можно получить версию протокола SMB используемого тем или иным клиентом (версия используемого протокола выбранного в рамках соединения указаны в столбце Dialect):

По-умолчанию, на файловом сервера Windows Server 2012 шифрование для передачи SMB трафика отключено. Включить шифрование можно как индивидуально для каждой SMB шары, так и для всего сервера целиком.

Если нужно включить шифрование на конкретного каталога, на сервере откройте консоль Server Manager и перейдите в раздел File and Storage Services –> Shares . Выберите нужную общую папку и откройте ее свойства. Затем перейдите на вкладку Settings , где включите опцию Encrypt Data Access . Сохраните изменения.

Кроме того, включить SMB шифрование можно из консоли PowerShell. Включаем шифрование для одной папки:

Set-SmbShare –Name Install -EncryptData $true

Либо для всех SMB подключений к серверу (будь то общие папки или административные ресурсы):

Set-SmbServerConfiguration –EncryptData $true

После включения SMB шифрования для общей сетевой папки, все устаревшие клиенты (до Windows 8), не смогут подключаться к данному каталогу, т.к. не поддерживают версию протокола SMB 3.0. Чтобы разрешить доступ таким Windows клиентам (как правило, такой доступ организуется временно, иначе теряется смысл от включения шифрования), можно разрешить подключаться к серверу без шифрования:

Set-SmbServerConfiguration –RejectUnencryptedAccess $false

Совет . После включения данного режима, подключающийся клиент в процессе согласования поддерживаемой версии протокола сможет переключится на совсем устаревшую версию SMB 1.0, что не безопасно (в Windows Server 2012 R2 ). В этом случае, чтобы хотя бы частично обезопасить сервер, желательно отключить поддержку SMB 1.0:
Set-SmbServerConfiguration –EnableSMB1Protocol $false

Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL /TSL -соединения перехватить обычными средствами невозможно. Но так ли это?

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

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

А как они это делают? Обычно - по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).

Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.

Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:

клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения

Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.

В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере - ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.

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

Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:

<== SSH-соединение ==> сервер <=> целевой сервер

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

На практике есть два варианта работы. Первый - покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP.

Второй вариант - покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. VDS может быть российским или американским (только не забывайте про заокеанские пинги), дешевым (от $5) и слабым или дорогим и помощнее. На VDS ставят OpenVPN -сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента .

Если вы решите использовать вариант с OpenVPN, то есть например эта простая пошаговая инструкция по поднятию сервера (Debian). Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).

Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.

Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, - это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.

Теги: Добавить метки

Вы думаете что ваша анонимность надежно защищена. Но к сожалению это не так. Существует один очень важный канал утечки вашей приватной информации — служба DNS. Но к счастью на это тоже придумано решения. Сегодня я раскажу как зашифровать свой DNS трафик с помощью утилиты DNSCrypt.

При использовании HTTPS или SSL твой HTTP трафик зашифрован, то есть защищен. Когда ты используешь VPN, шифруется уже весь твой трафик (конечно, все зависит от настроек VPN, но, как правило, так оно и есть). Но иногда, даже когда используется VPN, твои DNS-запросы не зашифрованы, они передаются как есть, что открывает огромное пространство для «творчества», включая MITM-атаки, перенаправление трафика и многое другое.

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

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

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

Да, какие данные ты будешь передавать на dkws.org.ua, никто не узнает. Но есть несколько очень неприятных моментов. Во-первых, провайдер, просмотрев логи DNS, сможет узнать, какие сайты ты посещал. Тебе это нужно? Вовторых, вероятна возможность атак DNS спуфинг и DNS снупинг. Подробно описывать их не буду, об этом уже написано множество статей. В двух словах ситуация может быть следующей: некто между тобой и провайдером может перехватить DNS-запрос (а так как запросы не шифруются, то перехватить запрос и прочитать его содержимое не составит никакого труда) и отправить тебе «поддельный» ответ. В результате вместо того, чтобы посетить google.com, ты перейдешь на сайт злоумышленника, как две капли воды похожий на тот, который тебе нужен, введешь свой пароль от форума, ну а дальше развитие событий, думаю, ясно.

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

Если ты «боишься» своего провайдера или просто не хочешь, чтобы он видел, какие сайты ты посещаешь, можешь (разумеется, кроме использования VPN и других средств защиты) дополнительно настроить свой компьютер на использование DNS серверов проекта OpenDNS (www.opendns.com). На данный момент это следующие серверы:

208.67.222.222
208.67.220.220

При этом тебе не нужно никакое другое дополнительное программное обеспечение. Просто настрой свою систему на использование этих DNS-серверов.

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

Вот мы и подошли к DNSCrypt. Эта программулина позволяет зашифровать твое DNS соединение. Теперь твой провайдер (и все, кто между тобой и им) точно не узнает, какие сайты ты посещаешь! Еще раз повторюсь. Эта программа не замена Tor или VPN. По-прежнему остальные передаваемые тобой данные передаются без шифрования, если ты не используешь ни VPN, ни Tor. Программа шифрует только DNS трафик.

В КАЧЕСТВЕ ЗАКЛЮЧЕНИЯ

Статья получилась не очень большая, поскольку сама программа очень проста в использовании. Но она была бы неполной, если бы я не упомянул и о VPN. Если ты прочитал эту статью, тебя она заинтересовала, но ты еще не пользуешься услугами VPN-провайдера для шифрования своих данных, то самое время это сделать.
VPN-провайдер предоставит тебе безопасный туннель для передачи твоих данных, а DNSCrypt обеспечит защиту DNS-соединений. Конечно, услуги VPN провайдеров платны, но ведь за безопасность нужно платить?

Можно использовать, конечно, и Tor, но Tor работает относительно медленно, и это, как ни крути, не VPN - весь трафик «торифицировать» не получится. В любом случае (какой бы вариант ты ни выбрал) теперь твои DNS-соединения защищены. Осталось только определиться со средством шифрования трафика (если ты это еще не сделал).

Last updated by at Октябрь 30, 2016 .

Широко известному в узких кругах Денису Карагодину попытались« улучшить» домашние интернет-устройства. Как написал сам Карагодин, ему позвонил томский провайдер и заявил, что из квартиры идёт« негативный трафик», после чего попросил принять дома специалиста. После беседы с этим гостем выяснилось, что провайдер хотел бы получить доступ к компьютеру Карагодина и войти в его домашнюю локальную сеть. Ещё до визита Карагодин обратил внимание, что: «несколько недель назад начались проблемы с обычным интернетом. Браузер жаловался на сертификаты, сайты не отображались корректно или не открывались вообще. Но если включаешь VPN, то становилось всё нормально».

Складывалось такое впечатление, что кто-то снифит трафик(причем еще и фильтруя его)(как будто стоит какой-то или буфер, или трестируется некая новая СОРМ-система).

Гость пытался воспользоваться компьютером Карагодина или войти в Wi-Fi, чего хозяин не разрешил, и не захотел подключить провайдерский кабель к собственному оборудованию, чтобы проверить« как идут пинги». В итоге Карагодин порекомендовал специалисту обращаться в управление« К» МВД России или ФСБ, где профессионально расследуют интернет-правонарушения. И объяснил, что с шифрованными пакетами провайдеру придётся смириться. Работать через VPN Карагодину удобнее.

сайт: 21 июля Госдума в третьем чтении закон о запрете обхода блокировок через VPN и анонимайзеры, но готовящийся к введению документ не касается абонентов. По закону анонимайзеры и VPN-сервисы должны так же как операторы связи ограничивать доступ к запрещенным в России сайтам — в этом случае никаких претензий власти к ним не возникнет. Если же сервисы не сотрудничают с РФ — доступ к ним блокируется провайдерами Рунета, а ссылки на соответствующие сайты должны быть удалены из выдачи на поисковиках.

Рассказ Дениса Карагодина полностью:

Новости такие. Позвонил интернет-провайдер. Говорит, что какой-то у вас« негативный трафик» идет. Нужно проверить. А «негативный трафик» — это мой шифрованный канал VPN. В ходе беседы выясняется, что они хотят получить доступ к моему макбуку… Ну, что ж… Посмотрим. Приезжайте говорю в назначенное время, обсудим суть вопроса. Через пару часов приедут.

Итак. Расклад такой. Утром звонок от провайдера. Якобы от вас(из одного из устройств, подключенного к интернету) идет« негативный трафик». Уточняю какое именно устройство. Выясняется, что мой макбук(хотя устройств несколько). Дальше идет попытка убедить меня, что мой компьютер взломан и с него осуществляется атака на оборудование провайдера. Рекомендуют принять сотрудника и он порекомендует какую именно следует поставить антивирусную программу. Я спрашиваю, что т.е. получается вы хотите получить доступ к моему компьютеру? Ответ — нет(откровенно смутившись), просто мы хотим, чтобы ушел негативный трафик и на нас(на наше оборудование) не было атаки. Поступает предложение продиагностировать всё удаленно. Я соглашаюсь. Через секунды 4 звонящий говорит, ой, у вас же макбук, так не получится… Давайте сотрудник приедет. Я соглашаюсь — делаю лаг времени, чтобы собрать немного данных о собственном трафике(он в полной норме, никаких ддосов и пр.). В итоге приезжает сотрудник от провайдера, говорит, что по моей заявке(но я как вы понимаете никакую заявку не оставлял). Начинает с порога просить дать доступ ко всем устройствам и сети домашней. Я переспрашиваю, а в чем собственно дело? Т.е. вы говорю хотите получить доступ ко всем устройствам моего дома, подключенных к интернету? Он говорит — да, так он сможет посмотреть все ли в порядке. Я ему говорю, что у меня всё в полном порядке и я не понимаю в чем проблема. Тут он говорит, что ему сказали, что есть некий ноутбук, и у него много пакетов и что они странные. Я ему отвечаю, что да есть в том числе и мой макбук и там много пакетов, т.к. я много им пользуюсь. И если например вы видите какие-то шифрованные пакеты, то это просто VPN. Он делает попытки получить к нему доступ, а также доступ просто в Wi-Fi сеть… Я всё на корню пресекаю. Говорю ему: если вам нужно проверить интернет(а он хотел проверить« как пинги идут»), то я сейчас просто дам вам кабель ваш который у меня в роутер идет и вы его себе воткнете и посмотрите пинги… Он начинает неврничать. Я ему говорю — вы наверное ifconfig хотите посмотреть? Он краснеет и говорит, что ну он же мой(т.е. его) покажет… В итоге я ему РАЗЪЯСНЯЮ, что если он(провайдер) считает, что с одного из устройств(в частности моего макбука) идет атака на их оборудование(хотя ее нет), то им следует подать официальное заявление в Управление« К» МВД России или ФСБ России и там разберутся(была ли атака и есть ли она). А если вы видите на своей стороне, что идут шифрованные пакеты, так это от того, что у меня стоит VPN и мне крайне это удобно. Далее идет еще минут 5 перепалка(с попыткой давления на меня). В итоге, он разворачивается и уходит. Я был вежлив и неуклонен. Если есть подозрение, что я осуществляю кибер-атаку на оборудование провайдера — пишите заявление в Управления« К» МВД или ФСБ России, а если нет, то мои устройства(компьютеры, мобильные телефоны и чайник с Wi-Fi — это моя личная собственность; включая и развернутую домашнюю сеть) и никого кому я не хочу давать к ним доступ, я его давать не намерен. Это говорю все равно, что сейчас придет человек из водоканала и попросит меня дать ему покупаться в моей ванной, т.к. ему кажется, что вода по трубе как-то не правильно идет. Человек явно не ожидал, что его в управление« К» отправят. Спросил подтвержу ли я все сказанное по телефону, если мне позвонит его начальство, я сказал что конечно и что он сам может в подробностях передать наш разговор.

В общем, держу цифровую оборону! ¡No pasarán!

Термин« негативный трафик» — терминология интернет-провайдера(озвучено при разговоре со мной); звучит красиво, до этого я никогда и нигде его не встречал и о нем не слышал(с учетом того, что в Сети я с 1993 года) {о реферальном спаме конечно же знаю, но это« оказался» не он}; век живи — век учись {ирония}.

Причем, важно отметить, что изначально(теоретически) я допускал возможность наличия некой технической проблемы, т.к. в мою локальную сеть включен и мой внешний веб-сервер [сайты: karagodin.com, stepanivanovichkaragodin.org]. Именно по этой причине я детально и пытался уточнить у провайдера, о каком именно« проблемном» устройстве идет речь? Но, когда выяснилось, что« проблема» именно в моем личном ноутбуке, то тут уже стало всё совсем интересно и интригующе!

Но, у истории есть предистория.

Несколько недель назад я начал отмечать странности с обычным интернетом. Складывалось такое впечатление, что кто-то снифит трафик(причем еще и фильтруя его)(как будто стоит какой-то или буфер, или трестируется некая новая СОРМ-система). Например, некоторые сайты не грузились(причем сегментно, тематически), либо грузились частично(битыми блоками, с потерей части.css-стилей и т. п.), почтовые программы при этом начинали жаловаться на проблемы с подлинностью сертификатов соединения и пр. Но, стоило включить VPN, как все эти непонятные технические сбои мгновенно пропадали. При этом, работа моего веб-сервера(у него свои порты) была всегда в полном порядке. Проблемы были именно на уровне рядового устройства, подключенного к роутеру и пытающегося выйти во внешний интернет.

---
// копия в телегам-канале: t.me/karagodincom/40
// тема ведется в блоге: karagodin.com/?p=4295

Отчетность за сотрудников