Eu tenho um host linux ip 172.31.29.44 estabelecendo um túnel ipsec com um Juniper SRX. A sub-rede esquerda é 172.31.29.0/24 e a sub-rede correta é 10.32.0.0/11. O túnel foi estabelecido e eu posso fazer ping de hosts de 172.31.29.44 a 10.32.10.20, por exemplo.
Agora eu gostaria que um host 172.31.29.55 direcionasse o tráfego para 10.32.10.20 a 172.31.29.44 e não posso fazer isso funcionar, espero que alguém possa me ajudar. Eu adicionei manualmente hosts estáticos em 182.31.29.55 para encaminhar 10.32.0.0/11 até 172.31.29.44.
ipsec.conf
config setup
charonstart=yes
plutostart=yes
conn mtsrx
authby=secret
auto=route
esp=aes128-sha1-modp2048,3des-sha1!
ike=aes128-sha1-modp2048,3des-sha1-modp1536!
ikelifetime=28800
keyexchange=ikev1
[email protected]
[email protected]
right=185.90.212.100
leftsubnet=172.31.29.0/24
rightsubnet=10.32.0.0/11
auto=start
root@ip-172-31-29-44:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@ip-172-31-29-44:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-1049-aws, x86_64):
uptime: 19 hours, since Mar 01 15:37:06 2018
malloc: sbrk 2433024, mmap 0, used 355232, free 2077792
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 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 connmark stroke updown
Listening IP addresses:
172.31.29.44
Connections:
mtsrx: %any...185.90.212.100 IKEv1
mtsrx: local: [awsubuntu.domain.com] uses pre-shared key authentication
mtsrx: remote: [srx240.domain.com] uses pre-shared key authentication
mtsrx: child: 172.31.29.0/24 === 10.32.0.0/11 TUNNEL
Security Associations (1 up, 0 connecting):
mtsrx[3]: ESTABLISHED 3 hours ago, 172.31.29.44[awsubuntu.domain.com]...185.90.212.100[srx240.domain.com]
mtsrx[3]: IKEv1 SPIs: 4bcdf7191c753d2c_i* 45a1b12c11f6ac78_r, pre-shared key reauthentication in 3 hours
mtsrx[3]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
mtsrx{28}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cc44e3a1_i 9e355fcb_o
mtsrx{28}: AES_CBC_128/HMAC_SHA1_96, 1106 bytes_i (9 pkts, 248s ago), 3612 bytes_o (57 pkts, 248s ago), rekeying in 10 minutes
mtsrx{28}: 172.31.29.0/24 === 10.32.0.0/11
root@ip-172-31-29-44:~# ip route show table 220
10.32.0.0/11 via 172.31.16.1 dev eth0 proto static src 172.31.29.44
root@ip-172-31-29-44:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 172.31.29.55 anywhere policy match dir out pol ipsec
MASQUERADE all -- 172.31.29.55 anywhere
EDITAR sysctl -a | saída de encaminhamento grep
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv6.conf.all.forwarding = 1
sysctl: reading key
"net.ipv6.conf.all.stable_secret"net.ipv6.conf.all.mc_forwarding = 0
sysctl: net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
reading key "net.ipv6.conf.default.stable_secret"
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.eth0.mc_forwarding = 0
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
Um tcpdump em 172.31.29.44 (que é o gw para a rede 10.32.0.0/20) não mostra pings de 172.31.29.55 a 10.32.10.20
root@ip-172-31-29-44:~# tcpdump -v -n dst host 10.32.10.20
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Embora eu veja as solicitações icmp quando pings são feitos de 10.32.10.20 a 172.31.29.55, embora eu nunca receba uma resposta
root@ip-172-31-29-44:~# tcpdump -v -n dst host 172.31.29.55
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:00:20.914992 IP (tos 0x0, ttl 63, id 1558, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 11, length 64
15:00:20.915013 IP (tos 0x0, ttl 62, id 1558, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 11, length 64
15:00:21.915119 IP (tos 0x0, ttl 63, id 1588, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 12, length 64
15:00:21.915140 IP (tos 0x0, ttl 62, id 1588, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 12, length 64
15:00:22.915262 IP (tos 0x0, ttl 63, id 1832, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 13, length 64
15:00:22.915283 IP (tos 0x0, ttl 62, id 1832, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 13, length 64
15:00:23.915364 IP (tos 0x0, ttl 63, id 2124, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 14, length 64
15:00:23.915389 IP (tos 0x0, ttl 62, id 2124, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 14, length 64
15:00:24.915523 IP (tos 0x0, ttl 63, id 2231, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 15, length 64
15:00:24.915543 IP (tos 0x0, ttl 62, id 2231, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 15, length 64
15:00:25.915605 IP (tos 0x0, ttl 63, id 2245, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 16, length 64
15:00:25.915627 IP (tos 0x0, ttl 62, id 2245, offset 0, flags [DF], proto ICMP (1), length 84)
10.55.20.20 > 172.31.29.55: ICMP echo request, id 5, seq 16, length 64
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
EDIT (5 de março)
Na verdade, eu mudei o ip da vm 10.32.10.20 para 10.55.20.20 (ainda está abaixo de 10.32.0.0/11), então eu ainda devo receber a resposta icmp. Desculpe por essa confusão, mas me pediram para alterar ips.
172.31.29.55 é uma máquina Windows e esta é a saída da tabela de rotas:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.31.16.1 172.31.29.55 25
10.51.0.0 255.255.0.0 172.31.29.44 172.31.29.55 26
10.55.0.0 255.255.0.0 172.31.29.44 172.31.29.55 26
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
169.254.169.250 255.255.255.255 172.31.16.1 172.31.29.55 50
169.254.169.251 255.255.255.255 172.31.16.1 172.31.29.55 50
169.254.169.254 255.255.255.255 172.31.16.1 172.31.29.55 50
172.31.16.0 255.255.240.0 On-link 172.31.29.55 281
172.31.29.45 255.255.255.255 172.31.29.44 172.31.29.55 26
172.31.29.55 255.255.255.255 On-link 172.31.29.55 281
172.31.31.255 255.255.255.255 On-link 172.31.29.55 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.31.29.55 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.31.29.55 281
rota ip obter 10.55.20.20 em 172.31.29.44
root@ip-172-31-29-44:~# ip route get 10.55.20.20
10.55.20.20 via 172.31.16.1 dev eth0 src 172.31.29.44
cache
ip route obtém 172.31.29.55 a partir de 10.55.20.20 (o túnel é estabelecido no firewall Juniper que é 10.55.20.1)
10.55.20.20:/home/user# ip route get 172.31.29.55
172.31.29.55 via 10.55.20.1 dev eth0 src 10.55.20.20
iptables-save -c (Eu admito que chupei o iptables então acabei de encontrar uma solução por outro usuário experimentando o mesmo problema e adaptado à nossa situação)
root@ip-172-31-29-44:~# iptables-save -c
# Generated by iptables-save v1.6.0 on Mon Mar 5 14:54:25 2018
*nat
:PREROUTING ACCEPT [217:10432]
:INPUT ACCEPT [215:10288]
:OUTPUT ACCEPT [12048:726818]
:POSTROUTING ACCEPT [12050:726962]
[0:0] -A POSTROUTING -s 172.31.29.55/32 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
[0:0] -A POSTROUTING -s 172.31.29.55/32 -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Mar 5 14:54:25 2018
# Generated by iptables-save v1.6.0 on Mon Mar 5 14:54:25 2018
*filter
:INPUT ACCEPT [15639190:5523937001]
:FORWARD ACCEPT [7942:666888]
:OUTPUT ACCEPT [15701678:5516311562]
COMMIT
# Completed on Mon Mar 5 14:54:25 2018
Tags vpn routing strongswan