Часть 0. Вводная.
Итак. Задача объединить две сети посредством OpenVPN. В распоряжении имеются два роутера, построенных на Debian 11. Схема сети ниже.
В принципе, все стандартно. Слева подсеть 192.168.1.0/24, внешний интерфейс роутера имеет статический IP, это ежу понятно. Адрес LAN-интерфейса 192.168.1.1/24. На сервере имеется стандартный набор правил iptables, в том числе и для NAT. Здесь же находится «серверная» часть OpenVPN. Справа подсеть 192.168.4.0/24 (так сложились звезды), где вообще-то локальная сеть в боевой задаче — это клиенты небезызвестного Wireguard. Но если мы вместо виртуального интерфейса запихаем физическую сетевуху с коммутатором и компами — ничего не поменяется, разве что имена интерфейсов. Адрес LAN-интерфейса (или туннельного интерфейса сервера Wireguard) 192.168.4.1/24. VPN-туннель будет подниматься в сети 192.168.10.0/24, так называемая линковая сеть. Туннельный интерфейс сервера имеет адрес 192.168.10.1/24, клиента 192.168.10.2/24
В статью пока не входит настройка центра сертификации OpenVPN, будем считать что все сертификаты уже сгенерированы. Имя сервера server, имя клиента — соответственно client. Сертификаты клиента и CA сервера включены в конфигурационный файл клиента чтоб не разводить много мусора.
Маршруты в данном руководстве задаются только на сервере. Топология VPN-сети — subnet.
Часть 1. Настройка Site A (сторона сервера)
Пилим конфиг /etc/openvpn/server.conf
# Прослушиваемый IP-адрес, порт
local x.x.x.x
port 1194
proto udp
# С tap интерфейсом проще, но нам нужен именно туннельный режим
dev tun
# Запускаем сервер с TLS
tls-server# Пути к сертификатам
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/ta.key 0# Топология сети. Для выбранного tun интерфейса должна быть такая
topology subnet
# Объявляем подсеть VPN
server 192.168.10.0 255.255.255.0
# В этой директории хранятся конфиги маршрутов и IP адресов клиентов
client-config-dir /etc/openvpn/ccd
# Добавляем маршрут на сервере до подсети 192.168.4.0/24 через шлюз 192.168.10.2.
# Если сетей несколько — маршрутов должно быть столько же, со своими адресами шлюзов
route 192.168.4.0 255.255.255.0 192.168.10.1
# Говорим клиентам прописать у себя маршруты до подсети за сервером
push «route 192.168.1.0 255.255.255.0»
# Указываем на стороне VPN-клиентов единый адрес шлюза до подсети за сервером
route-gateway 192.168.10.1
# Если нужны DNS-серверы — указываем
#push «dhcp-option DNS 192.168.1.4»
#push «dhcp-option DNS 192.168.1.1»
# Разрешаем обмен трафика между клиентами
client-to-client#Время жизни неактивной сессии
keepalive 10 120# Что-то про шифер. Triple-DES — это тяжелый шифер, а у AES есть аппаратная поддержка в этом вашем Intel
cipher AES-128-CBC
auth MD5# Понижаем в правах демона
user nobody
group nogroup# При перезапуске не перечитывать ключи и не передергивать интерфейсы
persist-key
persist-tun#Логирование
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
В директории /etc/openvpn/ccd создаем файл с именем клиента (который мы указывали при генерации сертификатов), в данном случае client, со следующим содержимым:
# Назначаем туннельному интерфейсу IP-адрес
ifconfig-push 192.168.10.2 255.255.255.0
# Сообщаем серверу, что за клиентом подсеть 192.168.4.0/24
iroute 192.168.4.0 255.255.255.0
Рестартуем демона, проверяем поднялся ли интерфейс tun0, смотрим маршруты, должен быть 192.168.4.0/24 via 192.168.10.2 dev tun0
Также надо открыть UDP порт 1194, разрешить iptables пускать трафик по интерфейсу tun0 и перенаправлять его между туннельным интерфейсом tun0 и интерфейсом локальной сети (для примера пусть это будет eth1). В sysctl, естественно, должен быть разрешен форвардинг; у нас роутер, ранее настроено. Если нет — на клиенте будет пример настройки. Итак, добавляем (или вставляем в нужное место, до DROP) правила файрвола:
# Открываем порт, можно указать интерфейс
iptables -A INPUT -p udp —dport 1194 -j ACCEPT
# Разрешаем входить и выходить трафику через туннельный интерфейс
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT
# Разрешаем форвардинг трафика туда и обратно
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT
Часть 2. Настройка Site B (сторона клиента)
На клиентском шлюзе пилим конфиг /etc/openvpn/client.conf
# Говорим, что мы клиент
client
# Адрес и порт сервера
remote x.x.x.x 1194
dev tun
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-128-CBC
auth MD5
verb 3
key-direction 1
auth-nocachestatus /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3#Раздел с сертификатами и ключами
<ca>
<BASE64_CA_SERVER_CERT>
</ca><tls-auth>
<BASE64_TA_SERVER_CERT>
</tls-auth>
<cert>
<CLIENT_CERT>
</cert>
<key>
<BASE64_CLIENT_PRIVATE_KEY>
</key>
Включаем и запускаем демона, после @ — имя конфига
systemctl enable openvpn@client
systemctl start openvpn@client
Если все правильно — поднимется интерфейс tun0 с назначенным IP адресом 192.168.10.2/24 и пропишется маршрут 192.168.1.0/24 via 192.168.10.1 dev tun0
Далее нужно разрешить форвардинг трафика между интерфейсами. В /etc/sysctl.conf раскомменчиваем или дописываем строку net.ipv4.ip_forward=1 и применяем командой sysctl -p
Про настройку файрвола также не стоит забывать, настройки аналогичны (порт открывать не надо).
Часть 3. Мы строили-строили, и наконец построили. Тестируем
Сперва смотрим доступность соседних шлюзов через VPN-туннель. С сервера пингуем 192.168.10.2, с клиента соответственно 192.168.10.1.
Также можно проверить форвардинг пакетов. Пингуем LAN-интерфейсы — с серверного клиентский 192.168.4.1, с клиентского серверный 192.168.1.1
Ну и самое главное (вообще можно проверять сразу) — проверяем маршрутизацию трафика между подсетями. Либо обычным пингом с любого хоста Site A на любой хост Site B. Либо трассировкой, например, с Windows-хоста 192.168.1.7:
Трассировка маршрута к 192.168.4.2 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 192.168.1.1
2 24 ms 24 ms 24 ms 192.168.10.2
3 140 ms 98 ms 96 ms 192.168.4.2Трассировка завершена.
Все верно. Хост видит, что пакет не адресован ни одной из известных сетей, в таблице маршрутизации записей о хосте 192.168.4.2 нет — идет на шлюз по-умолчанию. Шлюз по-умолчанию в соответствии со своей таблицей маршрутизации посылает пакет на IP-адрес маршрутизатора следующего перехода через туннель, принимающая сторона форвардит пакет в сеть назначения.
З.Ы. А еще это преспокойно работает на динамических IP-адресах, и даже с «серым» адресом со стороны клиента (keepalive-ы возможно подтюнить надо будет), естественно с настроенным и стабильно работающим DDNS-сервисом на стороне сервера. И даже больше — можно взять два роутера, прошитых под OpenWRT, и настроить то же самое, 90% настроек делается через интерфейс LuCI, небольшие отличия с настройкой зон и правил файрвола. Но это уже совсем другая история…
