Intereting Posts
Отказоустойчивая служба NFS с общим хранилищем Подстановочные знаки в способностях Использование «&&» недействительно для формы отправки cURL (не выполняйте вторую строку, если первая строка не работает) Звук Linux звучит при копировании с USB-ключа Тачпад Synaptics неактивен до приостановки, активен после возобновления У экземпляра Debian два ядра после установки драйверов Intel PCIe SSD – один с черным экраном в чем разница между usbtouchscreen и usbhid? Запуск аппаратных прерываний путем подключения параллельных портов 9 и 10 не работает Поддерживаются ли файловые системы с резервной копией (например, sysfs и procfs) в таблице суперблока и inode? Как использовать одинаковые настройки интерфейса для всех устройств wlan USB WiFi на CentOS7 Проблема tty: двоичный беспорядок вместо «текстовых хороших данных» Допускается пробел между #! и / bin / bash в shebang? Как указать медиа-каталог в MediaTomb Оптимизирует ли размер для уменьшения использования памяти во время выполнения, а также двоичный размер?

Strongswan перенаправляет трафик между двумя туннелями IPsec, где один из них является хостом

Я столкнулся с похожим вопросом, как описано здесь , но решение не работает в моем сценарии.

у меня есть

  • VPN-сервер A со статическим внешним IP-адресом AA.AA.AA.AA, внутренний IP-адрес 192.168.1.1 и внутреннюю подсеть 192.168.1.0/24
  • VPN-сервер B с динамическим внешним IP-адресом BB.BB.BB.BB, внутренний IP-адрес 192.168.2.254 и внутреннюю подсеть 192.168.2.0/24
  • мобильное устройство с динамическим внешним IP-адресом MM.MM.MM.MM и IP 192.168.250.129 при подключении к VPN

Между A и B две подсети прозрачно маршрутизируются через VPN, что отлично работает.

Мобильное устройство подключается к A и получает IP-адрес из подсети 192.168.250.128/25. Мобильное устройство может прекрасно общаться со всеми устройствами в подсети 192.168.1.0/24 (и наоборот), но не с любым устройством из 192.168.2.0/24.

На A я вижу, как поступают пакеты:

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25 19:28:31.367911 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 0, length 64 19:28:32.469991 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 1, length 64 19:28:33.410002 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 2, length 64 19:28:34.389997 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 3, length 64 19:28:35.449973 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 4, length 64 

В B никакие пакеты не захватываются.

Интересно, что отправка данных в другом направлении, то есть от хоста в подсети 192.168.2.0/24 к мобильному устройству, кажется, работает лучше.

Захват из B:

 hanjo@B:~$ sudo tcpdump -n net 192.168.250.0/24 20:44:27.201713 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 0, length 64 20:44:28.202222 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 1, length 64 20:44:29.202355 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 2, length 64 20:44:30.202603 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 3, length 64 

Захват от A:

 hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25 20:42:28.897441 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64 20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64 20:42:29.897510 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64 20:42:29.897962 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64 20:42:30.897469 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64 20:42:30.897918 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64 20:42:31.897458 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64 20:42:31.897911 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64 

Однако, как вы можете видеть, ответа эха не получено.

Это моя конфигурация Strongswan:

A ipsec.conf:

 conn B-tunnel left=AA.AA.AA.AA leftid="@A" right=B.dyndns rightid="@B" leftsubnet=192.168.1.0/24,192.168.250.0/24 rightsubnet=192.168.2.0/24 keyexchange=ikev2 type=tunnel authby=secret auto=route conn rw-v2 keyexchange=ikev2 left=AA.AA.AA.AA leftid="@A" right=%any leftsubnet=192.168.1.0/24,192.168.2.0/24 rightsourceip=192.168.250.128/25 rightdns=192.168.1.1 authby=secret conn mobile also=rw-v2 auto=add rightid="@mobile" 

B's ipsec.conf:

 conn A-tunnel left=192.168.2.254 leftsubnet=192.168.2.0/24 leftid=@B right=AA.AA.AA.AA rightsubnet=192.168.1.0/24,192.168.250.0/24 rightid=@A authby=secret type=tunnel auto=start 

