r1sh Опубликовано 25 июля, 2018 · Жалоба Добрый день. Раньше я как-то настраивал ipsec туннели на cisco и vyos и не парился, а сейчас я прочитал про туннелирование: gre - без шифрования ipsec - тот самый с шифрованием ipsec over gre - шифруем пакет и посылаем через gre туннель gre over ipsec - хз зачем Мне не до конца понятные прикладное применение этих туннелей, для каких случаев какие использовать? Например у меня есть: 1. сервер в цоде, на нём стоит гипервизор и 5 виртуалок: RouterOS + 4 Win2012r2 сервера 2. два отдельных офиса, в каждом стоит Микротик Нужно организовать доступ из подсети каждого офиса в подсеть серверов. Какие из этих методов можно применить в моём случае и какие будут отличия? Заранее благодарен за совет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RN3DCX Опубликовано 25 июля, 2018 · Жалоба https://habr.com/post/170895/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 25 июля, 2018 · Жалоба Забей, гоняй всё через SSH, на худой конец через OpenVPN - просто, понятно и аудитов куча проведена. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 26 июля, 2018 · Жалоба В случае Mikrotik и публичных IP в датацентре и офисах делайте IPIP с IPSEC, https://wiki.mikrotik.com/wiki/Manual:Interface/IPIP . Работает "искаропки" без каких-либо танцев с бубном. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapydan Опубликовано 26 июля, 2018 · Жалоба а белые ip есть везде? 14 минут назад, jffulcrum сказал: делайте IPIP а что там планируется гонять, по этим туннелям? a gre over ipsec - это грубо говоря способ, который рекомендует делать циска - создание transform-set`а и crypto ipsec profil`а и применение его уже на туннель (чтобы не делать acl и crypto-map). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mystray Опубликовано 26 июля, 2018 · Жалоба 11 часов назад, r1sh сказал: ipsec over gre - шифруем пакет и посылаем через gre туннель gre over ipsec - хз зачем Одна из причин появления этих двух уродцев в том, что изначально IPSec на многих платформах был только policy-based, когда выбор шифровать или не шифровать трафик был только по каким-то параметрам пакета (ip/proto/port, в лучшем случае - interface), и не было простого и понятного route-based vpn. ipsec over gre или gre over ipsec как раз из таких целей: делается политика "шифровать ip proto GRE" (или "шифровать все на интерфейсе gre*" если платформа умеет), а все остальное (какой трафик куда толкать, динамическая маршрутизация, фаерволы) навешивалось уже на конкретные GRE-туннели понятным человеку образом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
r1sh Опубликовано 28 июля, 2018 · Жалоба В 26.07.2018 в 12:57, kapydan сказал: а белые ip есть везде? да, белые везде В 26.07.2018 в 12:57, kapydan сказал: а что там планируется гонять, по этим туннелям? RDP сессии, файлы по SMB протоколу перекидывать с шары на шару. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapydan Опубликовано 29 июля, 2018 · Жалоба ну тогда, просто делать туннели и поднимать маршрутизацмю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
r1sh Опубликовано 29 июля, 2018 · Жалоба 4 часа назад, kapydan сказал: ну тогда, просто делать туннели и поднимать маршрутизацмю. благодарю. Вот у меня возник затык. Есть три микротика: 1. первый офис белый IP 1.1.1.1 lan 192.168.1.0/24 IP tunnel 10.10.10.2/29 2. второй офис белый IP 2.2.2.2 lan 192.168.2.0/24 IP tunnel 10.10.10.3/29 3. VM на сервере белый ip 3.3.3.3 lan 192.168.10.0/24 IP tunnel 10.10.10.1/29 У каждого микротика белый IP. Сделал следующее: 1. Интерфейс IP tunnel на каждом роутере 2. Повесил IP адрес указанный выше на каждый роутер на этот интерфейс 3. Сделал правило nat 4. Сделал маршрут, gateway указывал внешний интерфейс(на микротике в VM на оба роутера) 5. Сделал proposal (на микротике в VM один на оба пира) 6. Сделал Peers на микротики в обоих офисах 7. Сделал IPsec policy (на микротике в VM один на оба пира) Посмотрел Remote Peers, SA - всё ок. Включил лог ipsec'а. Проблема следующая: в первый офис трафик ходит в обе стороны без проблем, во второй офис трафик не ходит. Packet Sniffer юзал, но на микротике во втором офисе не приходят пакеты icmp от сервера. В чем может быть проблема? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapydan Опубликовано 29 июля, 2018 · Жалоба Можно попробовать разные mtu или проверить маршрутизауию (статику или динамику). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 29 июля, 2018 · Жалоба 24 минуты назад, r1sh сказал: 3. Сделал правило nat Это зачем? Вам наоборот надо ИЗ NAT исключить все ваши внутренние сети. Да, и сеть туннелей - тоже. 25 минут назад, r1sh сказал: 4. Сделал маршрут, gateway указывал внешний интерфейс(на микротике в VM на оба роутера) Гейтвей на сеть филиала - адрес туннеля в филиале! Маршрутизация осуществляется ДО туннелирования, ДО NAT! 26 минут назад, r1sh сказал: 5. Сделал proposal (на микротике в VM один на оба пира) 6. Сделал Peers на микротики в обоих офисах 7. Сделал IPsec policy (на микротике в VM один на оба пира) В этих вещах легко налажать так, что потом легче разобрать и собрать заново. Ограничьтесь просто ключами IPSec в свойствах туннеля, пусть автоматика сделает дело сама. Сначала заработает, потом уже можно будет докручивать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 7 августа, 2018 · Жалоба В 26.07.2018 в 15:04, Mystray сказал: Одна из причин появления этих двух уродцев в том, что изначально IPSec на многих платформах был только policy-based, когда выбор шифровать или не шифровать трафик был только по каким-то параметрам пакета (ip/proto/port, в лучшем случае - interface), и не было простого и понятного route-based vpn. ipsec over gre или gre over ipsec как раз из таких целей: делается политика "шифровать ip proto GRE" (или "шифровать все на интерфейсе gre*" если платформа умеет), а все остальное (какой трафик куда толкать, динамическая маршрутизация, фаерволы) навешивалось уже на конкретные GRE-туннели понятным человеку образом. Хм, а вот циска совсем по другому объясняет это: Цитата GRE by itself does not provide any security for the data it transmits; however, a GRE packet can be sent over an IPsec VPN, causing the GRE packet (and therefore its contents) to be protected. Such a configuration is commonly used, because IPsec can only protect unicast IP packets. This limitation causes issues for routing protocols that use IP multicasts. Fortunately, a GRE tunnel can encapsulate IP multicast packets. The resulting GRE packet is an IP unicast packet, which can then be protected by an IPsec tunnel. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...