+----------+
+-------+ Client 1 |
+--------------+ +---------------+ +----------+ +------------+ | +----------+
| Web Server +-------------+ Cisco ASA5585 +---------+ Internet +-----------+ StrongSwan +--------+ IP: 10.2.0.1
+--------------+ +---------------+ +----------+ +------------+ |
| +----------+
+-------+ Client 2 |
Internal Web server External IP: 1.1.1.1 External IP: 2.2.2.2 +----------+
https://some.webservice.net Internal IP: 10.1.0.1 IP: 10.3.0.1
192.168.0.1:443
Клиенты 1 и 2 находятся в разных подсетях / 20 и нуждаются в доступе к внутреннему веб-серверу на удаленной стороне через хост для размещения туннеля IPSEC VPN между сервером StrongSwan и удаленным устройством Cisco ASA.
У нас нет контроля над удаленной стороной.
У нас есть маршрутизация, позволяющая клиенту 1 и клиенту 2 достигать сервера StrongSwan.
У нас есть туннель, установленный между сервером StrongSwan и устройством Cisco ASA.
У нас включена переадресация IP на сервере StrongSwan.
Я пытаюсь выяснить, возможно ли использовать iptunnel для маскировки клиентов 1 и 2 как самого сервера StrongSwan, чтобы позволить им получить доступ к внутреннему веб-серверу на удаленной стороне туннеля.
Вы можете сделать это с помощью iptables настроен в поле StrongSwan.
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
предполагая, что eth0 - это ваш исходящий эфир (Ethernet в Интернет)
Простой способ подключения к веб-серверу с машины StrongSwan - установка прокси, например squid и использовать его от клиентов вместо прямого подключения к веб-серверу.
В зависимости от того, к какому типу ресурсов клиенты хотят получить доступ на веб-сервере, полноценный кальмар может оказаться излишним. Если это только порт 443, и вам не нужен порт 443 на StronSwan для других целей, вы можете использовать redirect вариант xinetd на StrongSwan. Это сделает необходимые записи etc / hosts в ваших клиентах, в противном случае сертификат веб-сервера будет отклонен из-за очевидного несоответствия имени. Есть и другие TCP-прокси, кроме xinetd redirect, но вы поняли идею.