LINUX.ORG.RU
Форум — Admin  

IPSec туннель до сервера виртуальных машин

 , , ,


0

3

Суть такова.

Есть сервер контейнеров OpenVZ (Centos 6), все они имеют белые адреса и интерфейсы veth, выходят в интернет через bridge на хостовой машине. Есть желание поднять host-to-host IPSec туннель до сервера, таким образом, чтобы:

  • Туннель был только один до хостовой машины
  • Через него можно было связываться со всеми контенерами на хосте
  • Как следствие из предыдущего пункта, отсутствие необходимости в строить отдельный туннель до каждого контейнера

Возможно ли такое?

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

Пример конфига:

version 2.0

config setup
  protostack = netkey
  nat_traversal = off
  oe = off
  syslog = local5.info

conn hn3-office
  type = tunnel
  authby = secret
  ike = "aes-sha1;modp2048"
  phase2 = esp
  phase2alg = "aes-sha1;modp2048"
  auto = start
  left = x.x.x.x
  right = y.y.y.y
  leftsubnets = { z.z.z.z/32 }

Не уверен в правильности решения. 

iptables -t nat -A OUTPUT -d z.z.z.z -j DNAT --to-destination y.y.y.y

Disova ★
()

Самое простое - пробросить внутри IPSEC GRELAN туннель и сбриджевать GRE интерфейс на хосте с виртуалками с основным бриджом.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Прошу прощения, не сталкивался пока что с GRE, но из описания не очень понимаю чем он тут может помочь? Как я понимаю, для GRE нужно заводить отдельную подсеть, трафик которой будет «упаковываться» в GRE, отсюда нужно выдавать в контейнеры адреса из этой сети? Есть м.б. пример с решением похожей задачи.

trancefer ★★
() автор топика
Ответ на: комментарий от trancefer

GRE это просто инкапсуляция. В твоём случае GRE позволит передавать Ethernet пакеты через IPSEC туннель (который можно просто сделать в transport mode - host-to-host).

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

Либо, если твой сервер является шлюзом по умолчанию для виртуалок - ты можешь взять отдельную подсеть (хотя бы точка-точка) для GRE и контейнеры смогут к неё обращаться. Если сервер шлюзом не является, то тут уже нужно шаманить с маршрутами внутри контейнеров.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

Моя проблема в том, что на этих контейнерах запущен mysql к которым идет подключение по сети с одного хоста, соответственно в mysql заведен пользователь типа user@remote.example.com, соответсвенно необходимо опеспечить шифрование для передаваемых на mysql данных, при этом в идеале не вносить изменений в конфигурацию mysql (читай подключать SSL), и не заморачиваться с настройкой туннеля до каждого контейнера (что в принципе по объему работ мало отличается от перенастройки mysql). Плюс до кучи такие контейнеры раскиданы по нескольким серверам в нескольких дц. Исходя из этого, если бы все находилось в одном ДЦ — поднял GRE, на IP адрес удаленной стороны навесил в dns remote.example.com и получил бы что нужно — для mysql ничего не изменилось, но канал стал зашифрованным. В случае с несколькими ДЦ, необходимо поднимать еще несколько пар GRE-на-удаленной-стороне — GRE-в-бридже-на-сервере и везде будут свои адреса?

trancefer ★★
() автор топика
Ответ на: комментарий от trancefer

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

Угу

Если тебе нужен только MySQL, то проще всего поставить на хосте какой-нибудь простейший TCP Proxy (например, balance), который будет проксировать твои соединения извне в мускуль. А сам траффик до TCP Proxy уже закрыть сверху IPSEC-ом.

Либо вообще через SSH туннель это сделать, вообще никакого доп.софта не нужно.

blind_oracle ★★★★★
()

Не знаю какой трафик пойдёт с контейнера до удалённого хоста, но с удалённого хоста до контейнера трафик должен пойти в тунеле, если прописаны leftsubnets. Смотрите, что на удалённом хосте выдаёт команда: ″ip xfrm pol show″.

mky ★★★★★
()
Ответ на: комментарий от mky

Собрал на Virtualbox тестовый стенд из 3х ВМ:

10.2.2.4 - left - openvz server
10.2.2.100 - ve 100
10.2.2.101 - ve 101

10.3.3.4 - right - remote host

между ними с адресами 10.2.2.1 и 10.3.3.1 маршрутизатор

С вот таким конфигом: 

version 2.0

config setup
  protostack = netkey
  nat_traversal = off
  oe = off
  syslog = local5.info

