Если надо, чтобы он смотрел внутрь урлек, то надо, чтобы он подменял сертификаты для https

Иначе немного бесполезно все

И мне кажется, что такого софта/железок бесплатно не существует (

Ну и приложухи он сможет очень посредственно определять

По крайней мере на опыте стоунгейтов я поняла, что это сомнительное действо. Возможно великий и могучий Стоун тоже не всемогущ, но по мне так, если уж параноить, то надо ставить длп систему

либо прокси с подменой сертификатов, либо с клиентов напрямую снимать, да

И подключать ее к анализатору трафика)

Можно без прокси) просто менять сертификаты

как это?

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

кокрастыке в энтерпрайзах для корпоративного митма и используется

Хм

Ну окей

он может быть прозрачным, так что клиент даже у себя ничего не прописывает

вообще не знает о существовании этого прокси

Как это? Если менять сертификат, то клиенту надо как минимум сказать об этом сертификате. Можно взять доменный, если домен есть

Но в целом клиент должен доверять сертификату.

Или покупать его у какого-нибудь очень распространенного ЦС

ну естественно, мы сейчас говорим об энтерпрайзных сценариях, где есть свой самостийный трастед рут

покупать не вариант в 99.9999% случаев

Почему? Кроме того, что дорого и сильно заморочно?

Вообще-то я действительно не знаю, можно ли купить сертификат с возможностью выпуска сертификатов

потому что вы будете покупать сертификат на любое Subject Name, который подписан УЦ, которому доверяют вообще все компьютеры в мире

Если надо, чтобы он смотрел внутрь урлек, то надо, чтобы он подменял сертификаты для https

ненене, это не рассматривается.

ну или сертификат на intermediate ca, который такие серты сможет выпустить

такие услуги существуют на рынке, но это штучные решения

ну это свой УЦ получается надо

Ну в целом наверное можно. Сейчас же каждый третий уц строит

Я спрашивал именно про netflow

дорого это наверно

ненене, это не рассматривается.

Как вы тогда Ютуб от соцсетей различать хотите?

если вы не microsoft и не google, то это не ваш вариант

не про прокси, подмены сертов (тут надо вспомнить про hsts) и т.д.

hsts, certificate pinning, public key pinning, dane и много других прикольных штук, да

Как вы тогда Ютуб от соцсетей различать хотите?

Ну по пулам, например?

Я вот нашел ntop и plixer

пишут, что могут

Нууу( это не интересно, чуть более, чем полностью

Видимо, там собранные базы свои и т.д.

Я как-то пыталась вычислить адреса серверов тимвьюера)

Бесполезное занятие)

Кстати даже не для запрета, а чтобы работал

по AS?

Кстати даже не для запрета, а чтобы работал

Есть решения как на сквиде его зарубить вроде :)

Есть решение как его загубить железкой

Fortinet к примеру

Есть решения как на сквиде его зарубить вроде :)

очень легко. достаточно заблокировать teamviewer.com

у меня squid + rejik прекрасно блокируют что надо.

Привет

Кто может объяснить разницу все таки между rd и rt, первый к маршрутам добавляеться а второй то же в bgp отпрааляеться так в чем разность? Они оба делают уникальный маршрут

первый делает уникальным, второй комьюнити

Зачем два?

очень легко. достаточно заблокировать teamviewer.com

Хм... На сколько я знаю, он таки по айпи идёт,а не днски. Это во-первых, а во-вторых, мне надо было,чтобы он как раз работал)

Хм... На сколько я знаю, он таки по айпи идёт,а не днски. Это во-первых, а во-вторых, мне надо было,чтобы он как раз работал)

Лески? Не знаю что такое. Но, днс использутется. В логах адреса вроде ping3.teamviewer.com, master5.teamviewer.com

Днски*

Кстати даже не для запрета, а чтобы работал

но мне не для запрета. Мне для классификации

Зачем два?

первый отвечает за уникальность, второй - за игры с перекладываниями маршрутов

причем route target'ов может быть много

