CityCat4

VBox-овский конвертер не сжует?

Как у всех микротиков с программным шифрованием, здесь IPSec ессно будет тормозить. Если главное применение VPN - нужно брать с аппаратным шифрованием, например RB760 (HEX S)
Ну и кроме того, логи надо смотреть - может там идет постоянное переподключение. DPD например я всегда выключаю - от него только один вред.

Для обычного сквида достаточно блокировки выхода в обход прокси.
Сквид без бампинга сейчас практически бесполезен - все на https. Без бампинга захватывается сайт из CONNECT, что может быть совсем не то, куда пошел юзер.
Я приводил уже пример:
юзер создает сайт с унылым производственным именем metricheskiy-krepeg.ru (или еще каким, но таким, чтобы соответствовал тематике производства и вызывал у админов чувство уныния :) ). А внтури делает страничку с переходами на ВКонтактик, love.mail.ru и tightwetholes.com :)
Вопрос: что увидит админ в логе прокси

VPN-типов в микротике зиллион. Вяжете, настраиваете маршрутизацию (если вяжете по IPSec - не надо). При необходимости можно развести пакеты маркировкой. Вполне себе стандартная задача.

В текущих условиях задача не имеет решения.

Нужен прокси, умеющий бампинг, squid например. Без бампинга статистика будет неверной (зашел юзер по https на ничем не примечательный metrichesky-krepeg.ru - а это им же управляемый сайт, внутри которого переходы на вконтактик и tightwetholes.com :) И хрен Вы догадаетесь, что юзер сейчас смотрит порно и соцсети :) )

кстати tcp-flags=syn не работает...а функцию надо включить на все протоколы

В протоколах, отличных от TCP нет и не может быть флага SYN

Вы случайно ограничение лицензии RouterOS не превысили?

IPSec.

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

Ну в общем отвечаю сам себе :) Замена БП не помогла, помогла повторная прошивка через netinstall.

Нет нигде такого описания. Гуглить PKI, X.509 и тому подобное. Можно маны на openssl почитать. Это фактически конструктор, где каждый сам себе строит то, что хочет.
Есть книга "Построение защищенных корпоративных сетей", там есть пара глав про сертификаты, но там в основном про то, как их запрашивать и выпускать, а также как настраивать под них разную софтину.

Теги неверные: сертификаты применяются очень много где, не только в openVPN

а в цепочке filter трафик разрешен?

И вообще реальна ли эта задача?

Окей, гугл
Что такое BGP
Какой нужен маршрутизатор на BGP fullview

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

не используя какой либо из vpn?

Никак. И очень советую почитать про то, что такое VPN.

различие...İpsec а в транспортном и туннельном режиме

Это в гугл.

Порядок создания опишу завтра - если кто-то другой не напишет раньше :)

Берем простейший случай - аутентификация по PSK (Pre-Shared Keys, то бишь простому текстовому паролю). Текст пароля "123456" (понятно, что если реализовывать такой вариант, пароль должен быть посерьезней)

Внешние интерфейсы, смотрящие в тырнет:
система А - 170.70.70.1
система Б - 180.80.80.1
(обязательно поменяйте их на свои!)

Внутренние интерфейсы, смотрящие в спариваемые локалки:
система А - 10.1.1.1
система Б - 10.2.2.1
маски у обеих сетей - /24 (255.255.255.0)

итак погнали.

RouterOS 6.45.7
значения по умолчанию не указываются
Система А (на системе Б будет все тоже, только перевернуто зеркально)

Шаг 0 - создаем предложение
Этот шаг необязательный

/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1

Самое первое - создаем proposal. Это наше предложение другой стороне о том, какие мы поддерживаем шифры и какие методы подписи пакетов. Выбираем самое сильное шифрование AES256 со счетчиком Галуа, отдельная подпись пакета не потребуется. Здесь же мы задали время жизни туннеля до неполного переустановления - 1 час.
Этот шаг необязательный, он нужен только для усиления защиты туннеля. Без него будет набор из более простых шифров типа AES128 CBC с SHA1 в качестве алгоритма подписи пакета

Шаг 1 - создаем профиль соединения

/ip ipsec profile
add dpd-interval=disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h name=profile1 \
    nat-traversal=no proposal-check=strict

Отключаем DPD - от него только проблемы, устанавливаем более мощные чем по умолчанию алгоритмы шифрования и хэширования (default encrypt может быть и 3DES, default hash - SHA1), устанавливаем время жизни туннеля 2 часа (после - полная переустановка соединения со сбросом ключей шифрования), отключаем NAT Travesal, указываем обработку предложений strict (очень важный параметр! Если время жизни туннеля, запрошенное той стороной больше чем задано у нас - послать, если меньше или равно - принять)

Шаг 2 - создаем напарника (данные об удаленной системе)

/ip ipsec peer
add address=170.70.70.1/32 comment="Main VPN" name=RB2011 profile=profile1

Тут даже пояснять ничего не надо, все самоочевидно

Шаг 3 - создаем политику

/ip ipsec policy
add dst-address=10.2.2.0/24 peer=RB2011 proposal=proposal1 src-address=10.1.1.0/24 tunnel=yes

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

Шаг 4 - создаем идентификаторы (identity). Раньше в IPSec у микротика было меньше сущностей и обьяснение было проще...

/ip ipsec identity
add peer=RB2011 secret=123456

Естественно возникает вопрос - а как же микротик узнает, куда девать пакеты? А это записано у него в настройках - все пакеты с сети 10.1.1.0/24 на 10.2.2.0/24 зашифровать и отправить на 170.70.70.1, все пакеты же с 170.70.70.1 протокола ESP нужно расшифровать и обработать повторно.
Вообще для того, чтобы понять, как ходят пакеты в IPSec - есть отличная схема Packet Flow in Netfilter and General Networking

Схема есть? Если нет - надо построить и помедитировать над распределением адресов и тем фактом, что в сети может быть "лишний" dhcp.

Я правильно понимаю, что это у нас новая инкарнация чемпиона бредовых вопросов Freedom_Toster , он же Nickname_not_name? Тот же стиль, тот же "качественно нелепый" бред, как будто чел сидит, читает Олиферов и по ходу чтения выдает какие-то фееричные вещи, которые нарочно не придумаешь...

Если шифрование и защищенность не важна - то какой угодно, хоть pptp. Если важна - IPSec.
Два белых IP упростят настройку, но важно наличие одного, тогда соединение всегда устанавливает второй (который с серым IP). Если есть два, то пофиг кто устанавливает соединение.

Тут надо немного поработать головой... Маршрутизация, что в микротике, что в шване - она будет политиками делаться, от политик и нужно плясать, учитывая то, что политика воспринимается буквально.
Как я себе это представляю:
Пакет, например от 192.168.1.1 на 192.168.77.1 приходит на микротик А. Политика предписывает этот пакет зашифровать и упаковать в ESP, где IP src 10.22.10.1, IP dst 10.22.10.2. Микротик А должен знать, как доставить этот пакет, и он знает.
Пакет пришел на швана. Шван расшифровал его и видит пакет от 192.168.1.1 на 192.168.77.1. Он должен знать, что с ним делать :) иначе фиганет его на default route. То есть у швана должна быть политика, говорящая, что ему делать с пакетом от 192.168.1.1 на 192.168.77.1, а ее похоже нет. Тогда он поступит в соответствии с политикой.