GRE + IPSec чтобы слушать multicast в облаке
Несмотря на обилие статей про IPsec на linux, каждый раз, когда мне нужно было слушать multicast на виртуальной машине в облаке (на примере AWS), который нужно было там получать через IPSec тоннель, я, сталкиваясь с какими-то проблемами в настройке, жалел, что не сделал никаких заметок в прошлый раз. В этот раз я решил записать пример конфигурации с небольшими пояснениями и поделиться им с общественностью, в надежде, что это кому-то может быть полезным.
Итак, обычно перед началом конфигурации вы должны договориться с другой стороной (в этой статье это будет условный DataCenter) о конфигурации IKE (фаза1) и IPSec (фаза2), в частности, согласовать PSK (pre-shared key) фразу, способы и алгоритмы аутентификации и шифрования, используется ли PFS (perfect forward secrecy), ваши публичные IP адреса (peer VPN gateway), ваши локальные подсети, которые вы связываете (interesting traffic), а также адресацию для GRE тоннеля. Обычно это делается совместным заполнением таблички, которую вы пересылаете по почте, в итоге собирается табличка такого вида:
Дальнейшая конфигурация будет производиться на AWS виртуальной машине с Ubuntu 20.04.3 LTS и Linux strongSwan U5.8.2/K5.13.0-1028-aws.
Для того, чтобы жестко закрепить только один профиль безопасности (аутентификации и шифрования) phase1 или phase2, стоит указать восклицательный знак ( ! ) после строки с заданной конфигурацией, например так:
ike=aes256-sha256-modp2048! # параметры аутентификации и шифрования IKE esp=aes256-sha256-modp2048! # параметры аутентификации и шифрования ESP
Для включения возможности маршрутизировать ipv4 трафик, необходимо включить:
Необходимо также настроить iptables, чтобы весь трафик (interesting traffic) к DataCenter Remote Address ( 100.15.30.0/24 ) выходил с source IP 10.45.8.17 и , как следствие, упаковывался в IPSec туннель службой strongswan:
iptables -t nat -A POSTROUTING -d 100.15.30.0/24 -j SNAT —to-source 10.45.8.17
Также, чтобы весь трафик к лупбэку GRE Tunnel source DataCenter ( 10.44.7.1 ) выходил с source IP 10.44.6.1 :
iptables -t nat -A POSTROUTING -d 10.44.7.1/32 -j SNAT —to-source 10.44.6.1
Для перезапуска strongswan используйте команду ipsec restart .
Теперь создадим GRE туннель c MTU 1476 и лупбэк:
ip tunnel add gre1 local 10.44.6.1 remote 10.44.7.1 mode gre ttl 255
ip link set gre1 up
ip addr add 10.44.4.6/30 dev gre1
ip link set dev gre1 mtu 1476
ip link set gre1 multicast on // должно быть по умолчанию включено, но пусть будет
ifconfig gre1 pointopoint 10.44.4.5
Для того, чтобы linux мог отвечать на GRE keepalive, нужно либо разрешить следующие параметры:
Либо воспользоваться более безопасным reply-only решением для ответа на GRE keepalive.
В результате, мы должны видеть на локальном сетевом интерфейсе приходящий пакет GRE keepalive от 10.44.7.1 к нашему адресу 10.44.6.1 , содержащий в себе инкапсулированный обратный пакет от 10.44.6.1 к 10.44.7.1 :
tcpdump -n -vv -i eth0 proto 47
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:53:20.976489 IP (tos 0xc0, ttl 255, id 38364, offset 0, flags [none], proto GRE (47), length 48)
10.44.7.1 > 10.44.6.1: GREv0, Flags [none], length 28
IP (tos 0xc0, ttl 255, id 34625, offset 0, flags [none], proto GRE (47), length 24)
10.44.6.1 > 10.44.7.1: GREv0, Flags [none], length 4
gre-proto-0x0
Также мы должны видеть деинкапсулированный исходящий пакет в дампе трафика на интерфейсе gre1:
tcpdump -i gre1 -n
13:01:30.985542 IP 10.44.6.1 > 10.44.7.1: GREv0, length 4: gre-proto-0x0
Кроме того, стоит проверить, что в разделе Security Associations вывода статуса демона strongswan счетчики входящего и исходящего трафика растут:
ipsec statusall — команда проверки статуса ipsec
Security Associations (2 up, 0 connecting):
dc-tun[2]: ESTABLISHED 2 hours ago, 10.1.1.246[222.45.67.1]. 177.54.214.20[177.54.214.20]
dc-tun[2]: IKEv2 SPIs: a62a46f88ff6e9c2_i* 50d27be1188d653d_r, pre-shared key reauthentication in 104 minutes
dc-tun[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
dc-tun-gre: INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c9788976_i 0e1488b7_o
dc-tun-gre: AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 13872 bytes_i (221 pkts, 8s ago), 3072 bytes_o (121 pkts, 10s ago), rekeying in 34 minutes
dc-tun-gre: 10.44.6.1/32 === 10.44.7.1/32
dc-tun-tcp: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cb28899e_i ace88e01_o
dc-tun-tcp: AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 16800 bytes_i (200 pkts, 30s ago), 16800 bytes_o (200 pkts, 30s ago), rekeying in 34 minutes
dc-tun-tcp: 10.45.8.17/28 === 100.15.30.0/24
В результате мы имеем рабочий GRE over IPSec тоннель по которому мы сможем получать multicast сообщения.
Для подписки на мультикаст с помощью PIM, я использовал python скрипт, в основу которого я взял скрипт из этого замечательного ответа на стаковерфлоу.
Для функции send_dummy_join(group, rp_addr, neighbor_ip) для этого примера:
group — это адрес мультикаст группы на которую вы хотите подписаться
rp_addr — адрес Multicast Rendezvous point 100.15.30.253 , данный нам стороной ДЦ
neighbor_ip — адрес соседа (пира) по GRE тоннелю 10.44.4.5
Для маршрутизации мультикаста можно использовать pimd, но его настройка уже не будет описана в этой статье.
Если вы хотите почитать на русском о PIM, то советую эту статью (Сети для самых маленьких. Часть 9.3. Мультикаст. Протокол PIM).
клин
Предыдущая статья:Используйте туннель GRE для прямого подключения двух частных сетей под LinuxНиже описано, как использовать туннель GRE между двумя независимыми частными сетями для прямого подключения двух разных частных сетей. Расширенное требование — зашифровать этот туннель. В противном случае злоумышленники могут перехватить много конфиденциальной информации на внешних линиях. Поэтому то, что будет обсуждаться в этой статье, является расширенной частью предыдущей:Зашифрованный туннель！
Why «GRE over IPSec»
Что касается зашифрованных туннелей, есть несколько решений:
Почему мы выбираемGRE over IPSecКакая?
и простоIPSec tunnelПо сравнению с преимуществами:
- Решение более гибкое, мы можем гибко направлять зашифрованный трафик в туннель GRE.
- IPSec не поддерживает многоадресную рассылку, поэтому невозможно работать с OSPF или другими протоколами маршрутизации.
с участиемIPSec over GREсоотношение:
- безопаснее. Весь трафик в общедоступной сети зашифрован, но извне неизвестно, работает ли протокол GRE.
Далее наш основной план — поговорить о:GRE over IPSec
окружение
| Объект | Замечания |
|---|---|
| NETA | Частная сеть 10.0.0.0/24, шлюз — GWA |
| NETB | Частная сеть на 10.0.1.0/24, шлюз GWB |
| NETC | Сеть, в которой узлы могут обмениваться данными, которую можно рассматривать как публичную сеть. |
| GWA | ip:10.0.0.1(NETA)、1.1.1.1(NETC)，CentOS6.x |
| GWB | ip:10.0.1.1(NETB)、2.2.2.2(NETC)，CentOS6.x |
| greB | Виртуальный сетевой интерфейс на GWA, имя туннеля GRE |
| greA | Виртуальный сетевой интерфейс на GWB, имя туннеля GRE |
| eth0 | Имя сетевого устройства GWA, подключенного к NETA, GWB, подключенного к NETB |
| eth1 | Имя сетевого устройства GWA и GWB, подключенного к NETC |
Конкретные шаги
Готов к работе
Выполнить на двух машинах, GWA и GWB:
yum -y install libreswan iptables; rm -rf /etc/ipsec.d/*db; # Удалить исходный файл db ipsec initnss; # Повторно инициализировать базу данных checonfig ipsec on; # Этот шаг также можно сделать позже Нормальное отверстие
Аналогичным образом выполните на GWB:
Таким образом, пробивка отверстий в основном завершена, и теперь вы можете найти две машины из сети NETA и NETB, и они должны иметь возможность общаться.
GRE over IPSEC
Настроить GWA
ipsec newhostkey \ --configdir /etc/ipsec.d \ --random /dev/urandom \ --output /etc/ipsec.d/GWA.secrets \ --verbose; # Вышеупомянутый параметр "--random / dev / urandom" намного эффективнее, чем параметр по умолчанию! ipsec showhostkey --left; # Обратите внимание на строку "leftrsasigkey =" в выводе # Это будет использоваться в файле /etc/ipsec.d/greB.conf этого компьютера (GWA) ipsec showhostkey --right; # Обратите внимание на строку "rightrsasigkey =" в выводе # Это будет использоваться в файле /etc/ipsec.d/greA.conf однорангового компьютера (GWB) vim /etc/ipsec.d/greB.conf # Создать файл конфигурации greB.conf conn greB type=transport left=10.0.0.1 leftrsasigkey=. leftprotoport=gre right=10.0.1.1 rightrsasigkey=. rightprotoport=gre authby=rsasig auto=start - GreB здесь взят случайно, просто потому что туннельное устройство на GWA называется greB, поэтому используется это имя
- leftrsasigkey = сверхуipsec showhostkey —leftкоманда
- rightrsasigkey = из команды, выполняемой на GWBipsec showhostkey —rightрезультат
Настроить GWB
Нарисуйте совок по тыкве и выполните на GWB:
ipsec newhostkey \ --configdir /etc/ipsec.d \ --random /dev/urandom \ --output /etc/ipsec.d/GWB.secrets \ --verbose; ipsec showhostkey --left; # Обратите внимание на строку "leftrsasigkey =" в выводе # Это будет использоваться в файле /etc/ipsec.d/greA.conf этого компьютера (GWB) ipsec showhostkey --right; # Обратите внимание на строку "rightrsasigkey =" в выводе # Это будет использоваться в файле /etc/ipsec.d/greB.conf однорангового компьютера (GWA) vim /etc/ipsec.d/greA.conf # Установить файл конфигурации grEA.conf, потому что имя туннельного устройства - grEA conn greA type=transport left=10.0.1.1 leftrsasigkey=. leftprotoport=gre right=10.0.0.1 rightrsasigkey=. rightprotoport=gre authby=rsasig auto=start - GreA здесь взяты случайно, просто потому что туннельное устройство на GWB называется greA, поэтому используется это имя.
- leftrsasigkey = сверхуipsec showhostkey —leftкоманда
- rightrsasigkey = Это из команды, выполняемой на GWAipsec showhostkey —rightрезультат
Iptables
Изначально на обычном этапе тестирования GRE на дырки есть настройки, связанные с iptables, и все они интегрированы в эту часть.
Выполнить на GWA и GWB соответственно:
iptables -A INPUT -i eth1 -p gre -j ACCEPT; iptables -A INPUT -i eth1 -p udp \ -m state --state NEW \ -m udp \ -m multiport --dports 50,51,500,4500 \ -j ACCEPT; iptables -A INPUT -i eth1 -p tcp \ -m state --state NEW \ -m tcp \ -m multiport --dports 50,51 \ -j ACCEPT; iptables -t mangle -A FORWARD \ -p tcp -m tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu; /etc/init.d/iptables save; # Сохранить правила iptables в файле конфигурации Начать обслуживание
Выполнить на машинах GWA и GWB соответственно:
/etc/init.d/ipsec start; ipsec auto --add greB; # Выполняется только на GWA ipsec auto --up greB; # Выполнять только на GWA ipsec auto --add greA; # Выполняется только на GWB ipsec auto --up greA; # Выполнять только на GWB chkconfig ipsec on; # Если вы не выполняли это предложение раньше, выполните его здесь, # После этого ipsec запустит случайную машину, # И больше не нужны ipsec auto --add и ipsec auto --up Простой тест
Чтобы проверить, успешна ли настройка, вы можете прослушать пакет на GWA и GWB соответственно:
tcpdump -nn -i eth1 host 1.1.1.1 and host 2.2.2.2; Вы обнаружите, что пакет зашифрован ESP.
Затем убейте шифрование ipsec для greB и greA на GWA и GWB соответственно
ipsec auto --delete greB; # Выполнять только на GWA ipsec auto --delete greA; # Выполнять только на GWB Затем повторите указанную выше команду пакета прослушивания:
tcpdump -nn -i eth1 host 1.1.1.1 and host 2.2.2.2; Вы обнаружите, что зашифрованный пакет исчез, его заменил пакет GRE, и вы, очевидно, можете увидеть содержимое пакета GRE.