самый простой вариант - есть три сайта, S1, S2 и S3. мы хотим отдать некоторые префиксы из сайта S1 в S2 и S3, а некоторые - только в S2

мы в абсолютно любом случае должны повесить на каждый префикс уникальный идентификатор, потому нам понадобится RD

и еще нам понадобится две метки: "во все сайты" и "только в S2"

вот эти метки и есть route target'ы

кстати в режике есть списки сайтов, по категориям, поддерживается сообществом, и то они далеко не совершенны. для сквида нужная вещь, но разбирать сырой нетфлоу, дело наблагодарное.

Вопрос, rd обязательно должно присутсвовать в rt export?

нет

равно в rt export не должны обязательно присутствовать хаотичность, чревовещатели, розовые слоны и заболевания, передающиеся половым путем

равно в rt export не должны обязательно присутствовать хаотичность, чревовещатели, розовые слоны и заболевания, передающиеся половым путем

А это точно про бгп?

ERROR: S client not available

А это точно про бгп?

да, этой фразы в rt export тоже быть не должно

там должны быть только метки route target

в некоторых имплементациях они могут задаваться визуально схожим с RD образом

но это чистой воды случайность

RD - это часть адреса vpnv4, 8 байт. у него нет никакой иной функции, кроме одной - сделать итоговый vpnv4 адрес уникальным

RT - это коммунити, метка, которую можно навесить на маршрут в отдельном атрибуте, extended community

у одного маршрута этих меток может быть много ии не быть ни одной

(хотя, возможно, насчет последнего я гоню)

нет, не гоню. у не-впнв4 маршрутов вполне может не быть

RD - это часть адреса vpnv4, 8 байт. у него нет никакой иной функции, кроме одной - сделать итоговый vpnv4 адрес уникальным

Зачем еслм еще в community добавляеться rt export метка

потому что впнв4 адрес должен быть другого формата

может добавиться, а может и нет. а может, добавится несколько. а может быть, мы вообще из разных врфов захотим в один префиксы вбросить

так что rd - универсальный механизм обеспечения уникальности маршрута

а rt - универсальный механизм распространения маршрутов

Зачем еслм еще в community добавляеться rt export метка

linkmeup.ru/blog/204.html

разные поля, имеют разные задачи

linkmeup.ru/blog/204.html

Так я это и читаю

У меня не с пустого места возник вопрос

И все равно не понятно

хм, там, вроде все очень понятно написано

смотри, тут главное - понять, зачем нужны RT

после этого отпадет вопрос "а зачем нужен RD"

Мы можем же в vrf написать так rd 65001:200 и rt export 65001:300 в пакете bgp он уйдет к другому PE а на другом конце как правильно писать rt import 65001:300 или rt import 65001:200 ?????

пусть у нас есть три сайта: S1, S2 и S3, в каждом по одному PE-роутеру: - мы договариваемся использовать три метки на маршрутах: то, что нужно передать в S1 (65001:1), в S2 (65001:2), и в S3 (65001:3) - и у нас есть маршруты, которые надо из S1 передать только в S2, мы на них вешаем только одну метку 65001:2 - и есть маршруты, которые надо из S1 передать и в S2, и в S3, мы на них вешаем две метки 65001:2 и 65001:3

"метки" = route target

тут понятно?

пусть у нас есть три сайта: S1, S2 и S3, в каждом по одному PE-роутеру: - мы договариваемся использовать три метки на маршрутах: то, что нужно передать в S1 (65001:1), в S2 (65001:2), и в S3 (65001:3) - и у нас есть маршруты, которые надо из S1 передать только в S2, мы на них вешаем только одну метку 65001:2 - и есть маршруты, которые надо из S1 передать и в S2, и в S3, мы на них вешаем две метки 65001:2 и 65001:3

На маршруты же нельзя повесить rt? Он же в vrf вешаеться

в контексте vrf он настраивается на оборудовании вендора Ц

а фактически по сети route target'ы передаются в сообщениях апдейт, применительно к каждому NLRI

Ну и они ко всем NLRI применяются

это еще почему