Дополнительная информация от A:

 hanjo@A:~$ sudo ipsec statusall Status of IKE charon daemon (weakSwan 5.2.2, Linux 3.10.20, mips64): uptime: 7 hours, since Jan 08 14:50:14 2017 malloc: sbrk 586896, mmap 0, used 376264, free 210632 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 44 loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock Virtual IP pools (size/online/offline): 192.168.250.128/25: 126/1/1 Listening IP addresses: AA.AA.AA.AA 192.168.1.1 Connections: B-tunnel: AA.AA.AA.AA...B.dyndns IKEv2, dpddelay=30s B-tunnel: local: [A] uses pre-shared key authentication B-tunnel: remote: [B] uses pre-shared key authentication B-tunnel: child: 192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 TUNNEL, dpdaction=restart mobile: AA.AA.AA.AA...%any IKEv2, dpddelay=15s mobile: local: [A] uses pre-shared key authentication mobile: remote: [mobile] uses pre-shared key authentication mobile: child: 192.168.1.0/24 192.168.2.0/24 === dynamic TUNNEL, dpdaction=clear Routed Connections: B-tunnel{5}: ROUTED, TUNNEL B-tunnel{5}: 192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 Security Associations (6 up, 0 connecting): mobile[55]: ESTABLISHED 104 seconds ago, AA.AA.AA.AA[A]...MM.MM.MM.MM[mobile] mobile[55]: IKEv2 SPIs: 4dc26b00764d7fbf_i f00fd36247594b6a_r*, pre-shared key reauthentication in 106 minutes mobile[55]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 mobile{36}: INSTALLED, TUNNEL, ESP in UDP SPIs: c1012a86_i 08a38525_o mobile{36}: AES_CBC_256/HMAC_SHA1_96, 15163 bytes_i (100 pkts, 66s ago), 55569 bytes_o (78 pkts, 87s ago), rekeying in 44 minutes mobile{36}: 192.168.1.0/24 192.168.2.0/24 === 192.168.250.129/32 B-tunnel[19]: ESTABLISHED 6 hours ago, AA.AA.AA.AA[A]...BB.BB.BB.BB[B] B-tunnel[19]: IKEv2 SPIs: 97ef622accd69b0a_i* b1cd574224dcba1c_r, rekeying in 80 minutes, pre-shared key reauthentication in 70 minutes B-tunnel[19]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192 B-tunnel{5}: INSTALLED, TUNNEL, ESP in UDP SPIs: cbd873b7_i cebce241_o B-tunnel{5}: AES_CBC_256/HMAC_SHA2_512_256, 518363 bytes_i (3670 pkts, 0s ago), 274095 bytes_o (3733 pkts, 0s ago), rekeying in 21 minutes B-tunnel{5}: 192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 hanjo@A:~$ sudo ip xfrm policy src 192.168.250.129/32 dst 192.168.2.0/24 dir fwd priority 2851 tmpl src MM.MM.MM.MM dst AA.AA.AA.AA proto esp reqid 36 mode tunnel src 192.168.250.129/32 dst 192.168.2.0/24 dir in priority 2851 tmpl src MM.MM.MM.MM dst AA.AA.AA.AA proto esp reqid 36 mode tunnel src 192.168.2.0/24 dst 192.168.250.129/32 dir out priority 2851 tmpl src AA.AA.AA.AA dst MM.MM.MM.MM proto esp reqid 36 mode tunnel src 192.168.250.129/32 dst 192.168.1.0/24 dir fwd priority 2851 tmpl src MM.MM.MM.MM dst AA.AA.AA.AA proto esp reqid 36 mode tunnel src 192.168.250.129/32 dst 192.168.1.0/24 dir in priority 2851 tmpl src MM.MM.MM.MM dst AA.AA.AA.AA proto esp reqid 36 mode tunnel src 192.168.1.0/24 dst 192.168.250.129/32 dir out priority 2851 tmpl src AA.AA.AA.AA dst MM.MM.MM.MM proto esp reqid 36 mode tunnel src 192.168.2.0/24 dst 192.168.250.0/24 dir fwd priority 2883 tmpl src BB.BB.BB.BB dst AA.AA.AA.AA proto esp reqid 5 mode tunnel src 192.168.2.0/24 dst 192.168.250.0/24 dir in priority 2883 tmpl src BB.BB.BB.BB dst AA.AA.AA.AA proto esp reqid 5 mode tunnel src 192.168.250.0/24 dst 192.168.2.0/24 dir out priority 2883 tmpl src AA.AA.AA.AA dst BB.BB.BB.BB proto esp reqid 5 mode tunnel src 192.168.2.0/24 dst 192.168.1.0/24 dir fwd priority 2883 tmpl src BB.BB.BB.BB dst AA.AA.AA.AA proto esp reqid 5 mode tunnel src 192.168.2.0/24 dst 192.168.1.0/24 dir in priority 2883 tmpl src BB.BB.BB.BB dst AA.AA.AA.AA proto esp reqid 5 mode tunnel src 192.168.1.0/24 dst 192.168.2.0/24 dir out priority 2883 tmpl src AA.AA.AA.AA dst BB.BB.BB.BB proto esp reqid 5 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 hanjo@A:~$ sudo ip route default via AA.AA.AA.1 dev eth0 proto zebra AA.AA.AA.0/30 dev eth0 proto kernel scope link 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 hanjo@A:~$ sudo ip route show table 220 192.168.2.0/24 via AA.AA.AA.1 dev eth0 proto static src 192.168.1.1 192.168.250.129 via AA.AA.AA.1 dev eth0 proto static src 192.168.1.1 

