CityCat4

Нет нигде такого описания. Гуглить 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, а ее похоже нет. Тогда он поступит в соответствии с политикой.

Хоть десять провайдеров :) микротик позволяет.

Политики IPSec настроены? В них правильно указаны подсети, публичные адреса IP-шлюзов?
IKE и ESP не фильтруются?

Максимальная простота, если пофиг на шифрование - PPTP. Его все знают, все умеют.