conn hn3
  type = tunnel
  authby = secret
  ike = "aes-sha1;modp2048"
  phase2 = esp
  phase2alg = "aes-sha1;modp2048"
  auto = start
  left = 10.2.2.4
  right = 10.3.3.4
  rightsubnets = { 10.3.3.4/32 }
  leftsubnets = { 10.2.2.4/32 10.2.2.100/32 10.2.2.101/32 }

Получаю следующие результаты

  • Между right и left трафик ходит через туннель
  • ping до ve 100 работает в одну сторону, т.е. в туннель пакеты уходят, но назад ничего не возвращается:

На маршрутизаторе это выглядит так: 

17:18:59.602594 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x77d), length 132
17:19:00.602159 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x77e), length 132
17:19:01.602017 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x77f), length 132
17:19:02.602315 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x780), length 132

На left (сервере openvz) так (на время не обращайте внимания): 

19:23:43.427591 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x7b9), length 132
19:23:44.428184 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x7ba), length 132
19:23:45.428406 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0xb3204fda,seq=0x7bb), length 132

Внутри ve 100 все выглядит так: 

19:27:44.459537 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 59208, seq 242, length 64
19:27:45.459551 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 59208, seq 243, length 64
19:27:46.459547 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 59208, seq 244, length 64

Т.е. все выглядит так что пакеты долетают, но контейнер как-будто на них «не хочет» отвечать.

ip xfrm policy, на right: 

src 10.3.3.4/32 dst 10.2.2.4/32
        dir out priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16385 mode tunnel
src 10.3.3.4/32 dst 10.2.2.100/32
        dir out priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16389 mode tunnel
src 10.3.3.4/32 dst 10.2.2.101/32
        dir out priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16393 mode tunnel
src 10.2.2.101/32 dst 10.3.3.4/32
        dir fwd priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16393 mode tunnel
src 10.2.2.101/32 dst 10.3.3.4/32
        dir in priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16393 mode tunnel
src 10.2.2.100/32 dst 10.3.3.4/32
        dir fwd priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16389 mode tunnel
src 10.2.2.100/32 dst 10.3.3.4/32
        dir in priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16389 mode tunnel
src 10.2.2.4/32 dst 10.3.3.4/32
        dir fwd priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16385 mode tunnel
src 10.2.2.4/32 dst 10.3.3.4/32
        dir in priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main

на left: 

src 10.2.2.4/32 dst 10.3.3.4/32
        dir out priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16385 mode tunnel
src 10.2.2.100/32 dst 10.3.3.4/32
        dir out priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16389 mode tunnel
src 10.2.2.101/32 dst 10.3.3.4/32
        dir out priority 2080 ptype main
        tmpl src 10.2.2.4 dst 10.3.3.4
                proto esp reqid 16393 mode tunnel
src 10.3.3.4/32 dst 10.2.2.101/32
        dir fwd priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16393 mode tunnel
src 10.3.3.4/32 dst 10.2.2.101/32
        dir in priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16393 mode tunnel
src 10.3.3.4/32 dst 10.2.2.100/32
        dir fwd priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16389 mode tunnel
src 10.3.3.4/32 dst 10.2.2.100/32
        dir in priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16389 mode tunnel
src 10.3.3.4/32 dst 10.2.2.4/32
        dir fwd priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16385 mode tunnel
src 10.3.3.4/32 dst 10.2.2.4/32
        dir in priority 2080 ptype main
        tmpl src 10.3.3.4 dst 10.2.2.4
                proto esp reqid 16385 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main

В контейнере ничего не выводит (думаю что так и должно быть).

trancefer ★★
() автор топика
Ответ на: комментарий от trancefer

Да, в контенере, если на нём не поднимали ipsec, не должно быть политки ipsec (пустой вывод ip xfrm).

Политики выглядят странно, видимо из-за того, что rightsubnets и leftsubnets содержат в себе right и left ip-адреса.

Раз в контейнере есть icmp-пакеты, значит тунель как-то работает. Почему ответных пакетов нет непонятно. У клинета есть маршрут по умолчанию или просто маршрут к 10.3.3.4? Что происходит, когда клиент пингует 10.3.3.4?

И маршрут у виртуалок до 10.3.3.4 должен быть через 10.2.2.4, а не через 10.2.2.1.

mky ★★★★★
()
Ответ на: комментарий от mky