Дополнительная информация от B:

 hanjo@B:~$ sudo ipsec statusall Status of IKE charon daemon (strongSwan 5.2.1, Linux 4.4.23+, armv6l): uptime: 24 hours, since Jan 07 22:19:36 2017 malloc: sbrk 663552, mmap 0, used 246232, free 417320 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12 loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity Virtual IP pools (size/online/offline): Listening IP addresses: 192.168.2.254 Connections: A-tunnel: 192.168.2.254,0.0.0.0/0,::/0...AA.AA.AA.AA,0.0.0.0/0,::/0 IKEv2, dpddelay=30s A-tunnel: local: [B] uses pre-shared key authentication A-tunnel: remote: [A] uses pre-shared key authentication A-tunnel: child: 192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24 TUNNEL, dpdaction=restart Security Associations (1 up, 0 connecting): A-tunnel[11]: ESTABLISHED 6 hours ago, 192.168.2.254[B]...AA.AA.AA.AA[A] A-tunnel[11]: IKEv2 SPIs: 0a9bd6cc2a62ef97_i 1cbadc244257cdb1_r*, pre-shared key reauthentication in 79 minutes A-tunnel[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192 A-tunnel{12}: INSTALLED, TUNNEL, ESP in UDP SPIs: cebce241_i cbd873b7_o A-tunnel{12}: AES_CBC_256/HMAC_SHA2_512_256, 275930 bytes_i (3754 pkts, 0s ago), 523881 bytes_o (3728 pkts, 0s ago), rekeying in 22 minutes A-tunnel{12}: 192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24 hanjo@B:~$ sudo ip xfrm policy src 192.168.250.0/24 dst 192.168.2.0/24 dir fwd priority 2883 tmpl src AA.AA.AA.AA dst 192.168.2.254 proto esp reqid 12 mode tunnel src 192.168.250.0/24 dst 192.168.2.0/24 dir in priority 2883 tmpl src AA.AA.AA.AA dst 192.168.2.254 proto esp reqid 12 mode tunnel src 192.168.2.0/24 dst 192.168.250.0/24 dir out priority 2883 tmpl src 192.168.2.254 dst AA.AA.AA.AA proto esp reqid 12 mode tunnel src 192.168.1.0/24 dst 192.168.2.0/24 dir fwd priority 2883 tmpl src AA.AA.AA.AA dst 192.168.2.254 proto esp reqid 12 mode tunnel src 192.168.1.0/24 dst 192.168.2.0/24 dir in priority 2883 tmpl src AA.AA.AA.AA dst 192.168.2.254 proto esp reqid 12 mode tunnel src 192.168.2.0/24 dst 192.168.1.0/24 dir out priority 2883 tmpl src 192.168.2.254 dst AA.AA.AA.AA proto esp reqid 12 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 hanjo@B:~$ sudo ip route default via 192.168.2.1 dev eth0 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.254 hanjo@B:~$ sudo ip route show table 220 192.168.1.0/24 via 192.168.2.1 dev eth0 proto static src 192.168.2.254 192.168.250.0/24 via 192.168.2.1 dev eth0 proto static src 192.168.2.254 

Любая идея, что может быть проблемой?

Это выглядит неправильно:

 20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64 

Зачем должен быть ICMP от публичного IP-адреса A до мобильного клиента, когда A просто перенаправляет трафик B? Что вы ожидаете, это пакет ESP с открытым IP-адресом A, но определенно не ICMP.

Возможно, есть правило NAT на A? Если это так, убедитесь, что модуль политики освобождает трафик, соответствующий политике IPsec, из фактического правила NAT. В основном добавьте что-то вроде этого до фактического правила NAT (также объясненного на сильной вики Wiki ):

 iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT