[r1sh]

Добрый день.

 

Раньше я как-то настраивал ipsec туннели на cisco и vyos и не парился, а сейчас я прочитал про туннелирование:

 

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

 

Мне не до конца понятные прикладное применение этих туннелей, для каких случаев какие использовать?

 

Например у меня есть:

 

1. сервер в цоде, на нём стоит гипервизор и 5 виртуалок: RouterOS + 4 Win2012r2 сервера
2. два отдельных офиса, в каждом стоит Микротик

 

Нужно организовать доступ из подсети каждого офиса в подсеть серверов.

 

Какие из этих методов можно применить в моём случае и какие будут отличия?

 

Заранее благодарен за совет.

[RN3DCX]

https://habr.com/post/170895/

[Ivan_83]

Забей, гоняй всё через SSH, на худой конец через OpenVPN - просто, понятно и аудитов куча проведена.

[jffulcrum]

В случае Mikrotik и публичных IP в датацентре и офисах делайте IPIP с IPSEC, https://wiki.mikrotik.com/wiki/Manual:Interface/IPIP . Работает "искаропки" без каких-либо танцев с бубном.

[kapydan]

а белые ip есть везде?

 

14 минут назад, jffulcrum сказал:

делайте IPIP

а что там планируется гонять, по этим туннелям?

 

a gre over ipsec - это грубо говоря способ, который рекомендует делать циска - создание transform-set`а и crypto ipsec profil`а и применение его уже на туннель (чтобы не делать acl и crypto-map).

[Mystray]

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-туннели понятным человеку образом.

[r1sh]

В 26.07.2018 в 12:57, kapydan сказал:

а белые ip есть везде?

да, белые везде

 

В 26.07.2018 в 12:57, kapydan сказал:

а что там планируется гонять, по этим туннелям?

RDP сессии, файлы по SMB протоколу перекидывать с шары на шару.

[kapydan]

ну тогда, просто делать туннели и поднимать маршрутизацмю.

[r1sh]

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 от сервера.

 

В чем может быть проблема?

[kapydan]

Можно попробовать разные mtu или проверить маршрутизауию (статику или динамику).

[jffulcrum]

24 минуты назад, r1sh сказал:

3. Сделал правило nat

Это зачем? Вам наоборот надо ИЗ NAT исключить все ваши внутренние сети. Да, и сеть туннелей - тоже.

 

25 минут назад, r1sh сказал:

4. Сделал маршрут, gateway указывал внешний интерфейс(на микротике в VM на оба роутера)

Гейтвей на сеть филиала - адрес туннеля в филиале! Маршрутизация осуществляется ДО туннелирования, ДО NAT!

 

26 минут назад, r1sh сказал:

5. Сделал proposal (на микротике в VM один на оба пира)

6. Сделал Peers на микротики в обоих офисах

7. Сделал IPsec policy (на микротике в VM один на оба пира)

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

[xcme]

В 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.