Сделал 10.2.2.4 gw для 10.2.2.100, при ping с 3.4 ничего не поменялось, в ve наблюдаю: 

06:24:18.510202 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 40568, seq 156, length 64
06:24:19.510247 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 40568, seq 157, length 64
06:24:20.510161 IP 10.3.3.4 > 10.2.2.100: ICMP echo request, id 40568, seq 158, length 64

Если пустить в обратную сторону с 10.2.2.100 до 3.4, на маршрутизаторе наблюдаю: 

06:28:45.744406 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x6), length 132
06:28:45.745016 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x14c), length 132
06:28:46.744752 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x7), length 132
06:28:46.745233 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x14d), length 132
Т.е. вроде как пакеты летят в обе стороны

На самом 3.4 получается такое: 

06:29:56.530847 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x4d), length 132
06:29:56.530909 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 28418, seq 77, length 64
06:29:56.530941 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x193), length 132
06:29:57.530741 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x4e), length 132
06:29:57.530814 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 28418, seq 78, length 64
06:29:57.530861 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x194), length 132
06:29:58.530674 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x4f), length 132
06:29:58.530723 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 28418, seq 79, length 64

На хосте openvz (2.4) картина такая: 

06:33:04.127313 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x115), length 132
06:33:04.128207 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x25b), length 132
06:33:04.278026 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x116), length 132
06:33:04.279078 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x25c), length 132
06:33:05.127030 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x117), length 132
06:33:05.127997 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x25d), length 132
06:33:05.278141 IP 10.2.2.4 > 10.3.3.4: ESP(spi=0x093d987e,seq=0x118), length 132
06:33:05.279021 IP 10.3.3.4 > 10.2.2.4: ESP(spi=0x9381c4e2,seq=0x25e), length 132
В ve тем не менее ответы не попадают, с ve есть ping до маршрутизатора 3.1 и 2.1 и до хоста 2.4

trancefer ★★
() автор топика
Ответ на: комментарий от trancefer

В ve тем не менее ответы не попадают

Точно не попадают? Смотрели с помощью tcpdump, запросы есть, а ответов не видно? Или просто ″ping″ не получает ответы.

Попробуйте найти концы icmp-пакетов, приходящих в вируталку 2.100 при пинге с 3.4 (логгирование марсианских пакетов, iptables -j TRACE).

И покажите вывод команд ″ip addr″ и ″ip route″ на хосте openvz (2.4).

mky ★★★★★
()
Ответ на: комментарий от mky

Забавно получается, tcpdump в ve показывает что ответы есть: 

11:20:47.023279 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 57602, seq 9, length 64
11:20:47.024101 IP 10.3.3.4 > 10.2.2.100: ICMP echo reply, id 57602, seq 9, length 64
11:20:47.251989 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 28930, seq 17289, length 64
11:20:47.253198 IP 10.3.3.4 > 10.2.2.100: ICMP echo reply, id 28930, seq 17289, length 64
11:20:47.378081 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 28674, seq 17297, length 64
11:20:47.379150 IP 10.3.3.4 > 10.2.2.100: ICMP echo reply, id 28674, seq 17297, length 64
11:20:48.023054 IP 10.2.2.100 > 10.3.3.4: ICMP echo request, id 57602, seq 10, length 64
11:20:48.024029 IP 10.3.3.4 > 10.2.2.100: ICMP echo reply, id 57602, seq 10, length 64
ping же говорит 
--- 10.3.3.4 ping statistics ---
146 packets transmitted, 0 received, 100% packet loss, time 145021ms

На 2.4 ip a, и ip r выглядят так: 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:9c:2e:d1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.111/24 brd 192.168.11.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:07:48:84 brd ff:ff:ff:ff:ff:ff
4: vzbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 08:00:27:07:48:84 brd ff:ff:ff:ff:ff:ff
    inet 10.2.2.4/24 brd 10.2.2.255 scope global vzbr0
5: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
6: veth101.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
8: veth100.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

10.2.2.0/24 dev vzbr0  proto kernel  scope link  src 10.2.2.4 
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.111 
10.3.3.0/24 via 10.2.2.1 dev vzbr0 
169.254.0.0/16 dev eth0  scope link  metric 1002 
169.254.0.0/16 dev vzbr0  scope link  metric 1004 
default via 192.168.11.251 dev eth0

trancefer ★★
() автор топика
Ответ на: комментарий от trancefer

Посмотрите в виртуалке rp_filter. Ну и log_martians попробуйте включить. Не уверен, что это поможет, но больше идей нет.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin