Всем привет! Как и обещал начало третьего блока.
3. Bash скрипт базовой настройки iptables
По умолчанию любой Linux дистрибутив имеет в таблице filter, в соответствующих цепочках, политику ACCEPT:
Можно конечно оставить и так. Но если речь идет о конечной станции пользователя или сервере который не должен находиться в DMZ сегменте, т.е. принимать входящие соединения извне, то лучше использовать следующую рекомендую. В нашем случае роль такой машины будет выполнять Ubuntu20_04_2.
Далее следует простой bash скрипт, способный повысить безопасность Linux box-а без особых ухищрений:
Чтобы вы не набивали руками скрипт вот вам сниппет:
#!/bin/bash
IPT=/sbin/iptables
#Устанавливаем политику по умолчанию для каждой цепочки
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT # Политика для исх. траффика ACCEPT
#Удаляем все правила в таблице filter (мало ли затесались)
$IPT -F
#Разрешаем траффик на петлевом интерфейсе
$IPT -A INPUT -i lo -j ACCEPT
#Разрешаем ICMP траффик
$IPT -A INPUT -p icmp -j ACCEPT
#Разрешаем входящий DNS траффик
$IPT -A INPUT -p udp --sport 53 -j ACCEPT
#Разрешаем входящие пакеты для TCP сессий инициированных нашим Linux box
$IPT -A INPUT -p tcp ! --syn -j ACCEPT
Не забываем сделать скрипт исполняемым:
chmod +x security.sh - делаем файл исполняемым
sudo ./security.sh - исполняем файл
Данный bash скрипт конфигурирует netfilter в базовое состояние в соответствии с политикой для Linux box как для конечной станции пользователя:
- $IPT -P INPUT DROP и $IPT -P FORWARD DROP - по умолчанию входящие подключения и транзит трафика для станций пользователя должны быть запрещены. Политика “все, что не разрешено, то запрещено”;
- $IPT -P OUTPUT ACCEPT - весь исходящий трафик по умолчанию разрешен. Политика “все, что не запрещено, то разрешено”;
- $IPT -F - вычищает существующие правила в таблице filter (если таковые имеются);
- $IPT -A INPUT ACCEPT -i lo -j ACCEPT - некоторые приложения используют TCP/IP коннекты на lo интерфейсе. Поэтому нет ничего страшного в том чтобы разрешить входящий трафик на петлевом интерфейсе;
- $IPT -A INPUT -p icmp -j ACCEPT - ICMP часто используют для DoS атак. Мир делится на тех кто отключает ICMP на особо защищаемых участках и тех кто осознанно идет на риск и не делают этого. Дело в том, что отключение ICMP сильно затрудняют поиск проблемных участков на сети и в целом диагностику сетевого взаимодействия. В нашем случае мы разрешаем ICMP для того, чтобы продолжать использовать ping, traceroute, mtr когда нам это понадобится;
- $IPT -A INPUT -p udp --sport 53 -j ACCEPT - для работы DNS и возможности преобразовывать domain names в IP адреса нам необходимо разрешить пакеты UDP трафика с 53 портом для отправителя. Это не идеальное правило и оно не защищает нас от атаки с использованием udp и 53 порта для создания udp туннеля. В идеале плюсом к 53 порту необходимо добавить IP адрес отправителя наш локальный DNS сервер или DNS сервера нашего оператора. Мы же оставим пока так;
- $IPT -A INPUT -p tcp ! --syn -j ACCEPT - ну и самое главное правило пропускает трафик TCP сессий которые инициированы нашей машиной. Т.е. мы запрещаем SYN на вход, пытающиеся инициировать с нашей машиной TCP сессию.
Дальше, по согласованию с ИБ, мы можем дополнять базовую конфигурацию. К примеру, мы хотим предоставить возможность администратору, управляющему Ubuntu20_04_1 подключаться к рабочим местам пользователя по ssh (см. Пример №1):
sudo iptables -N SSH - создаем отдельную цепочку
sudo iptables -A INPUT -p tcp --dport 22 -j SSH - указываем цепочке INPUT таблице filter искать правила для трафика адресованного на порт 22 в таблице SSH
sudo iptables -A SSH -s 192.168.0.1/32 -j ACCEPT #добавляем разрешающее правило для ssh коннектов с адреса Ubuntu20_04_1 (сеть LAN1)
sudo iptables -A SSH -j DROP #остальной трафик мы должны запретить
Не забываем сохраниться:
service netfilter-persistent save
4. Схемы и виды NAT
В данном уроке мы разберем какие виды NAT бывают, разберем такое понятие как stateful firewalls, научимся все это настраивать и отслеживать с помощью conntrack.
NAT может использоваться в разных сценариях (схемах):
One-to-one (1:1) - трансляция одного приватного адреса в один публичный;
One-to-many (1:Много) - трансляция одного приватного адреса в некоторый диапазон (range) публичных адресов;
Many-to-one (Много:Один) - трансляция диапазона приватных адресов в один публичный;
Many-to-Many (Много: Много) - трансляция диапазона приватных адресов в в некоторый диапазон (range) публичных адресов.
Самая часто встречающаяся схема “Many-to-one” - классическая схема предоставления пользовательским устройствам доступа в интернет известная еще под названием masquerading (SNAT).
NAT бывает следующих видов:
- SNAT (Source Address Translations). Также делится на static SNAT - отражение схемы “Many-to-one” и “One-to-one” и dynamic SNAT - отражение схем “One-to-many” и “Many-to-Many”. static - NAT в один адрес, dynamic - в заданный диапазон адресов;
- DNAT (Destination Address Translations). Обычно настраивается для того, чтобы опубликовать внутренний сервис в интернет. Редко когда используется в чистом виде. Обычно в связке с PAT (Port Address Translations);
- Symmetric NAT (RFC 3489) - наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети. Пример: вы настраиваете point-to-point UDP туннель, “приземляющийся” на железке “За NAT”. В этой схеме следует ограничить доступ к приватному адресу внешним адресом и портом источника UDP трафика противоположной стороны туннеля.
Symmetric NAT в данной схеме:
R1 натирует трафик в Pr1:port только в случае если адрес:порт источника UDP пакета = Pub2:port;
На стороне R2 может быть аналогичная схема. А может быть и немного другая. Это не меняет факта, что на стороне R1 используется Symmetric NAT.
4 . Full NAT (Full Cone NAT) - это по факту static SNAT и DNAT в совокупности. Full NAT - это когда за приватным адресом во внутренней сети закрепляется белый адрес. При этом для исходящих и входящих соединений может использоваться любой порт как есть (“as is”). Ограничения взаимодействия по портам настраиваются уже на межсетевом экране.
Есть еще несколько вариаций Full NAT, но с ограничениями:
5.Address Restricted Cone NAT (он же Restricted NAT) - промежуточный вариант между Full Cone и Symmetric, при котором маршрутизатор транслирует входящие пакеты только с определенного адреса источника, но номер порта источника при этом может быть любым;
6.Port Restricted Cone NAT (он же Port Restricted NAT) - то же, что и Address Restricted Cone NAT, но с тем отличием, что маршрутизатор обращает внимание на порт источника и не обращает внимания на адрес источника;
7.PAT или NAPT
PAT (Port Address Translation) или NAPT (Network Address and Port Translation). Идея тут в том, что меняется не только IP адрес, но и порт. В п.2 я уже говорил, что DNAT часто используется в связке с PAT. Мы разберем этот случай в уроке 4.
Редко когда в общении кто-то конкретизирует о каком виде NAT идет речь. Обычно говорят просто NAT и из контекста задачи становится понятно, что имеется сам факт преобразования в заголовках пакетов. В инструкциях, топологиях следует конкретизировать дабы было все предельно понятно при использовании документации в работе.
Как уже упоминалось SNAT занимается тем, что подменяет src IP для пакетов предназначенных адресату во внешней сети (классический вариант - Интернет). Говоря про SNAT часто используют понятие маскарадинга трафика (Masquerade или MASQ). Тут верно такое утверждение: “Любой маскарадинг есть SNAT, но не любой SNAT есть маскарадинг!”. В чем тут суть? А в том, что SNAT является маскарадингом только тогда когда в качестве src IP подставляется IP интерфейса интерфейса. В иных случаях речь идет о чистом нате. Очень часто маскарадят именно выход в интернет, а публикуют сервисы в DMZ с использованием совокупности SNAT и DNAT(PAT).
Разберем основные виды NATна реальных задачах в нашей лабе
5. Настраиваем SNAT и DNAT
Обратимся к схеме лабораторного стенда (1. Подготовка лабораторного стенда). У нас есть машина Centos 7 в DMZ сегменте. Давайте дадим ей доступ в Интернет!
Для этого нам понадобится настройка SNAT (MASQ) на пограничной машине Ubuntu20_04_1.
Внимание! Предполагается, что базовая связность стенда уже подготовлена. Данный вопрос рассматривался в первой ступени курса (Подготовка стенда в VB, базовая настройка сети и сервисов).
Попробуем пропинговать адрес 8.8.8.8:
На скрине вы видите, что пинг не проходит и мы проверяем есть ли в системе маршрут к адресу 8.8.8.8.
Вывод команды: 8.8.8.8 via (через) 192.168.0.1 говорит нам о том, что маршрут к 8.8.8.8 лежит через 192.168.0.1, а это как вы помните адрес внутреннего интерфейса машины Ubuntu20_04_1. Доступность этого адреса мы уже проверяли.
Очевидно, что для обеспечения Centos7 доступом в интернет необходимо выполнить некоторые манипуляции на Ubuntu20_04_1 (Router1).
Если на Centos7 запустить бесконечный ping, а на Ubuntu20_04_1 в это время запустить tcpdump:
sudo tcpdump -n -i enp0s8 icmp, то мы увидим такую картину:
Что мы видим? Мы видим, что прилетают ICMP запросы (request) на шлюзовой интерфейс enp0s8, но не видим ответов (replay). По логике, icmp запрос должен прийти на интерфейс enp0s8 (LAN1) и дальше уйти в сторону нашего домашнего роутера IP: 192.168.31.1. Запустим tcpdump на интерфейсе enp0s3 и проверим так ли это:
Если в первой ступени вы все сделали верно, то этот шаг можно пропустить!
Хм... А тут мы ничего не видим!
Все верно, дело в том, что в ядре Linux по умолчанию выключена возможность пропускать через себя транзитный трафик:
Команда sysctl net.ipv4.ip_forward даст вам вывод:
net.ipv4.ip_forward = 0 - значит транзит трафика запрещен. Чтобы изменить это необходимо выставить параметр в 1.
Для этого на Ubuntu20_04_1 в файле /etc/sysctl.conf необходимо добавить строку и сохранить изменения:
net.ipv4.ip_forward = 1
Чтобы зафиксировать изменения в sysctl необходимо выполнить следующую команду:
sudo sysctl -p /etc/sysctl.conf
Ну и для контроля рестарт сетевого сервиса:
sudo systemctl restart systemd-networkd
Опять запустим tcpdump на интерфейсе enp0s3 Ubuntu 20_04_1:
Отлично - мы разрешили транзит трафика. Но опять только requests. Все верно, SRC icmp пакетов = 192.168.0.3. Наша хостовая машина ничего не знает про этот адрес. Единственный адрес который она знает это адрес интерфейса enp0s3: 192.168.31.209. Чтобы наша хостовая машина могла вернуть icmp ответ от 8.8.8.8 нам необходим SNAT. Настраивать его мы будем через iptables.
Исходное состояние таблицы NAT в netfilter:
Для задачи SNAT нам понадобится таблица nat (очевидный факт). В качестве цепочки нам подходит POSTROUTING так как именно туда направляет процесс routing/forwarding пакет адресованные во внешний мир (в нашем случае в Интернет).
Добавляем правило:
sudo iptables --table nat --append POSTROUTING --source 192.168.0.3/32 --out-interface enp0s3 -j MASQUERADE
Внимание! После внесения изменений в конфигурацию iptables/netfilter необходимо обязательно сохраниться.
В iptables не тривиальная схема сохранения и восстановления правил. Для того чтобы сохранить правила на постоянку необходимо установить
sudo apt install iptables-persistent
Если apt не находит данный пакет, то сначала следует сделать apt update.
Сохраняем правила:
service netfilter-persistent save
Есть альтернативный вариант (но он менее тривиальный):
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Можно настроить и так:
sudo iptables -t nat -I POSTROUTING -s 192.168.0.3/32 -j SNAT --to [Public IP]
Public IP в моем случае - 192.168.31.209
но эту схему не стоит применять если внешний интерфейс получает IP динамически. При смене IP NAT перестанет отрабатывать. К чистому SNAT стоит прибегать в случае, если провайдер выделил вам отдельную сеть публичных адресов и вы вольны использовать их в правилах натирования.
Вот как выглядит таблица nat, после смены MASQ на SNAT.
Если вы решили попробовать второй вариант и еще не сохранили изменения и хотите вернуться к предыдущей конфигурации netfilter, то есть полезная команда iptables-restore:
iptables-restore < /etc/iptables/rules.v4
Проверим заработал ли доступ в интернет с Centos 7:
Все хорошо! Кстати когда вы выводили таблицу правил на машине Ubuntu20_04_1 вы должны были заметить столбцы pkts и bytes. Не нулевые и растущие значения свидетельствуют о том, что под правила попадает требуемый трафик. В узких кругах еще говорят: "Трафик матчится!"
Следующим этапом, после того как мы обеспечили для CentOS 7 L3 связность в сеть Интернет, необходимо настроить DNS клиента (если вы еще этого не делали). Выполните команду:
echo "nameserver 8.8.8.8" > /etc/resolv.conf
после этого проверьте, что машина способна резолвить имена в IP адреса:
Вот теперь мы можем ставить необходимые нам утилиты. Давайте поставим net-tools:
yum install net-tools -y
Взгляните на схему лабораторного стенда. По задумке Centos7 размещена в DMZ и на ней поднят веб сервер. Это все необходимо для сценария на котором будет разбираться дальнейший материал.
Примечание: DMZ (англ. Demilitarized Zone — демилитаризованная зона, ДМЗ) — сегмент сети, содержащий общедоступные сервисы и отделяющий их от частных. В качестве общедоступного может выступать, например, веб-сервис: обеспечивающий его сервер, который физически размещён в локальной сети (Интранет), должен отвечать на любые запросы из внешней сети (Интернет), при этом другие локальные ресурсы (например, файловые серверы, рабочие станции) необходимо изолировать от внешнего доступа.
Цель ДМЗ — добавить дополнительный уровень безопасности в локальной сети, позволяющий минимизировать ущерб в случае атаки на один из общедоступных сервисов: внешний злоумышленник имеет прямой доступ только к оборудованию в ДМЗ.
Давайте установим веб-сервер:
yum install httpd #устанавливаем
systemctl enable httpd #ставим в автозагрузку
По умолчанию http сервер работает на порту 80, изменим его на 8080:
откройте конфигурационный файл:
vi /etc/httpd/conf/httpd.conf, и замените строку Listen 80, на Listen 8080
systemctl start httpd #стартуем apache
С помощью netstat проверим, что порт 8080 прослушивается httpd сервисом:
Перейдите в директорию /var/www/html/ и создайте там файл index.html:
cd /var/www/html/
vi index.html
Внесите любой тест для страницы заглушки.
Проверим доступность web-сервера с Ubuntu20_04_1:
curl -I http://192.168.0.3/index.html
Неудачно!
Дело в том, что в CentOS по умолчанию включен FirewallD. Проверить это можно так:
firewall-cmd --state, если на стандартный поток вывода вы получите: running, то действительно встроенный межсетевой экран запущен.
Давайте отключим его, чтобы не мешался. Всю безопасность машин мы будем настраиваться с помощью netfilter.
systemctl stop firewalld #останавливаем встроенный FW
systemctl disable firewalld #убираем из автозагрузки
firewall-cmd --state, на этот раз мы должны получить на стандартный поток not running
Проверяем curl еще раз:
-I - позволяет просмотреть только заголовки ответа.
Следующим этапом на Ubuntu 20_04_1 (Router1) необходимо добавить правило для SNAT чтобы выпустить CentOS9_1 в интернет:
sudo iptables -t nat -A POSTROUTING -s 192.168.0.2/32 --out-interface enp0s3 -j MASQUERADE
Не забываем сохранить iptables правила!
Проверяем доступность 8.8.8.8 и редактируем /etc/resolv.conf так же как делали для Centos 7 (если еще этого не сделали).
После этого проверяем ping ya.ru:
Следующим этапом настроим на Ubuntu20_04_1 DNAT для Centos 7. Это делается для того чтобы опубликовать во внешнюю сеть WEB сервер, который был поднят в рамках первичного развертывания стенда.
Опять возвращаемся к схеме Netfilter Packet Traversal. Для задачи DNAT нам также понадобится таблица nat. Но в этот раз нам будет необходима цепочка PREROUTING. Так как нам важно изменить dst IP всех входящих на внешний интерфейс enp0s3 (Ubuntu20_04_1) пакетов с dst port = 80 на внутренний IP Centos7 (dst IP = 192.168.0.3) и dst port = 8080 до того как пакет будет обработан процессом routing/forwarding.
Вот как это настраивается:
sudo iptables -t nat --append PREROUTING -p tcp -i enp0s3 --dport 80 -j DNAT --to-destination 192.168.0.3:8080
Можно настроить и чуть по другому, указывая не интерфейс, а IP:
sudo iptables -t nat --append PREROUTING -p tcp -d 192.168.31.209 --dport 80 -j DNAT --to-destination 192.168.0.3:8080, но опять же, если произойдет смена IP (e.g. dhcp lease time истечет), то DNAT(PAT) не будет отрабатывать. Можете удалить предыдущее правило, предварительно выяснив его номер в соответствующей таблице/цепочке. А затем "прибить" PAT к конкретному IP.
sudo iptables -t nat -L PREROUTING -nv --line-numbers, где -n (числовой вывод), -v (избыточная информативность вывода), --line-numbers (нумерация правил в цепочках)
Это позволяет выяснить, что предыдущее правило у нас числится под номером 2.
sudo iptables -t nat -D PREROUTING 2, где -D ( сигнализирует об операции удаления в цепочке PREROUTING правила во 2-й строке).
sudo iptables -t nat --append PREROUTING -p tcp -d 192.168.31.209 --dport 80 -j DNAT --to-destination 192.168.0.3:8080 - "прибиваем" PAT к IP адресу 192.168.31.209
В обоих случаях результатом настройки SNAT и DNAT(PAT) должна стать успешная попытка отобразить тестовую страницу web сервера Apache из браузера вашего компьютера.
Это имитация доступа из сети Интернет!
С Centos9_1 веб-сервер тоже должен быть доступен, но по внутреннему адресу и с указанием порта 8080:
6. Двойной NAT или неприятная ситуация
Часто возникает ситуация когда адресные пространства, подключаемых с помощью VPN площадок пересекаются. Это неприятная ситуация, но из нее есть выход - двойной NAT.
Рассмотрим схему:
Задача: Объединить головной офис и филиал с использованием site-to-site VPN. Обойти проблему с пересечением адресных пространств - в головном офисе и в новом филиале есть пересечение подсетей: LAN1 - 192.168.0.0/29 и LAN3 - 192.168.0.0/24, обеспечив доступ с рабочего места Centos9_2-IP: 192.168.0.2/24 к web ресурсу Centos7-IP: 192.168.0.3/29.
Предварительно необходимо включить Ubuntu20_04_3 и Centos9_2.
Примечание:
Помните я говорил, про то что будет нюанс с CLIENTID клонированной машины?
Так вот фишка в том, что Networkd ответственный за работу сети в Ubuntu по умолчанию устанавливает в качестве источника запроса на получение адреса от DHCP сервера идентификатор duid (RFC4361).
Такое поведение вы встретите в дистрибутивах Ubuntu/Debian старше версии 18.04. Так как мы клонировали машину, то duid у них будет одинаков и Ubuntu20_04_3 получит тот же IP что и Ubuntu20_04_1, что как вы понимаете вызовет конфликт. Чтобы изменить это поведение нам необходимо сменить способ идентификации dhcp клиента с duid на mac.
Делается это просто в конфигурационном файле netplan:
Внутренний интерфейс Ubuntu20_04_3 (LAN3) и интерфейс CentOS9_2(LAN3) настройте по аналогии с тем как мы делали в головном офисе.
Не забываем применить настройки netplan.
Теперь можно не беспокоиться в уникальности WAN IP адресов Router1 и Router2
Назад к решению проблемы пересечения адресных пространств с помощью двойного NAT:
Решение:
- Настраиваем GRE туннель между головным офисом и филиалом:
Настройки GRE на Router 1 и Router 2 будут выглядеть следующим образом:
Router 1:
Router 2:
- Настраиваем псевдосети и помещаем их в таблицу маршрутизации за туннельные интерфейсы:
На R1 указываем, что за адресом 10.10.10.2 живет псевдосеть 192.168.20.0/24, где 10.10.10.2 - туннельный интерфейс R2, а 192.168.20.0/24 - псевдоподсеть для подсети 192.168.0.0/24 (LAN3):
routes:
- to: 192.168.20.0/24
via: 10.10.10.2
На R2 указываем, что за адресом 10.10.10.1 живет псевдосеть 192.168.10.0/24, где 10.10.10.1 - туннельный интерфейс R1, а 192.168.10.0/24 - псевдоподсеть для подсети 192.168.0.0/29 (LAN1):
routes:
- to: 192.168.10.0/24
via: 10.10.10.1
routes:
- to: 192.168.20.0/24
via: 10.10.10.2
Если все настроено верно, то результат должен быть вот таким:
Router 1:
Router 2:
При этом с R1 должен пинговаться туннельный интерфейс R2, а с R2 туннельный R1 соответственно:
Задача обеспечить связность между Centos 9_2 (филиал) и Centos 7 (головной офис). Для этого нам понадобится iptables.
Примечание:
По нашей задумке, для обхода проблемы пересечения:
- адрес 192.168.0.3 (Centos7) мапится в адрес 192.168.10.3;
- адрес 192.168.0.2 (Centos9_2) мапится в адрес 192.168.20.2;
C учетом такого хака взглянем на маршрут к псевдоадресу Centos 9_2 со стороны R1 и к Centos 7 со стороны R2:
Маршруты к псевдо адресам корректно настроены. Однако надо еще учесть тот факт что R1 ничего не знает про сеть 192.168.10.0/24, а R2 про 192.168.20.0/24. Поэтому когда, к примеру на R2, прилетит из туннеля пакет с адресом назначения 192.168.20.2, то R2 ничего не останется как отправить его дальше по маршруту по умолчанию, т.е. в сторону WiFi роутера (в моем случае это IP адрес 192.168.31.1).
Чтобы избежать этой ситуации создадим secondary ip на внутренних интерфейсах enp0s8 LAN1 и LAN3. Внимательно взгляните на скрины настроек netplan, там уже добавлены адреса 192.168.10.1 и 192.168.20.1. Теперь R1 и R2 имеют connected маршруты к псевдосетям:
Таким образом пакет не улетит в неизвестном направлении, а будет передан ядру Linux, а именно модулю netfilter на обработку где и произойдет магия двойного NAT.
И так схема магии в общем виде выглядит так:
Рассмотрим путь пакета от Centos 7 (192.168.0.3) к Centos 9 (192.168.0.2) и обратно:
- Пакет с src адресом: 192.168.0.3 и dst адресом: 192.168.20.2 попадает в процесс routing/forwarding R1 и для пакета определяется маршрут следования через 10.10.10.2 - адрес туннельного интерфейса;
- Прежде чем пакет будет инкапсулирован в туннель в цепочке POSTROUTING таблицы nat производится SNAT: 192.168.0.3 меняется на 192.168.10.3;
- Прежде чем пакет будет передан процессу routing/forwarding R2 в цепочке PREROUTING таблицы nat производится DNAT: dst адрес 192.168.20.2 меняется на 192.168.0.2;
- Пакет с src адресом: 192.168.0.2 и dst адресом: 192.168.10.3 попадает в процесс роутинга R2 и для пакета определяется маршрут следования через 10.10.10.1 - адрес туннельного интерфейса;
- Прежде чем пакет будет инкапсулирован в туннель в цепочке POSTROUTING таблицы nat производится SNAT: 192.168.0.2 меняется на 192.168.20.2;
- Прежде чем пакет будет передан процессу роутинга R1 в цепочке PREROUTING таблицы nat производится DNAT: dst адрес 192.168.10.3 меняется на 192.168.0.3.
Манипуляции в таблицах iptables:
R1:
R2:
Centos 9_2 у нас с графикой, а на Centos 7 у нас работает www сервер. Давайте попробуем открыть сайт с адресом 192.168.10.3:8080 с машины Centos 9_2:
Двойной NAT и GRE работает. Отлично! А что насчет безопасности трафика между Centos 9_2 (филиал) и Centos 7 (www сервер головного офиса)? Можно было бы настроить TLS на стороне www и этого было бы достаточно. Но что, если между площадками через GRE мы будем пускать разный трафик, в том числе не шифрованный. Скорее всего так и будет. Поэтому нам заранее необходимо позаботиться о шифровании GRE трафика. Для этого как нельзя лучше подойдет StrongSwan. Разберем настройку IPsec с помощью StrongSwan в следующем выпуске.
Следующий выпуск будет на тему: Безопасность GRE туннеля. IPsec на базе StrongSwan
Пишите комментарии, делитесь с друзьями, ставьте лайки - этим вы помогаете материалу быть виднее!
