У меня есть два сервера, устанавливающих IPSec VPN как тип настройки site-to-side. Я использую StrongSwan на Ubuntu 16.04 для обоих серверов, и сам VPN работает. Что может быть немного особенным, так это то, что подсеть за каждым шлюзом просто виртуальная, как в случае, когда я создал виртуальный сетевой адаптер. eth0:0.
auto eth0
iface eth0 inet static
address <PublicIP-A>
... etc
auto eth0:0
iface eth0:0 inet static
address 192.168.6.1
netmask 255.255.255.0
broadcast 192.168.6.255
(Второй сервер имеет 192.168.6.0/24 network и PublicIP-B, где PublicIP-A и -B, естественно, заменяются реальными и рабочими IP-адресами.)
Причина создания виртуальной сети заключается в том, что я хочу подключиться к одному из серверов через туннель IPSec VPN и использовать этот туннель для передачи данных по SSH / FTP. Я обнаружил, что для подключения к серверу через SSH / FTP или ping мне нужна эта виртуальная сеть. (Обнаружено, что в более ранних тестах с конфигурацией VPN типа «сеть-сеть», которая работала; к сожалению, это изменилось с моей настройкой типа «сеть-сеть».) Подходит ли виртуальная сеть? Есть что-нибудь получше?
Мой /etc/ipsec.conf:
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
authby=secret
keyexchange=ike
conn net-net
right=<PublicIP-A>
rightsubnet=192.168.6.0/24
left=<PublicIP-B>
leftsubnet=192.168.5.0/24
auto=add
Когда я traceroute адрес виртуальной сети сервера B 192.168.5.1, он пытается пройти через Интернет вместо туннеля и застревает ... Итак, я попытался настроить маршруты с подобными подходами в различных комбинациях - но с очень ограниченным успехом:
ip route add 192.168.5.0/24 via 192.168.6.1 dev eth0 src PublicIP-A table 220
Я также попробовал некоторые настройки iptables, взятые из документации StrongSwan (https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/), но не запустил.
Я надеюсь, что эта настройка имеет смысл для всех, кто поможет мне выяснить, как настроить мою маршрутизацию, чтобы трафик в виртуальную локальную сеть другого сервера проходил через туннель. Нужна дополнительная информация - пожалуйста, не сомневайтесь ...
Заранее спасибо!
ИЗМЕНИТЬ 2016-08-26
Думая о комментарии @ ecdsa, мне не нужна настройка site-to-site. Site-to-host в порядке.
traceroute вывод
traceroute to PublicIPServer-B (PublicIPServer-B), 30 hops max, 60 byte packets
1 PublicIPServer-B (PublicIPServer-B) 1.467 ms 1.298 ms 1.229 ms
тогда как без туннеля всплывают некоторые другие шлюзы.
Это помогло перейти с сервера B на хост A - SSH работает - но другое направление не хочет работать. Позже реальная настройка будет осуществляться по принципу «сайт-хост», где за шлюзом B находится реальная сеть.
Взято отсюда https://www.strongswan.org/testing/testresults/ikev2/host2host-cert/, Я пытался добавить маршрут
ip route add PublicIPServer-B via PublicIPServer-B src PublicIPHost-A
// and
ip route add 192.168.5.0/24 via PublicIPServer-B src PublicIPHost-A
что приводит к RTNETLINK answers: Network is unreachable ошибки. Не уверен, что мне когда-нибудь понадобится прямая связь между хостами, но было бы неплохо на всякий случай. (Тем более что я не уверен на 100%, что ответы на traceroute отправляются через туннель)
Есть идеи, как достичь последнего бита?
ИЗМЕНИТЬ 2016-08-26 (2-й)
По-видимому, strongSwan настраивает маршруты в этом сценарии. traceroute-ing и ping-ing удаленная подсеть (как в IP-адресе удаленной подсети Server-B 192.168.5.1) работает.
Так что да, я думаю, что на данный момент это решено!
Приветствую @ecdsa