Я настроил сеть OpenVPN 10.8.0.0/24 (сеть A), работающую в Azure. IP-адрес виртуальной машины Linux - 10.1.0.4 в сети 10.1.0.0/24 в Azure (сеть B). Я также настроил маршрутизатор в качестве клиента OpenVPN с собственной подсетью 192.168.1.0/24 (сеть C).
В Azure есть виртуальная машина Windows Server с IP-адресом 10.1.0.5. На удаленном маршрутизаторе есть устройство с IP 192.168.1.223.
Итак, чтобы подвести итог, у меня есть следующие сети:
И эти устройства:
Я настроил таблицы маршрутизации, чтобы устройство на IP 192.168.1.223 и виртуальная машина Windows Server на IP 10.1.0.5 может связываться друг с другом. Это работает отлично.
Проблема возникает, когда я хочу отправить ловушки SNMP (UDP 162) с устройства на виртуальную машину Windows Server. Пакеты принимаются с IP-адресом источника 10.8.0.3 (IP-адрес маршрутизатора в сети OpenVPN). Я пытаюсь подключиться к Strongswan (5.5.3-3), и это кажется успешным: Запуск ...
Я использую систему ArchLinux и пытаюсь подключиться к моей корпоративной VPN, которая обслуживается Можжевельник SRX100H. Я пытаюсь подключиться к Strongswan (5.5.3-3), и вроде как успешно:
Starting strongSwan 5.5.3 IPsec [starter]...
generating QUICK_MODE request 2638887156 [ HASH SA No KE ID ID ]
sending packet: from 192.168.1.204[4500] to 10.0.0.1[4500] (396 bytes)
received packet: from 10.0.0.1[4500] to 192.168.1.204[4500] (364 bytes)
parsed QUICK_MODE response 2638887156 [ HASH SA No KE ID ID ]
CHILD_SA test{2} established with SPIs cad5681f_i 4015b7bd_o and TS 192.168.1.204/32 === 192.168.32.0/24
connection 'test' established successfully
Проблема в том, что после этого я не могу пинговать ничего, кроме 10.0.0.1, который возвращает ответ. Но я не могу связаться ни с одним из пиров внутри 192.168.32.0/24.
Мой ipsec.conf выглядит так:
conn test
left=%any
leftid=test@SRX100-local.de
leftauth=psk
leftauth2=xauth
rightsubnet=192.168.32.0/24
rightid=10.0.0.1
rightauth=psk
auto=start
xauth_identity=USER
esp=aes256-sha1-modp1536
ike=aes256-sha2_256-modp1536
aggressive=yes
type=tunnel
Результат ip route show
:
default via 192.168.1.1 dev wlp3s0 proto static metric 600
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.204 metric 600
Другие клиенты ( Windows) может подключаться к NCP Secure Client, так что я предполагаю, что это не проблема брандмауэра на стороне Juniper.
Любая помощь приветствуется:)
Вывод iptables-save
# Generated by iptables-save v1.6.1 on Tue Aug 8 11:24:43 2017
*filter
:INPUT ACCEPT [5:2010]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:999]
-A INPUT -s 192.168.32.0/24 -d 192.168.1.204/32 -i wlp3s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 192.168.1.204/32 -d 192.168.32.0/24 -o wlp3s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Tue Aug 8 11:24:43 2017
] Charon_debug.log находится здесь: https://pastebin.com/jYiqpLip
При помощи @ecdsa через IRC:
Отсутствующие свойства были leftsourceip =% config
и modeconfig = push
, потому что Juniper передает необходимые настройки клиенту.
Я думаю, это связано с iptables
попробуйте добавить это:
leftfirewall=yes
rightfirewall=yes
Это было решение для меня использовать ssh для любого хоста в сети на другой стороне туннеля.
Разрешить пересылку IPv4
Отредактируйте /etc/sysctl.conf, чтобы разрешить пересылка в ядре Linux.
vi /etc/sysctl.conf
Добавьте в файл следующую строку.
net.ipv4.ip_forward=1
Сохраните файл, затем примените изменения.
sysctl -p