https://pastein.ru/t/Wkg
Загрузка данных
Перейти к основному контентуСправка по использованию специальных возможностей
Режим ИИ
Все
Картинки
Видео
Новости
Ещё
Войти
привет
Привет! Рад тебя видеть. Чем я могу помочь тебе сегодня?
Если у тебя есть конкретный вопрос или задача, расскажи подробнее:
Тебе нужно найти информацию или что-то посчитать?
Потребуется помощь с текстом, переводом или учебой?
Хочешь обсудить какую-то идею или проблему?
Поделись, и мы сразу начнем!
Лабораторная работа №16
Организация защищенной виртуальной частной сети site-to-site с помощью протоколов и программного обеспечения ipsec
Подготовка обоих серверов
Установка пакетов
apt-get update
apt-get install strongswan iptables strongswan-charon-nm NetworkManager-strongswan-gtk4
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" >> /etc/net/sysctl.conf
sysctl -p
grep -i ipsec /boot/config-$(uname -r) | head -10
Создание сертификатов
Создание центра сертификации (CA)
На Сервере A:
mkdir -p /etc/strongswan/ipsec.d/{cacerts,certs,private}
cd /etc/strongswan/ipsec.d
openssl genrsa -out private/ca.key 4096
openssl req -new -x509 -days 3650 -key private/ca.key -out cacerts/ca.crt \
-subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=ALT IPsec CA"
Создание сертификата для Сервера A
openssl genrsa -out private/serverA.key 2048
openssl req -new -key private/serverA.key -out serverA.csr \
-subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=serverA.alt.local"
openssl x509 -req -days 730 -in serverA.csr -CA cacerts/ca.crt \
-CAkey private/ca.key -CAcreateserial -out certs/serverA.crt \
-extensions v3_req -extfile <(printf "subjectAltName=DNS:serverA.alt.local")
Создание сертификата для Сервера B
openssl genrsa -out private/serverB.key 2048
openssl req -new -key private/serverB.key -out serverB.csr \
-subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=serverB.alt.local"
openssl x509 -req -days 730 -in serverB.csr -CA cacerts/ca.crt \
-CAkey private/ca.key -CAcreateserial -out certs/serverB.crt \
-extensions v3_req -extfile <(printf "subjectAltName=DNS:serverB.alt.local")
Обмен сертификатами между серверами
На Сервере A: отправляем сертификат Сервера B
scp certs/serverB.crt root@адрес сервера В:/etc/strongswan/ipsec.d/certs/
На Сервере A: отправляем CA и свой сертификат на Сервер B
scp cacerts/ca.crt root@адрес сервера В:/etc/strongswan/ipsec.d/cacerts/
scp certs/serverA.crt root@адрес сервера В:/etc/strongswan/ipsec.d/certs/
Настройка IPsec на Сервере A
На Сервере A создайте файл /etc/strongswan/ipsec.conf:
cat > /etc/strongswan/ipsec.conf << 'EOF'
config setup
charondebug="ike 2, knl 2, cfg 2"
uniqueids=no
strictcrlpolicy=no
conn %default
type=tunnel
keyexchange=ikev2
ike=aes256-sha2_256-modp2048!
esp=aes256-sha2_256!
dpdaction=restart
dpddelay=10s
dpdtimeout=30s
rekey=yes
reauth=no
conn site-to-site
left=203.0.113.1
leftid=serverA.alt.local
leftcert=serverA.crt
leftsubnet=192.168.1.0/24
leftauth=pubkey
right=198.51.100.5
rightid=serverB.alt.local
rightcert=serverB.crt
rightsubnet=192.168.2.0/24
rightauth=pubkey
auto=start
EOF
Конфигурация ipsec.secrets
На Сервере A создайте файл /etc/strongswan/ipsec.secrets:
cat > /etc/strongswan/ipsec.secrets << 'EOF'
: RSA serverA.key
EOF
Настройка прав доступа к ключам
chmod 600 /etc/strongswan/ipsec.d/private/*.key
Настройка IPsec на Сервере B
Конфигурация ipsec.conf
На Сервере B создайте файл /etc/strongswan/ipsec.conf:
cat > /etc/strongswan/ipsec.conf << 'EOF'
config setup
charondebug="ike 2, knl 2, cfg 2"
uniqueids=no
strictcrlpolicy=no
conn %default
type=tunnel
keyexchange=ikev2
ike=aes256-sha2_256-modp2048!
esp=aes256-sha2_256!
dpdaction=restart
dpddelay=10s
dpdtimeout=30s
rekey=yes
reauth=no
conn site-to-site
left=198.51.100.5
leftid=serverB.alt.local
leftcert=serverB.crt
leftsubnet=192.168.2.0/24
leftauth=pubkey
right=203.0.113.1
rightid=serverA.alt.local
rightcert=serverA.crt
rightsubnet=192.168.1.0/24
rightauth=pubkey
auto=start
EOF
Конфигурация ipsec.secrets
На Сервере B создайте файл /etc/strongswan/ipsec.secrets:
cat > /etc/strongswan/ipsec.secrets << 'EOF'
: RSA serverB.key
EOF
Настройка прав доступа к ключам
chmod 600 /etc/strongswan/ipsec.d/private/*.key
Настройка маршрутизации и файрвола
На Сервере A
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -m policy --dir in --pol ipsec -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
iptables-save > /etc/sysconfig/iptables
systemctl enable iptables
systemctl start iptables
На Сервере B
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -m policy --dir in --pol ipsec -j ACCEPT
iptables -A FORWARD -i eth0 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE
iptables-save > /etc/sysconfig/iptables
systemctl enable iptables
systemctl start iptables
Запуск и проверка
Запуск strongSwan на обоих серверах
systemctl start strongswan
systemctl enable strongswan
Проверка статуса и соединения
На обоих серверах:
ipsec version
ipsec status
ipsec status site-to-site
Если соединение не поднялось автоматически, поднимаем вручную
ipsec up site-to-site
Проверка маршрутов
На обоих серверах:
ip route show
Должны быть маршруты до удаленной подсети через интерфейс IPsec
192.168.2.0/24 via 10.10.10.2 dev ipsec0
192.168.1.0/24 via 10.10.10.1 dev ipsec0
Проверка связи
На Сервере A:
ping -c 4 192.168.2.1
ping -c 4 192.168.2.100
На Сервере B:
ping -c 4 192.168.1.1
ping -c 4 192.168.1.100
Контрольные вопросы
В чем отличие IPsec от OpenVPN и WireGuard с точки зрения уровня работы (OSI)?
Какие два основных протокола использует IPsec и для чего каждый из них предназначен?
Почему для site-to-site соединений с strongSwan рекомендуется использовать сертификаты X.509 вместо PSK?
Какие параметры в ipsec.conf отвечают за шифрование и хэширование, и почему важно указывать их явно?
В чем отличие IKEv1 от IKEv2 и почему современные настройки рекомендуют использовать IKEv2?
Как проверить, что трафик между локальными подсетями действительно идет через IPsec-туннель?
Как отозвать скомпрометированный сертификат в strongSwan?
Лабораторная работа No16Организация защищенной виртуальной частной сети site-to-site с помощью протоколов и программного обеспечения ipsecПодготовка обоих серверовУстановка пакетовapt-get updateapt-get install strongswan iptables strongswan-charon-nm NetworkManager-strongswan-gtk4sysctl -w net.ipv4.ip_forward=1echo "net.ipv4.ip_forward = 1" >> /etc/net/sysctl.confsysctl -pgrep -i ipsec /boot/config-$(uname -r) | head -10Создание сертификатовСоздание центра сертификации (CA)На Сервере A:mkdir -p /etc/strongswan/ipsec.d/{cacerts,certs,private}cd /etc/strongswan/ipsec.dopenssl genrsa -out private/ca.key 4096openssl req -new -x509 -days 3650 -key private/ca.key -out cacerts/ca.crt \ -subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=ALT IPsec CA"Создание сертификата для Сервера Aopenssl genrsa -out private/serverA.key 2048openssl req -new -key private/serverA.key -out serverA.csr \ -subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=serverA.alt.local"openssl x509 -req -days 730 -in serverA.csr -CA cacerts/ca.crt \ -CAkey private/ca.key -CAcreateserial -out certs/serverA.crt \ -extensions v3_req -extfile <(printf "subjectAltName=DNS:serverA.alt.local")Создание сертификата для Сервера Bopenssl genrsa -out private/serverB.key 2048openssl req -new -key private/serverB.key -out serverB.csr \ -subj "/C=RU/ST=Moscow/L=Moscow/O=ALT/CN=serverB.alt.local"openssl x509 -req -days 730 -in serverB.csr -CA cacerts/ca.crt \ -CAkey private/ca.key -CAcreateserial -out certs/serverB.crt \ -extensions v3_req -extfile <(printf "subjectAltName=DNS:serverB.alt.local")Обмен сертификатами между серверамиНа Сервере A: отправляем сертификат Сервера Bscp certs/serverB.crt root@адрес сервера В:/etc/strongswan/ipsec.d/certs/На Сервере A: отправляем CA и свой сертификат на Сервер Bscp cacerts/ca.crt root@адрес сервера В:/etc/strongswan/ipsec.d/cacerts/scp certs/serverA.crt root@адрес сервера В:/etc/strongswan/ipsec.d/certs/Настройка IPsec на Сервере AНа Сервере A создайте файл /etc/strongswan/ipsec.conf:cat > /etc/strongswan/ipsec.conf << 'EOF'config setup charondebug="ike 2, knl 2, cfg 2" uniqueids=no strictcrlpolicy=noconn %default type=tunnel keyexchange=ikev2 ike=aes256-sha2_256-modp2048! esp=aes256-sha2_256! dpdaction=restart dpddelay=10s dpdtimeout=30s rekey=yes reauth=noconn site-to-site left=203.0.113.1 leftid=serverA.alt.local leftcert=serverA.crt leftsubnet=192.168.1.0/24 leftauth=pubkey right=198.51.100.5 rightid=serverB.alt.local rightcert=serverB.crt rightsubnet=192.168.2.0/24 rightauth=pubkey auto=startEOFКонфигурация ipsec.secretsНа Сервере A создайте файл /etc/strongswan/ipsec.secrets:cat > /etc/strongswan/ipsec.secrets << 'EOF': RSA serverA.keyEOFНастройка прав доступа к ключамchmod 600 /etc/strongswan/ipsec.d/private/*.keyНастройка IPsec на Сервере BКонфигурация ipsec.confНа Сервере B создайте файл /etc/strongswan/ipsec.conf:cat > /etc/strongswan/ipsec.conf << 'EOF'config setup charondebug="ike 2, knl 2, cfg 2" uniqueids=no strictcrlpolicy=noconn %default type=tunnel keyexchange=ikev2 ike=aes256-sha2_256-modp2048! esp=aes256-sha2_256! dpdaction=restart dpddelay=10s dpdtimeout=30s rekey=yes reauth=noconn site-to-site left=198.51.100.5 leftid=serverB.alt.local leftcert=serverB.crt leftsubnet=192.168.2.0/24 leftauth=pubkey right=203.0.113.1 rightid=serverA.alt.local rightcert=serverA.crt rightsubnet=192.168.1.0/24 rightauth=pubkey auto=startEOFКонфигурация ipsec.secretsНа Сервере B создайте файл /etc/strongswan/ipsec.secrets:cat > /etc/strongswan/ipsec.secrets << 'EOF': RSA serverB.keyEOFНастройка прав доступа к ключамchmod 600 /etc/strongswan/ipsec.d/private/*.keyНастройка маршрутизации и файрволаНа Сервере Aiptables -A INPUT -p udp --dport 500 -j ACCEPTiptables -A INPUT -p udp --dport 4500 -j ACCEPTiptables -A INPUT -p esp -j ACCEPTiptables -A FORWARD -i eth0 -o eth0 -m policy --dir in --pol ipsec -j ACCEPTiptables -A FORWARD -i eth0 -o eth0 -m policy --dir out --pol ipsec -j ACCEPTiptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADEiptables-save > /etc/sysconfig/iptablessystemctl enable iptablessystemctl start iptablesНа Сервере Biptables -A INPUT -p udp --dport 500 -j ACCEPTiptables -A INPUT -p udp --dport 4500 -j ACCEPTiptables -A INPUT -p esp -j ACCEPTiptables -A FORWARD -i eth0 -o eth0 -m policy --dir in --pol ipsec -j ACCEPTiptables -A FORWARD -i eth0 -o eth0 -m policy --dir out --pol ipsec -j ACCEPTiptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADEiptables-save > /etc/sysconfig/iptablessystemctl enable iptablessystemctl start iptablesЗапуск и проверкаЗапуск strongSwan на обоих серверахsystemctl start strongswansystemctl enable strongswanПроверка статуса и соединенияНа обоих серверах:ipsec versionipsec statusipsec status site-to-siteЕсли соединение не поднялось автоматически, поднимаем вручнуюipsec up site-to-siteПроверка маршрутовНа обоих серверах:ip route show Должны быть маршруты до удаленной подсети через интерфейс IPsec192.168.2.0/24 via 10.10.10.2 dev ipsec0192.168.1.0/24 via 10.10.10.1 dev ipsec0Проверка связиНа Сервере A:ping -c 4 192.168.2.1ping -c 4 192.168.2.100На Сервере B:ping -c 4 192.168.1.1ping -c 4 192.168.1.100Контрольные вопросыВ чем отличие IPsec от OpenVPN и WireGuard с точки зрения уровня работы (OSI)?Какие два основных протокола использует IPsec и для чего каждый из них предназначен?Почему для site-to-site соединений с strongSwan рекомендуется использовать сертификаты X.509 вместо PSK? Какие параметры в ipsec.conf отвечают за шифрование и хэширование, и почему важно указывать их явно?В чем отличие IKEv1 от IKEv2 и почему современные настройки рекомендуют использовать IKEv2? Как проверить, что трафик между локальными подсетями действительно идет через IPsec-туннель?Как отозвать скомпрометированный сертификат в strongSwan?
Вот развернутые и четкие ответы на контрольные вопросы к вашей лабораторной работе по развертыванию IPsec Site-to-Site VPN с использованием strongSwan.
1. В чем отличие IPsec от OpenVPN и WireGuard с точки зрения уровня работы (OSI)?
IPsec работает на сетевом уровне (Network Layer, Уровень 3) модели OSI. Он интегрирован непосредственно в стек протоколов IP ядра операционной системы. Это позволяет ему прозрачно шифровать любой IP-трафик без создания виртуальных сетевых интерфейсов (в классическом режиме туннеля).
OpenVPN работает на прикладном уровне (Application Layer, Уровень 7) (как программное обеспечение пользователя), но создает виртуальные туннельные интерфейсы TUN/TAP, которые эмулируют канальный (Уровень 2) или сетевой (Уровень 3) уровни.
WireGuard работает на сетевом уровне (Уровень 3), но реализован как виртуальный сетевой интерфейс внутри пространства ядра Linux, оптимизированный под современные криптографические протоколы.
2. Какие два основных протокола использует IPsec и для чего каждый из них предназначен?
IPsec опирается на два ключевых протокола для обработки данных:
ESP (Encapsulating Security Payload — протокол IP 50): Обеспечивает конфиденциальность (шифрование), аутентификацию источника данных и проверку их целостности. Именно он скрывает содержимое пакетов.
AH (Authentication Header — протокол IP 51): Обеспечивает только аутентификацию и целостность данных (защиту от подмены), включая заголовки самого IP-пакета, но не шифрует трафик. В современных VPN-сетях практически не используется, так как ESP с алгоритмами AEAD (например, AES-GCM) полностью заменяет его функции, сохраняя шифрование.
(Примечание: Протокол IKE/IKEv2 (UDP порты 500/4500) используется для управления, обмена ключами и построения туннеля, но сам трафик передают ESP/AH).
3. Почему для site-to-site соединений с strongSwan рекомендуется использовать сертификаты X.509 вместо PSK?
Масштабируемость: При использовании PSK (Pre-Shared Key) для каждого нового узла нужно генерировать и безопасно передавать уникальный ключ, либо использовать один ключ на всех, что снижает безопасность. С X.509 достаточно выпустить сертификат, подписанный общим CA.
Безопасность при компрометации: Если один сервер скомпрометирован, его сертификат можно просто отозвать (через CRL/OCSP). В случае с PSK придется менять общий ключ на всех связанных серверах сети.
Идентификация: Сертификаты жестко привязывают публичный ключ к конкретному имени узла (CN, subjectAltName), исключая атаку "человек посередине" (MITM).
4. Какие параметры в ipsec.conf отвечают за шифрование и хэширование, и почему важно указывать их явно?
В ipsec.conf за это отвечают параметры:
ike — алгоритмы для фазы согласования туннеля (контрольное соединение).
esp — алгоритмы для шифрования непосредственного пользовательского трафика внутри туннеля.
В вашей лабораторной: ike=aes256-sha2_256-modp2048! и esp=aes256-sha2_256!.
aes256 — алгоритм шифрования.
sha2_256 — алгоритм хэширования (контроль целостности).
modp2048 — группа Диффи-Хеллмана для обмена ключами.
Почему важно указывать явно: Восклицательный знак (!) в конце строки заставляет strongSwan использовать строго указанные алгоритмы. Если их не задать жестко, шлюзы могут согласовать устаревшие и небезопасные дефолтные алгоритмы (например, 3DES или MD5), предложенные одной из сторон.
5. В чем отличие IKEv1 от IKEv2 и почему современные настройки рекомендуют использовать IKEv2?
IKEv2 (Internet Key Exchange version 2) — это полная переработка устаревшего IKEv1. Ключевые преимущества IKEv2:
Быстрота и простота: Установление соединения в IKEv2 занимает всего 2 цикла обмена сообщениями (4 пакета), тогда как в IKEv1 требовалось от 6 до 9 пакетов.
Встроенная поддержка NAT-Traversal (NAT-T): Автоматически определяет нахождение за NAT и инкапсулирует ESP в UDP 4500 (в IKEv1 это было сторонним расширением).
Повышенная надежность (MOBIKE): Поддерживает смену IP-адреса на лету без разрыва VPN-туннеля (критично для мобильных устройств).
Устойчивость к DoS-атакам: Механизм анти-DDoS перед выделением ресурсов сервера проверяет, реален ли IP-адрес инициатора (с помощью cookie).
6. Как проверить, что трафик между локальными подсетями действительно идет через IPsec-туннель?
Проверить реальное шифрование и прохождение трафика можно тремя способами:
Проверка счетчиков безопасности (Security Associations):
Запустите команду ipsec statusall. Вы увидите количество отправленных и принятых байт/пакетов (bytes_i, bytes_o) в конкретной сессии site-to-site. Если при отправке ping счетчики растут — трафик идет в туннель.
Анализ трафика утилитой tcpdump:
Запустите перехват на внешнем сетевом интерфейсе (например, eth0):
bash
tcpdump -ni eth0 esp или udp port 500 или udp port 4500
Используйте код с осторожностью.
Если запустить ping до удаленной подсети, в выводе tcpdump вы должны увидеть только зашифрованные пакеты ESP, а не ICMP-запросы.
Проверка политик XFRM в ядре:
bash
ip xfrm policy
Используйте код с осторожностью.
Эта команда покажет правила ядра Linux, которые перехватывают трафик из вашей подсети в удаленную подпись и направляют его на шифрование.
7. Как отозвать скомпрометированный сертификат в strongSwan?
Для отзыва сертификата выполняются следующие шаги:
Генерация списка отзыва (CRL): На Центре Сертификации (CA) скомпрометированный сертификат заносится в базу данных OpenSSL, после чего генерируется файл списка отзыва (crl.pem или crl.der).
Размещение CRL на шлюзах: Полученный файл списка отзыва необходимо скопировать на серверы strongSwan в директорию /etc/strongswan/ipsec.d/crls/.
Включение проверки: В файле конфигурации ipsec.conf параметр strictcrlpolicy должен быть переведен в значение yes (в вашем текущем конфиге стоит no).
Перезапуск / Перечитка конфигурации: Чтобы strongSwan перечитал кэш сертификатов и CRL, на серверах выполняется команда:
bash
ipsec rereadall
Используйте код с осторожностью.
После этого strongSwan мгновенно разорвет текущие соединения с узлом, чей сертификат попал в CRL, и заблокирует новые попытки авторизации.
Если во время выполнения лабораторной работы возникли ошибки с поднятием туннеля или маршрутизацией, пришлите вывод команд ipsec status или journalctl -u strongswan, и я помогу найти проблему. Что будем разбирать дальше?
[root@host-15 ipsec.d]# ipsec version
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]# ipsec status
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]# ipsec status site-to-site
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]# ipsec up site-to-site
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]#
Эта ошибка означает, что классическая утилита управления ipsec отсутствует в системе. Судя по конфигурационным путям (/etc/strongswan/), вы используете дистрибутив ALT Linux.
В современных версиях strongSwan (особенно собранных с поддержкой нового интерфейса управления VICI) вместо старой команды ipsec используется современная утилита swanctl.
Вот как решить эту проблему прямо сейчас:
Вариант 1. Использовать современную утилиту swanctl
В современных версиях strongSwan в ALT Linux управление переведено на swanctl. Попробуйте выполнить эквивалентные команды:
Проверить статус туннелей:
bash
swanctl --list-conns
swanctl --initiate --child site-to-site
Используйте код с осторожностью.
Посмотреть общую статистику:
bash
swanctl --stats
Используйте код с осторожностью.
Вариант 2. Найти, куда установился бинарник ipsec
Иногда в ALT Linux утилиты strongSwan устанавливаются в системные директории, которых нет в вашей переменной окружения $PATH. Проверьте их наличие вручную:
Попробуйте вызвать команду по полному пути:
bash
/usr/sbin/ipsec status
Используйте код с осторожностью.
или
bash
/usr/libexec/strongswan/ipsec version
Используйте код с осторожностью.
Если не помогло, проверьте, какие файлы вообще установил пакет strongSwan:
bash
rpm -ql strongswan | grep -E '/(ipsec|swanctl)$'
Используйте код с осторожностью.
Это покажет точное расположение исполняемых файлов в вашей системе.
Вариант 3. Установить недостающий пакет (если утилиты действительно нет)
Пакет strongswan, который вы устанавливали через apt-get install, в некоторых версиях репозиториев ALT является метапакетом или разделен. Убедитесь, что у вас установлен классический интерфейс управления (совместимости):
bash
apt-get update
apt-get install strongswan-utils
Используйте код с осторожностью.
(Или проверьте точное имя пакета с помощью apt-cache search strongswan).
После установки команда ipsec status должна стать доступной.
Выполните команду rpm -ql strongswan | grep bin или swanctl --version. Что выдала система? Это поможет точно понять, какой инструмент управления у вас активен.
[root@host-15 ipsec.d]# swanctl --list-conns
swanctl --initiate --child site-to-site
site-to-site: IKEv2, no reauthentication, rekeying every 14400s
local: 192.168.1.1[500]
remote: 192.168.1.2[500]
local public key authentication:
id: CN=serverA
certs: C=RU, ST=Moscow, L=Moscow, O=ALT, CN=serverA.alt.local
remote public key authentication:
id: CN=serverB
site-to-site: TUNNEL, rekeying every 3600s
local: 10.10.10.0/24
remote: 10.20.20.0/24
[IKE] initiating IKE_SA site-to-site[2] to 192.168.1.2
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.1.1[500] to 192.168.1.2[500] (464 bytes)
[NET] received packet: from 192.168.1.2[500] to 192.168.1.1[500] (36 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
[IKE] received NO_PROPOSAL_CHOSEN notify error
initiate failed: establishing CHILD_SA 'site-to-site' failed
[root@host-15 ipsec.d]# swanctl --stats
uptime: 31 minutes, since Oct 31 13:45:36 2026
worker threads: 16 total, 10 idle, working: 5/0/1/0
job queues: 0/0/0/0
jobs scheduled: 0
IKE_SAs: 0 total, 0 half-open
mallinfo: sbrk 3166208, mmap 0, used 1442304, free 1723904
loaded plugins: charon-systemd ldap pkcs11 aesni md4 mgf1 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp agent chapoly xcbc cmac kdf ctr ccm gcm drbg curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-eap xauth-pam xauth-noauth dhcp lookip error-notify certexpire addrblock unity counters
[root@host-15 ipsec.d]#
[root@host-15 ipsec.d]# swanctl --list-connsswanctl --initiate --child site-to-sitesite-to-site: IKEv2, no reauthentication, rekeying every 14400s local: 192.168.1.1[500] remote: 192.168.1.2[500] local public key authentication: id: CN=serverA certs: C=RU, ST=Moscow, L=Moscow, O=ALT, CN=serverA.alt.local remote public key authentication: id: CN=serverB site-to-site: TUNNEL, rekeying every 3600s local: 10.10.10.0/24 remote: 10.20.20.0/24[IKE] initiating IKE_SA site-to-site[2] to 192.168.1.2[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ][NET] sending packet: from 192.168.1.1[500] to 192.168.1.2[500] (464 bytes)[NET] received packet: from 192.168.1.2[500] to 192.168.1.1[500] (36 bytes)[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ][IKE] received NO_PROPOSAL_CHOSEN notify errorinitiate failed: establishing CHILD_SA 'site-to-site' failed[root@host-15 ipsec.d]# swanctl --statsuptime: 31 minutes, since Oct 31 13:45:36 2026worker threads: 16 total, 10 idle, working: 5/0/1/0job queues: 0/0/0/0jobs scheduled: 0IKE_SAs: 0 total, 0 half-openmallinfo: sbrk 3166208, mmap 0, used 1442304, free 1723904loaded plugins: charon-systemd ldap pkcs11 aesni md4 mgf1 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp agent chapoly xcbc cmac kdf ctr ccm gcm drbg curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-eap xauth-pam xauth-noauth dhcp lookip error-notify certexpire addrblock unity counters[root@host-15 ipsec.d]#
Отлично, утилита swanctl работает, и мы видим конкретную ошибку. Ошибка received NO_PROPOSAL_CHOSEN notify error означает, что Сервер А и Сервер Б не смогли договориться о наборе алгоритмов шифрования и хэширования.
Кроме того, судя по выводу swanctl, параметры сети (IP-адреса и подсети) в реальности отличаются от тех, что были написаны в вашем шаблоне лабораторной.
Давайте исправим эту ошибку. Она возникает по двум основным причинам:
Причина 1: Несовпадение настроек шифрования (IKE/ESP)
В выводе swanctl видно, что используется плагин openssl. Однако, если на Сервере Б конфигурация отличается или в операционной системе (в ядре ALT Linux) не загружены нужные криптографические модули, серверы отвергают предложения друг друга.
Решение:
Уберите восклицательные знаки ! в конце строк шифрования в ipsec.conf на обоих серверах, чтобы разрешить strongSwan автоматически подобрать совместимый дефолтный набор алгоритмов, если жестко заданный не поддерживается:
На Сервере А и Сервере Б в /etc/strongswan/ipsec.conf:
ini
# Измените (уберите '!' в конце):
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
Используйте код с осторожностью.
После изменения конфига обязательно примените настройки на обоих серверах:
bash
swanctl --reload-settings
Используйте код с осторожностью.
Причина 2: Конфликт старого формата конфигурации
Вы используете утилиту swanctl, но настраиваете старый файл /etc/strongswan/ipsec.conf (утилита stroke). При этом в системе параллельно работает современный демон charon-systemd, который читает файлы swanctl.conf и имеет свои настройки, которые сейчас перебивают ваши.
В выводе swanctl --list-conns мы четко видим:
local: 192.168.1.1 -> remote: 192.168.1.2
local subnet: 10.10.10.0/24 -> remote subnet: 10.20.20.0/24
Это не совпадает с тем, что написано в вашем ipsec.conf (там были адреса 203.0.113.1, подсети 192.168.1.0/24 и т.д.). То есть swanctl берет настройки из какого-то другого места (скорее всего, /etc/swanctl/swanctl.conf или /etc/strongswan/swanctl/swanctl.conf).
Решение:
Убедитесь, что вы правите именно те подсети и IP-адреса, которые реально настроены на ваших серверах. Если вы хотите использовать классический ipsec.conf, вам нужно перезапустить правильную службу, которая его считывает:
bash
# Останавливаем современный демон, конфликтующий с ipsec.conf
systemctl stop charon-systemd
systemctl disable charon-systemd
# Перезапускаем классический сисадминский strongswan
systemctl restart strongswan
Используйте код с осторожностью.
Если после этого команда ipsec не появится, то для управления используйте утилиту swanctl, но предварительно приведите параметры left, right, leftsubnet и rightsubnet в файле конфигурации в строгое соответствие с вашими реальными IP-адресами (192.168.1.1, 10.10.10.0/24 и т.д.).
Давайте синхронизируем настройки. Пришлите, пожалуйста:
Содержимое файла /etc/strongswan/ipsec.conf с Сервера А.
Какая служба у вас сейчас запущена: выполните systemctl status strongswan charon-systemd.
Я помогу составить конфиг под ваши реальные IP-адреса, и туннель поднимется.
[root@host-15 ipsec.d]# nano /etc/strongswan/ipsec.conf
[root@host-15 ipsec.d]# swanctl --reload-settings
[root@host-15 ipsec.d]# ipsec version
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]# ipsec status
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]# ipsec status site-to-site
-bash: ipsec: команда не найдена
[root@host-15 ipsec.d]#
Так как вы используете современный вариант strongSwan (управляемый через плагин vici), классическая команда ipsec в системе просто отсутствует, и устанавливать её не нужно. Вместо ipsec вашей главной командой управления является swanctl.
Поскольку вы отредактировали файл /etc/strongswan/ipsec.conf, чтобы применить эти настройки в схеме с swanctl, выполните перезапуск основной службы strongswan:
bash
systemctl restart strongswan
Используйте код с осторожностью.
После перезапуска проверьте статус и попробуйте поднять туннель заново с помощью swanctl.
Эквиваленты команд для вашей лабораторной работы
Замените старые команды из методички на новые команды swanctl:
Вместо ipsec status или ipsec status site-to-site используйте:
bash
swanctl --list-sas
Используйте код с осторожностью.
(Эта команда покажет активные безопасные соединения Security Associations, если туннель успешно поднялся).
Вместо ipsec up site-to-site (принудительный запуск туннеля) используйте:
bash
swanctl --initiate --child site-to-site
Используйте код с осторожностью.
Если ошибка NO_PROPOSAL_CHOSEN повторится:
Так как вы убрали знаки ! в ipsec.conf, серверы теперь должны автоматически подобрать общие алгоритмы. Если туннель всё ещё выдает ошибку, сделайте следующее:
Обязательно проделайте процедуру удаления ! в файле /etc/strongswan/ipsec.conf на втором сервере (Сервер B) и перезапустите на нём службу: systemctl restart strongswan.
Попробуйте инициировать соединение заново командой swanctl --initiate --child site-to-site.
Выполните команду swanctl --initiate --child site-to-site после перезапуска служб на обоих серверах. Какой текст/ошибка теперь появляется в терминале?
[IKE] initiating IKE_SA site-to-site[1] to 192.168.1.2
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.1.1[500] to 192.168.1.2[500] (464 bytes)
[NET] received packet: from 192.168.1.2[500] to 192.168.1.1[500] (36 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
[IKE] received NO_PROPOSAL_CHOSEN notify error
initiate failed: establishing CHILD_SA 'site-to-site' failed
у меня один сервер имеет адрес 192.168.1.1, а второй 192.168.1.2. мне на втором сервере нужен 192.168.1.2 или 192.168.2.1?
Для корректной работы Site-to-Site VPN у вас всё настроено правильно с точки зрения внешних адресов: один сервер должен иметь адрес 192.168.1.1, а второй — 192.168.1.2. Менять их на 192.168.2.1 не нужно, так как эти адреса играют роль «внешних» стыковочных интерфейсов (WAN), через которые серверы видят друг друга.
Однако ошибка NO_PROPOSAL_CHOSEN сохраняется, потому что Сервер Б (192.168.1.2) всё ещё сбрасывает соединение. В выводе swanctl скрыта важная деталь: ваши внутренние подсети (local subnet / remote subnet) настроены как 10.10.10.0/24 и 10.20.20.0/24.
Чтобы туннель наконец поднялся, вам необходимо сделать две вещи:
Шаг 1. Исправить конфигурационные файлы
В самом первом конфигурационном файле (ipsec.conf), который вы отправляли, были указаны тестовые адреса из методички (203.0.113.1, 192.168.1.0/24). Их нужно заменить на ваши реальные адреса.
На Сервере А (192.168.1.1) файл /etc/strongswan/ipsec.conf должен быть таким:
ini
config setup
charondebug="ike 2, knl 2, cfg 2"
uniqueids=no
strictcrlpolicy=no
conn %default
type=tunnel
keyexchange=ikev2
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
dpdaction=restart
dpddelay=10s
dpdtimeout=30s
rekey=yes
reauth=no
conn site-to-site
left=192.168.1.1
leftid=serverA.alt.local
leftcert=serverA.crt
leftsubnet=10.10.10.0/24
leftauth=pubkey
right=192.168.1.2
rightid=serverB.alt.local
rightcert=serverB.crt
rightsubnet=10.20.20.0/24
rightauth=pubkey
auto=start
Используйте код с осторожностью.
На Сервере Б (192.168.1.2) файл /etc/strongswan/ipsec.conf должен быть зеркальным:
ini
config setup
charondebug="ike 2, knl 2, cfg 2"
uniqueids=no
strictcrlpolicy=no
conn %default
type=tunnel
keyexchange=ikev2
ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256
dpdaction=restart
dpddelay=10s
dpdtimeout=30s
rekey=yes
reauth=no
conn site-to-site
left=192.168.1.2
leftid=serverB.alt.local
leftcert=serverB.crt
leftsubnet=10.20.20.0/24
leftauth=pubkey
right=192.168.1.1
rightid=serverA.alt.local
rightcert=serverA.crt
rightsubnet=10.10.10.0/24
rightauth=pubkey
auto=start
Используйте код с осторожностью.
Шаг 2. Применить настройки и запустить
После того как вы сохраните файлы на обоих серверах, выполните команды:
На обоих серверах перезапустите службу для очистки старых политик ядра:
bash
systemctl restart strongswan
Используйте код с осторожностью.
На Сервере А принудительно инициируйте соединение:
bash
swanctl --initiate --child site-to-site
Используйте код с осторожностью.
Если после этого туннель снова выдаст ошибку, пришлите, пожалуйста, логи со второго сервера (Сервера Б) в момент подключения. Их можно посмотреть командой journalctl -u strongswan -n 30. Это покажет, почему именно Сервер Б отвергает предложение.
Перейти к предыдущему запросу
Задайте вопрос
Ответ от режима ИИ готов.Задать вопрос по теме: 