Перейти к содержимому
Калькуляторы

Запутался в туннелях, помогите разобраться.

Добрый день.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

делайте IPIP

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.