А некоторые клиенты, например, Amnezia не умеют работать с масками аля *.site.ru.
А что, никто не пользуется proxy autoconfiguration? Вниманию тех, кто пользуется, предлагается функция на JScript для поиска прокси из ассоциативного массива, соответствующего наиболее детальному домену из указанных, типа most detailed route, которая может до определённой степени заменить поиск прокси по шаблону имени хоста.
Функция может с успехом использоваться в дебрях proxy autoconfiguration file.
// URI прокси даны для примера
// Прокси socks v5
const socks = 'SOCK5 127.0.0.1:1080';
// Локальный кэширующий прокси
const cache = 'PROXY 127.0.0.1:8080';
// Доступ, минуя любые прокси
const direct = 'DIRECT';
const default_proxy = direct;
const proxy_type =
{
'imap.gmail.com': socks,
'smtp.gmail.com': socks,
'gmail.com': cache
};
// Функция проверяет в цикле, нет ли в ассоциативном
// массиве obj ключа, соответствующего host, и если есть —
// — возвращает ассоциированное с ним значение.
//
// Если нет — отщипывает от host левую часть до первой точки
// вместе с ней и повторяет цикл с новым значением host.
//
// В результате получается поиск наиболее детального
// поддомена среди ключей obj и возврат прокси URI,
// ассоциированного с этим поддоменом.
//
// Данная функция может использоваться вместо поиска
// подоменов по шаблону: если некий domain.tld указан
// в качестве ключа obj, то функция вернёт ассоциированный
// с ним URI прокси для любого поддомена domain.tld
// за исключением явно указанных в obj поддоменов вида
// subX.domain.tld. Для них она вернёт ассоциированные
// с ними прокси URI.
//
// Если значение host и всех доменов верхнего уровня
// среди ключей obj отсутствует, функция вернёт undefined.
//
// Так, для указанных выше данных, функция вернёт
// значение socks для imap.gmail.com и smtp.gmail.com, но cache —
// — для просто gmail.com.
function FindMostDetailed(obj, host)
{
let dot_pos = 0;
let result = undefined;
do
{
result = obj[host.substr(dot_pos)];
if (result) { break; }
}
while ((dot_pos = host.indexOf(".", dot_pos) + 1) > 0)
return result;
}
// Противодействие сканированию localhost
// с подачи @alex_1065
const blackhole = 'PROXY 127.0.0.1:9'
const per_host_proxy =
{
'127.0.0.1': blackhole,
'[::1]': blackhole,
'localhost': blackhole,
'0.0.0.0': blackhole
}
function FindProxyForURL(url, host)
{
let proxy = per_host_proxy[host];
if (proxy) { return proxy; }
if (isInNet (host, "127.0.0.0", "255.0.0.0.")) { return blackhole; }
proxy = FindMostDetailed (proxy_type, host);
if (proxy) { return proxy; }
return default_proxy;
}
Забавно, но я таких со своей стороны практически не встречал.
Ну так я ж давно живу. Я ещё ipchains настраивал, в них никакого conntrack'а не было. И древние циски родом из 90-х годов прошлого века тоже настраивал, в которых даже расширенных ACL не было, не говоря уже о CBAC или ZFW.
Трейс в интранет всегда работал корректно через все бытовые (и не очень) NATы на роутерах, шлюзах на основе всяких OS (были и Linux и FreeBSD и даже Windows).
Что совершенно неудивительно, потому что в них уже был встроен SPI с поддержкой NAT. Я ж говорю, создателям SPI надо памятник при жизни поставить.
Можете назвать реальный пример такого, чтобы самому пощупать?
Самый простой вариант заключается в том, чтобы взять любой работающий линуксовый МСЭ на iptables, удалить из его таблиц все правила, в которых фигурирует conntrack, после чего можно будет поглядеть на отвалившийся PMTUD и на неработающую трассировку.
Команда для удаления всех правил, в которых упомянут conntrack:
Если хочется приобщиться к старине, найдите где-нибудь древний маршрутизатор Cisco, разработанный и выпущенный в конце 90-х — начале 00-х, поставьте на него не менее древний Cisco IOS, в feature set которого отсутствуют упоминания о Context-Based Access Control (CBAC) и Zone-Based Policy Firewall (ZFW), ну или хотя бы не включайте их, если они там есть, и насладитесь оригинальным устойчивым вкусом. Cisco ASA не подойдут, они сделаны на базе линуха с IPtables, и потому в них SPI была изначально, и сразу с NATом.
Вот послали мы UDP-пакет на некий IP на порт 33434. Но ответ при достижении TTL=0 придет совсем с другого IP.
Ответ в рамках того же соединения не придёт, придёт оповещение ICMP, а это уже совершенно другой протокол, который в установленное ранее соединение уже не вписывается. То есть, межсетевой экран (МСЭ) на маршрутизаторе знает про соединение, например, TCP/UDP A.A.A.A:PortA <—> B.B.B.B:PortB, а ему внезапно прилетит ICMP C.C.C.C/TTL expired, которое и не TCP, и не UDP, и адрес отправителя в нём не B.B.B.B, ну и про порты в нём вообще ничего нет.
МСЭ, который не умеет SPI, такой пакет просто тупо удавит. Чтобы не сломать интернет, таким МСЭ приходится разрешать пропуск вообще любых ICMP TTL expired, admin prohibited и всё семейство unreachable откуда угодно, что представляет собой определённый риск.
А вот МСЭ, который умеет SPI, и у которого эта самая SPI включена, ловко расковыривает любое оповещение ICMP, достаёт из него оригинальный пакет, устанавливает по нему сведения о протоколе, а также те самые A.A.A.A:PortA, B.B.B.B:PortB, находит по ним соединение в своей таблице соединений и понимает, что он должен отправить оповещение ICMP в адрес инициатора соединения A.A.A.A. Ну или давит это оповещение ICMP, если искомое соединение в своей таблице он так и не нашёл.
C SPI для NAT просто добавляется ещё один шаг. Найдя совпадающее соединение, МСЭ затем смотрит в дополнительные поля записи таблицы соединений, в которых хранятся оригинальные адреса/номера портов до трансляции, выбирает из нужного поля оригинальный адрес инициатора соединения и отправляет оповещение уже ему.
Т.е., даже если включен на шлюзе Symmetric NAT или Adress Restricted NAT, то такой ICMP-ответ не будет сходу отброшен (как ответ для неизвестного вопрошающего), а сначала будет вскрыт, узнан порт исходящего UDP-соединения, адрес вопрошающего и ему туда ответ будет перенаправлен. Правильно понимаю?
Правильно понимаете. SPI — это великое изобретение, существенно упрощающее настройку МСЭ, а на его изобретателей вообще надо молиться :)
Ну я даже не знаю. Invalid device помню отчётливо, Illegal device не помню вообще.
У меня, конечно, где-то валяются дискеты с RT-11, и теоретически можно их раскопать и посмотреть строки внутри мониторов и системных утилит, но что-то мне лень эти дискеты искать :)
А что касается экрана ДВК-2, то у него, собственно, никакого экрана не было, зато был терминал 15ИЭ-00-013, и его можно было подключать к чему угодно, и вот это самое «что угодно» уже могло ругаться через этот терминал словами Illegal device.
Не совсем понятно, как будет проходить обратный ICMP-пакет через NAT?
Stateful packet inspection (SPI) for NAT. Если есть трансляция, открытая исходящим пакетом, и разрешено прохождение пакетов, относящихся к этому соединению, то оповещения ICMP, принятые маршрутизатором с NAT, будут перенаправлены этим маршрутизатором отправителю исходного пакета. Относится ли пакет с оповещением ICMP к какому-либо ранее открытому соединению, или нет, маршрутизатор узнаёт путём анализа вложенного в этот пакет исходного пакета (с уже транслированными им адресами/портами).
Например, в iptables для SPI предназначен модуль conntrack, и если в таблицу FORWARD добавить правило c разрешением (--jump ACCEPT) прохождения пакетов, связанных (RELATED) с состоянием соединения (connection state, --cstate): -m conntrack --cstate RELATED --jump ACCEPT, то это разрешит прохождение ответов ICMP даже в том случае, когда исходный пакет соединения был подвергнут трансляции адресов/портов.
Особенно, если на промежуточных роутерах включен Symmetric NAT или Port Restricted NAT или Adress Restricted NAT?
Виды NAT не имеют отношения к прохождению через них оповещений ICMP. Для прохождению ответов ICMP требуется, чтобы на этих самых промежуточных маршрутизаторах была включена и правильно настроена SPI for NAT для трафика, связанного с состоянием соединения.
По поводу "завезены и установлены", - вы слышали выражение "рязанский сахар"? Или "дело "Сети"?
Не, ну это Вы, считаю, зря. Генералов уже взрывали, причём в одном из случаев ЕМНИП камера, которой следили, была установлена как раз на самокате. Правда, и самокат стоял на приколе, и что-то вроде «Клеймора» было установлено уже по завершении слежки, а не до.
… тотальный контроль переписки и данных. Тенденции везде, почему-то, очень похожие.
Не согласен. Здесь нужен анализ большого объёма данных в одном месте.
У меня был опыт решения подобной задачи с помощью SiLK CERT NSA tools. Особо больших объёмов данных это, вроде бы, и не требовало. По сравнению с объёмами самого трафика объёмы обрабатываемых мною данных о сеансах передачи данных были, скажем прямо, микроскопическими, потому что первичную обработку трафика для экспорта этих сведений по протоколу NetFlow выполняли сами граничные маршрутизаторы своими SoC'ами. Вместо всего трафика они отдавали только записи о том откуда, куда, по какому протоколу, с какого порта на какой порт, время начала и время окончания передачи, а также флаги TCP/ICMP. Нагрузка на маршрутизаторы после включения экспорта NetFlow если и возросла, то это было совершенно незаметно.
Ну и надо сказать спасибо дизайнерам этих самих SiLK CERT NSA tools: благодаря грамотной упаковке данных NetFlow поиск и генерация отчётов по формируемой базе данных происходили практически моментально, особенно если брать окно размером всего в сутки, как я выше предлагал.
Если исключить обновления - то трансграничный трафик из моей сети - это может быть куча всего, даже включенный торрент генерирует трансграничный трафик по рандомным ip адресам, игры генерируют трансграничный трафик и их не так просто включить в "общеизвестные", они вполне предоставляют выделенные сервера для узкой группы лиц, webrtc стримы с вебкамер, экзотическая аппаратарура коей немало (всякие 3д принтерны, которые могут быть вообще в штучном количестве в стране).
Так в том-то и дело, что торрентокачалка — это короткие соединения с огромным количеством разных адресов, а VPN-туннель — это устойчивый трафик между двумя адресами, который не прерывается в течение суток. Особенно если в туннеле включить keepalive. Про стримы с вебкамер ничего определённого не скажу, не щупал, про 3D принтеры — не понимаю, зачем им нужно устойчивое соединение с одним и тем же адресом, висящее сутки напролёт.
P.S. Если Вы решили, что я предлагал сортировать статистику по суммарному объёму трафика между парами адресов и искать наибольший, то это не всё. Есть ещё вариант брать соединения за сутки и смотреть, когда в эти сутки трафик между конкретной парой адресов начался, а когда — закончился, а затем сортировать по наибольшей длине интервала между этими двумя событиями. Так можно выявлять пары адресов, между которыми существует устойчивый круглосуточный трафик, а на что это больше всего похоже? На VPN-туннель это похоже.
Мой ПК 24/7 долбиться к microsoft сливая телеметрию, а ещё у Гуглу и куче других сервисов. Иногда объем трафика большей (качаем обновления/гугл карты/etc), иногда маленький.
Во первых, туда долбится не только Ваш ПК. Туда долбятся миллиарды, а из нашей страны —миллионы. Вот по этому признаку их очень быстро можно исключить из списков VPN.
А ещё можно составить список DNS имён широко известных сервисов в сети интернет, поднять у себя на ТСПУ кэширующий сервер DNS и постоянно ресолвить имена из этого списка впрямую на самих ТСПУ, а затем пробивать адреса из статистики NetFlow из кэша своего сервера DNS на предмет того, что же это за имя. И так можно будет гарантированно исключить соединения с широко известными сервисами.
Во-вторых, вы же не пускаете трафик к серверам Microsoft и Гуглу непосредственно c MY.VPN? Правильно, не пускаете. Он ведь у Вас либо идёт через туннель MY.VPN <—> FREEDOM.VPN1, либо, если эти сервера не заблокированы, вообще даже не доходит до MY.VPN, а уходит в интернет непосредственно с Вашей машины, ведь трафик MY.VPN надо экономить, правильно? Поэтому, если исключить обновления ПО, то единственный трансграничный трафик вашего MY.VPN — это трафик VPN-туннеля MY.VPN <—> FREEDOM.VPN1.
Объем трафика через тоннель с разеделем у меня когда я ещё мониторил это - был около 10-15гб, что в общем потоке 350гб идущих даже не особо заметно. Иногда он был большой (смотрим Ютуб), иногда маленький (служебный трафик для поддержки соединения или чисто веб).
Вот как только из статистики NetFlow будут исключены соединения с общеизвестными сервисами, так сразу на верхнюю строчку трансграничного трафика вылезет длительно висящее соединение MY.VPN <—> FREEDOM.VPN1, и ничего Вы с этим сделать не сможете.
Да факт соединения - спалится. Но что это за соединение? Обычная часть микросервисной архитектуры, где микросервси стучится в другой? Или это VPN?
Было бы можно такое отличить методом анализа трафика, разве стали бы они городить огород со стукачами?
Зачем отличать? Блокируем, а затем внимательно слушаем эфир: если снизу начинают раздаваться действительно массовые злобные истеричные выкрики, слышно, как кто0то швыряет в стену телефонный аппарат, кто-то в сердцах хлопает дверью, а потом нам звонят сверху и вежливым матом объясняют, что мы наступили ногой на горло бизнесу уважаемых людей, и эти уважаемые люди уже вот прям щаз теряют кучу бабок в минуту — значит, мы заблокировали что-то не то. Тут важно, чтобы низы и верхи взбунтовались одновременно. Если бунтуют только низы и в микроскопических объёмах — значит, мы нащупали и пристрелили чей-то микроскопический бизнес по продаже услуг того самого трёхзвенного VPN.
Всё нормально, это древний и весьма уважаемый способ составления правил межсетевого экрана в информационных системах, когда никто из сотрудников уже не в состоянии внятно объяснить, кто и куда должен иметь доступ и по каким протоколам, потому что никто не знает, как и что устроено ввиду того, что критически важные элементы инфраструктуры разрабатывались и внедрялись лет десять тому назад, на коленке и без надлежащего документирования, а кто знает, тот уже не помнит, а кто ещё помнит — те давно релоцировались: редкие счастливчики — в верхние эшелоны мегакорпораций, и теперь им нельзя просто так взять и позвонить, кто на удивительное Бали, кто в психушку (ночные смены и работа по двенадцать часов в сутки, ага), а кто и вообще на кладбище.
Уважаемые коллеги! Вам не приходило в голову, что все эти ваши трёхзвенные схемы легко вскрываются, стоит только заняться анализом статистики соединений? Вы же, наверно, в курсе, что есть такая замечательная вещь, как NetFlow различных версий, и что среди провайдеров принято вынимать c его помощью сведения о сеансах связи с граничных маршрутизаторов? И, наверное, понимаете, что совершенно ничего не мешает накапливать эти сведения, а затем сгруппировать сеансы связи по парам «адрес источника» — «адрес назначения» и таким образом выявить устойчивую связь между вашими MY.VPN и FREEDOM.VPN1?
Вы ж через этот самый MY.VPN непрерывно долбитесь во FREEDOM.VPN1, и он, само собой, отвечает вам через него взаимностью? Ведь долбитесь же, да? Ага, я так и думал. Так что адрес этого самого FREEDOM.VPN1 вы спалите просто самим фактом постоянного трансграничного трафика между ним и MY.VPN.
Ну а если провайдер по какой-то странной причине не выгружает сведения о соединениях со своих граничных маршрутизаторов сам, всегда есть ТСПУ, через которые проходит весь трафик и на которых можно накапливать нужную статистику соединений по парам адресов источника и назначения, или оборудование СОРМ, которое вообще обязано хранить весь трафик с этими самыми адресами за три последних месяца. Сиди, да считай не спеша нужную статистику, а затем блокируй выявленные адреса FREEDOM.VPN1 квадрадно-гнездовым методом, поблочно.
Да, для шпионской камеры с впн будет проблемой, что приложение от Сбера/Яндекса/ВБ детектит впн.
По моему скромному ограниченному дилетантскому мнению, шпионская камера с VPN не должна выделяться на фоне миллионов мобильников, использующих VPN для обеспечения работы телеграма, инстаграма и прочих линкединов, потому, что если она начнёт чем-то выделяться, её мгновенно спалят. А это значит, что все меры, которые будут использованы против обычных людей с их VPN, помогут и против шпионской камеры.
P.S. Кстати, по моему мнению, прокатные электросамокаты и электровелосипеды — наилучшие устройства для размещения шпионских камер: всегда есть питание и можно задействовать добровольных и не очень помощников для скрытого наблюдения за целью в процессе движения. А если эти камеры размещать на средствах индивидуальной мобильности ещё и массово, можно вообще закрыть вопрос с наружным наблюдением. Возможно, эти самые средства запрещают ещё и по этой причине.
Если у соседей уже есть свой вайфай, то они обязательно помянут Вас тихим незлым словом, когда Вы повесите на своем доме три дальнобойные внешние точки доступа с секторными антеннами, накрывающими участок этих соседей. Особенно незлыми будут эти слова, если вы каждой такой точкой накроете полосу в 80МГц вместо 20 в диапазоне 2,4ГГц :)
P.S. Я не преувеличиваю, это совершенно реальный случай.
Упс. В строку
закралась лишняя точка после 255.0.0.0 . Должно быть:
А что, никто не пользуется proxy autoconfiguration? Вниманию тех, кто пользуется, предлагается функция на JScript для поиска прокси из ассоциативного массива, соответствующего наиболее детальному домену из указанных, типа most detailed route, которая может до определённой степени заменить поиск прокси по шаблону имени хоста.
Функция может с успехом использоваться в дебрях proxy autoconfiguration file.
Ну так я ж давно живу. Я ещё ipchains настраивал, в них никакого conntrack'а не было. И древние циски родом из 90-х годов прошлого века тоже настраивал, в которых даже расширенных ACL не было, не говоря уже о CBAC или ZFW.
Что совершенно неудивительно, потому что в них уже был встроен SPI с поддержкой NAT. Я ж говорю, создателям SPI надо памятник при жизни поставить.
Самый простой вариант заключается в том, чтобы взять любой работающий линуксовый МСЭ на iptables, удалить из его таблиц все правила, в которых фигурирует conntrack, после чего можно будет поглядеть на отвалившийся PMTUD и на неработающую трассировку.
Команда для удаления всех правил, в которых упомянут conntrack:
Если хочется приобщиться к старине, найдите где-нибудь древний маршрутизатор Cisco, разработанный и выпущенный в конце 90-х — начале 00-х, поставьте на него не менее древний Cisco IOS, в feature set которого отсутствуют упоминания о Context-Based Access Control (CBAC) и Zone-Based Policy Firewall (ZFW), ну или хотя бы не включайте их, если они там есть, и насладитесь оригинальным устойчивым вкусом. Cisco ASA не подойдут, они сделаны на базе линуха с IPtables, и потому в них SPI была изначально, и сразу с NATом.
Ответ в рамках того же соединения не придёт, придёт оповещение ICMP, а это уже совершенно другой протокол, который в установленное ранее соединение уже не вписывается. То есть, межсетевой экран (МСЭ) на маршрутизаторе знает про соединение, например, TCP/UDP A.A.A.A:PortA <—> B.B.B.B:PortB, а ему внезапно прилетит ICMP C.C.C.C/TTL expired, которое и не TCP, и не UDP, и адрес отправителя в нём не B.B.B.B, ну и про порты в нём вообще ничего нет.
МСЭ, который не умеет SPI, такой пакет просто тупо удавит. Чтобы не сломать интернет, таким МСЭ приходится разрешать пропуск вообще любых ICMP TTL expired, admin prohibited и всё семейство unreachable откуда угодно, что представляет собой определённый риск.
А вот МСЭ, который умеет SPI, и у которого эта самая SPI включена, ловко расковыривает любое оповещение ICMP, достаёт из него оригинальный пакет, устанавливает по нему сведения о протоколе, а также те самые A.A.A.A:PortA, B.B.B.B:PortB, находит по ним соединение в своей таблице соединений и понимает, что он должен отправить оповещение ICMP в адрес инициатора соединения A.A.A.A. Ну или давит это оповещение ICMP, если искомое соединение в своей таблице он так и не нашёл.
C SPI для NAT просто добавляется ещё один шаг. Найдя совпадающее соединение, МСЭ затем смотрит в дополнительные поля записи таблицы соединений, в которых хранятся оригинальные адреса/номера портов до трансляции, выбирает из нужного поля оригинальный адрес инициатора соединения и отправляет оповещение уже ему.
Правильно понимаете. SPI — это великое изобретение, существенно упрощающее настройку МСЭ, а на его изобретателей вообще надо молиться :)
Спасибо!
Ну я даже не знаю. Invalid device помню отчётливо, Illegal device не помню вообще.
У меня, конечно, где-то валяются дискеты с RT-11, и теоретически можно их раскопать и посмотреть строки внутри мониторов и системных утилит, но что-то мне лень эти дискеты искать :)
А что касается экрана ДВК-2, то у него, собственно, никакого экрана не было, зато был терминал 15ИЭ-00-013, и его можно было подключать к чему угодно, и вот это самое «что угодно» уже могло ругаться через этот терминал словами Illegal device.
Это весьма древненькое.
Это со всяких клонов OS/360, что ли?
Это DEC RT-11 со своим характерным сообщением об ошибке ?KMON-F-Invalid device <dev:>
КОИ-7 — это большие русские буквы вместо маленьких латинских. Маленьких латинских букв нет, маленьких русских букв нет
, населена роботами.Stateful packet inspection (SPI) for NAT. Если есть трансляция, открытая исходящим пакетом, и разрешено прохождение пакетов, относящихся к этому соединению, то оповещения ICMP, принятые маршрутизатором с NAT, будут перенаправлены этим маршрутизатором отправителю исходного пакета. Относится ли пакет с оповещением ICMP к какому-либо ранее открытому соединению, или нет, маршрутизатор узнаёт путём анализа вложенного в этот пакет исходного пакета (с уже транслированными им адресами/портами).
Например, в iptables для SPI предназначен модуль conntrack, и если в таблицу FORWARD добавить правило c разрешением (--jump ACCEPT) прохождения пакетов, связанных (RELATED) с состоянием соединения (connection state, --cstate):
-m conntrack --cstate RELATED --jump ACCEPT, то это разрешит прохождение ответов ICMP даже в том случае, когда исходный пакет соединения был подвергнут трансляции адресов/портов.Виды NAT не имеют отношения к прохождению через них оповещений ICMP. Для прохождению ответов ICMP требуется, чтобы на этих самых промежуточных маршрутизаторах была включена и правильно настроена SPI for NAT для трафика, связанного с состоянием соединения.
Сложно, да, но зато какие перспективы!
Не, ну это Вы, считаю, зря. Генералов уже взрывали, причём в одном из случаев ЕМНИП камера, которой следили, была установлена как раз на самокате. Правда, и самокат стоял на приколе, и что-то вроде «Клеймора» было установлено уже по завершении слежки, а не до.
Ещё бы.
К «Железной пяте», вестимо.
У меня был опыт решения подобной задачи с помощью SiLK CERT NSA tools. Особо больших объёмов данных это, вроде бы, и не требовало. По сравнению с объёмами самого трафика объёмы обрабатываемых мною данных о сеансах передачи данных были, скажем прямо, микроскопическими, потому что первичную обработку трафика для экспорта этих сведений по протоколу NetFlow выполняли сами граничные маршрутизаторы своими SoC'ами. Вместо всего трафика они отдавали только записи о том откуда, куда, по какому протоколу, с какого порта на какой порт, время начала и время окончания передачи, а также флаги TCP/ICMP. Нагрузка на маршрутизаторы после включения экспорта NetFlow если и возросла, то это было совершенно незаметно.
Ну и надо сказать спасибо дизайнерам этих самих SiLK CERT NSA tools: благодаря грамотной упаковке данных NetFlow поиск и генерация отчётов по формируемой базе данных происходили практически моментально, особенно если брать окно размером всего в сутки, как я выше предлагал.
Так в том-то и дело, что торрентокачалка — это короткие соединения с огромным количеством разных адресов, а VPN-туннель — это устойчивый трафик между двумя адресами, который не прерывается в течение суток. Особенно если в туннеле включить keepalive. Про стримы с вебкамер ничего определённого не скажу, не щупал, про 3D принтеры — не понимаю, зачем им нужно устойчивое соединение с одним и тем же адресом, висящее сутки напролёт.
P.S. Если Вы решили, что я предлагал сортировать статистику по суммарному объёму трафика между парами адресов и искать наибольший, то это не всё. Есть ещё вариант брать соединения за сутки и смотреть, когда в эти сутки трафик между конкретной парой адресов начался, а когда — закончился, а затем сортировать по наибольшей длине интервала между этими двумя событиями. Так можно выявлять пары адресов, между которыми существует устойчивый круглосуточный трафик, а на что это больше всего похоже? На VPN-туннель это похоже.
Для описанного мною случая много ресурсов не надо. ТСПУ со своим онлайн DPI потребляет существенно больше.
Что, тот же LanDroid не сможет выполнить трассировку до хоста, доступного через VPN, при работе VPN через tun?
Во первых, туда долбится не только Ваш ПК. Туда долбятся миллиарды, а из нашей страны —миллионы. Вот по этому признаку их очень быстро можно исключить из списков VPN.
А ещё можно составить список DNS имён широко известных сервисов в сети интернет, поднять у себя на ТСПУ кэширующий сервер DNS и постоянно ресолвить имена из этого списка впрямую на самих ТСПУ, а затем пробивать адреса из статистики NetFlow из кэша своего сервера DNS на предмет того, что же это за имя. И так можно будет гарантированно исключить соединения с широко известными сервисами.
Во-вторых, вы же не пускаете трафик к серверам Microsoft и Гуглу непосредственно c MY.VPN? Правильно, не пускаете. Он ведь у Вас либо идёт через туннель MY.VPN <—> FREEDOM.VPN1, либо, если эти сервера не заблокированы, вообще даже не доходит до MY.VPN, а уходит в интернет непосредственно с Вашей машины, ведь трафик MY.VPN надо экономить, правильно? Поэтому, если исключить обновления ПО, то единственный трансграничный трафик вашего MY.VPN — это трафик VPN-туннеля MY.VPN <—> FREEDOM.VPN1.
Вот как только из статистики NetFlow будут исключены соединения с общеизвестными сервисами, так сразу на верхнюю строчку трансграничного трафика вылезет длительно висящее соединение MY.VPN <—> FREEDOM.VPN1, и ничего Вы с этим сделать не сможете.
Зачем отличать? Блокируем, а затем внимательно слушаем эфир: если снизу начинают раздаваться действительно массовые злобные истеричные выкрики, слышно, как кто0то швыряет в стену телефонный аппарат, кто-то в сердцах хлопает дверью, а потом нам звонят сверху и вежливым матом объясняют, что мы наступили ногой на горло бизнесу уважаемых людей, и эти уважаемые люди уже вот прям щаз теряют кучу бабок в минуту — значит, мы заблокировали что-то не то. Тут важно, чтобы низы и верхи взбунтовались одновременно. Если бунтуют только низы и в микроскопических объёмах — значит, мы нащупали и пристрелили чей-то микроскопический бизнес по продаже услуг того самого трёхзвенного VPN.
Всё нормально, это древний и весьма уважаемый способ составления правил межсетевого экрана в информационных системах, когда никто из сотрудников уже не в состоянии внятно объяснить, кто и куда должен иметь доступ и по каким протоколам, потому что никто не знает, как и что устроено ввиду того, что критически важные элементы инфраструктуры разрабатывались и внедрялись лет десять тому назад, на коленке и без надлежащего документирования, а кто знает, тот уже не помнит, а кто ещё помнит — те давно релоцировались: редкие счастливчики — в верхние эшелоны мегакорпораций, и теперь им нельзя просто так взять и позвонить, кто на удивительное Бали, кто в психушку (ночные смены и работа по двенадцать часов в сутки, ага), а кто и вообще на кладбище.
Шучу. А может, и не шучу ;)
Спасибо!
Уважаемые коллеги! Вам не приходило в голову, что все эти ваши трёхзвенные схемы легко вскрываются, стоит только заняться анализом статистики соединений? Вы же, наверно, в курсе, что есть такая замечательная вещь, как NetFlow различных версий, и что среди провайдеров принято вынимать c его помощью сведения о сеансах связи с граничных маршрутизаторов? И, наверное, понимаете, что совершенно ничего не мешает накапливать эти сведения, а затем сгруппировать сеансы связи по парам «адрес источника» — «адрес назначения» и таким образом выявить устойчивую связь между вашими MY.VPN и FREEDOM.VPN1?
Вы ж через этот самый MY.VPN непрерывно долбитесь во FREEDOM.VPN1, и он, само собой, отвечает вам через него взаимностью? Ведь долбитесь же, да? Ага, я так и думал. Так что адрес этого самого FREEDOM.VPN1 вы спалите просто самим фактом постоянного трансграничного трафика между ним и MY.VPN.
Ну а если провайдер по какой-то странной причине не выгружает сведения о соединениях со своих граничных маршрутизаторов сам, всегда есть ТСПУ, через которые проходит весь трафик и на которых можно накапливать нужную статистику соединений по парам адресов источника и назначения, или оборудование СОРМ, которое вообще обязано хранить весь трафик с этими самыми адресами за три последних месяца. Сиди, да считай не спеша нужную статистику, а затем блокируй выявленные адреса FREEDOM.VPN1 квадрадно-гнездовым методом, поблочно.
По моему скромному ограниченному дилетантскому мнению, шпионская камера с VPN не должна выделяться на фоне миллионов мобильников, использующих VPN для обеспечения работы телеграма, инстаграма и прочих линкединов, потому, что если она начнёт чем-то выделяться, её мгновенно спалят. А это значит, что все меры, которые будут использованы против обычных людей с их VPN, помогут и против шпионской камеры.
P.S.
Кстати, по моему мнению, прокатные электросамокаты и электровелосипеды — наилучшие устройства для размещения шпионских камер: всегда есть питание и можно задействовать добровольных и не очень помощников для скрытого наблюдения за целью в процессе движения. А если эти камеры размещать на средствах индивидуальной мобильности ещё и массово, можно вообще закрыть вопрос с наружным наблюдением. Возможно, эти самые средства запрещают ещё и по этой причине.
Если у соседей уже есть свой вайфай, то они обязательно помянут Вас тихим незлым словом, когда Вы повесите на своем доме три дальнобойные внешние точки доступа с секторными антеннами, накрывающими участок этих соседей. Особенно незлыми будут эти слова, если вы каждой такой точкой накроете полосу в 80МГц вместо 20 в диапазоне 2,4ГГц :)
P.S. Я не преувеличиваю, это совершенно реальный случай.