Minha topologia inclui HostA executando o cliente OpenVPN conectando-se ao servidor no HostB. O HostB tem o cliente OpenVPN conectado ao servidor no HostC. Ambos os túneis estão abertos e posso enviar solicitações de curl por meio de cada um, mas não consigo direcionar o tráfego do HostA, por meio do HostB, para o HostC. Por exemplo:
Public Private Client Tunnel Server Tunnel
HostA 1.1.1.1 10.120.177.168 10.8.0.6 10.8.0.1
HostB 2.2.2.2 172.30.24.54
HostC 3.3.3.3 10.140.17.141 10.9.0.6 10.9.0.1
HostA $ ip address
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state UP group default qlen 1000
inet 10.120.177.168/26 brd 10.120.177.191 scope global eth0
20: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.8.0.6 peer 255.255.255.0/32 scope global tun0
HostB $ ip address
4: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
inet 172.30.24.54/32 scope global eth0
18: tun010140017141: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
inet 10.9.0.6 peer 10.9.0.5/32 scope global tun010140017141
20: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
HostC $ ip address
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc prio state UP group default qlen 1000
inet 10.140.17.141/26 brd 10.140.17.191 scope global eth0
227: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 32000 qdisc pfifo_fast state UNKNOWN group default qlen 100
inet 10.9.0.1 peer 10.9.0.2/32 scope global tun0
HostA $ cat /etc/openvpn/client.conf
client
remote 2.2.2.2 443
proto tcp
dev tun
nobind
HostB $ cat /etc/openvpn/server/server.conf
port 443
proto tcp4
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.140.17.141 255.255.255.255 10.8.0.6"
client-config-dir ccd
route 10.120.177.168 255.255.255.255
HostB $ cat /etc/openvpn/server/ccd/gateway_10_120_177_168
ifconfig-push 10.8.0.6 255.255.255.0
iroute 10.120.177.168 255.255.255.255
HostB $ cat /etc/openvpn/client/tun010140017141/client.ovpn
client
remote 10.140.17.141 1194
proto tcp
dev tun010140017141
nobind
HostC $ cat /etc/openvpn/server.conf
port 1194
proto tcp
dev tun
server 10.9.0.0 255.255.255.0
- Omiti as partes da configuração relacionadas a certificados e registro, pois isso funciona.
Roteamento do kernel:
HostA $ ip route
default via 10.120.177.129 dev eth0
10.0.0.0/8 via 10.120.177.129 dev eth0
10.8.0.1 via 255.255.255.0 dev tun0
10.120.177.128/26 dev eth0 proto kernel scope link src 10.120.177.168
10.140.17.141 via 10.8.0.6 dev tun0
255.255.255.0 dev tun0 proto kernel scope link src 10.8.0.6
HostB $ ip rule list table my_routing_table
32764: from 10.140.17.141 lookup my_routing_table
32765: from 10.120.177.168 lookup my_routing_table
HostB $ ip route list table my_routing_table
10.120.177.168 dev tun0 scope link
10.140.17.141 dev tun010140017141 scope link
HostB $ ip route
default via 169.254.1.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.9.0.1 via 10.9.0.5 dev tun010140017141
10.9.0.5 dev tun010140017141 proto kernel scope link src 10.9.0.6
10.120.177.168 via 10.8.0.2 dev tun0
169.254.1.1 dev eth0 scope link
HostC $ ip route
default via 10.140.17.129 dev eth0
10.0.0.0/8 via 10.140.17.129 dev eth0
10.9.0.0/24 via 10.9.0.2 dev tun0
10.9.0.2 dev tun0 proto kernel scope link src 10.9.0.1
10.120.177.168 via 10.140.17.129 dev eth0
10.140.17.128/26 dev eth0 proto kernel scope link src 10.140.17.141
192.168.0.0/16 via 10.140.17.129 dev eth0
Eu quero realizar:
HostA $ curl -v https://10.140.17.141
mas a resposta é
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
O tráfego vem do HostA, pelo túnel para o HostB
HostB $ tcpdump --interface=tun0 -n host 10.140.17.141
12:55:07.039521 IP 10.8.0.6.44150 > 10.140.17.141.https: Flags [S], seq 2877997232, win 42340, options [mss 1358,sackOK,TS val 3699256805 ecr 0,nop,wscale 12], length 0
12:55:07.039629 IP 10.140.17.141.https > 10.8.0.6.44150: Flags [S.], seq 1620656485, ack 2877997233, win 65535, options [mss 1460,sackOK,TS val 19053367 ecr 3699256805,nop,wscale 9], length 0
12:55:07.046763 IP 10.8.0.6.44150 > 10.140.17.141.https: Flags [.], ack 1, win 11, options [nop,nop,TS val 3699256831 ecr 19053367], length 0
12:55:07.205307 IP 10.8.0.6.44150 > 10.140.17.141.https: Flags [P.], seq 1:178, ack 1, win 11, options [nop,nop,TS val 3699256988 ecr 19053367], length 177
12:55:07.205377 IP 10.140.17.141.https > 10.8.0.6.44150: Flags [.], ack 178, win 131, options [nop,nop,TS val 19053533 ecr 3699256988], length 0
12:55:07.206243 IP 10.140.17.141.https > 10.8.0.6.44150: Flags [R.], seq 1, ack 178, win 131, options [nop,nop,TS val 19053534 ecr 3699256988], length 0
12:55:07.392219 IP 10.8.0.6.44154 > 10.140.17.141.https: Flags [S], seq 3637655375, win 42340, options [mss 1358,sackOK,TS val 3699257178 ecr 0,nop,wscale 12], length 0
12:55:07.392277 IP 10.140.17.141.https > 10.8.0.6.44154: Flags [S.], seq 1233055697, ack 3637655376, win 65535, options [mss 1460,sackOK,TS val 19053720 ecr 3699257178,nop,wscale 9], length 0
12:55:07.412840 IP 10.8.0.6.44154 > 10.140.17.141.https: Flags [.], ack 1, win 11, options [nop,nop,TS val 3699257199 ecr 19053720], length 0
12:55:07.419864 IP 10.8.0.6.44154 > 10.140.17.141.https: Flags [P.], seq 1:319, ack 1, win 11, options [nop,nop,TS val 3699257206 ecr 19053720], length 318
12:55:07.419895 IP 10.140.17.141.https > 10.8.0.6.44154: Flags [.], ack 319, win 131, options [nop,nop,TS val 19053747 ecr 3699257206], length 0
12:55:07.420618 IP 10.140.17.141.https > 10.8.0.6.44154: Flags [R.], seq 1, ack 319, win 131, options [nop,nop,TS val 19053748 ecr 3699257206], length 0
mas não chega à outra interface
HostB $ tcpdump --interface=tun010140017141 -n host 10.140.17.141
nothing
Estou confuso porque o tcpdump indica que 10.140.17.141 está respondendo.
Eu sou capaz de falar com o HostC do HostB usando o túnel
HostB $ curl -v https://10.9.0.1
< HTTP/1.1 200 OK
que responde com a página que eu espero de
curl -v https://10.140.17.141
Para provar que está usando o túnel
HostB $ tcpdump --interface=tun010140017141 -n
13:09:45.950403 IP 10.9.0.6.45884 > 10.9.0.1.https: Flags [S], seq 226912329, win 65535, options [mss 1460,sackOK,TS val 879082581 ecr 0,nop,wscale 9], length 0
13:09:45.995483 IP 10.9.0.1.https > 10.9.0.6.45884: Flags [S.], seq 845398301, ack 226912330, win 31948, options [mss 1358,sackOK,TS val 3700256992 ecr 879082581,nop,wscale 12], length 0
13:09:45.995550 IP 10.9.0.6.45884 > 10.9.0.1.https: Flags [.], ack 1, win 128, options [nop,nop,TS val 879082626 ecr 3700256992], length 0
13:09:45.995727 IP 10.9.0.6.45884 > 10.9.0.1.https: Flags [P.], seq 1:518, ack 1, win 128, options [nop,nop,TS val 879082626 ecr 3700256992], length 517
13:09:46.043310 IP 10.9.0.1.https > 10.9.0.6.45884: Flags [.], ack 518, win 9, options [nop,nop,TS val 3700257036 ecr 879082626], length 0
13:09:46.043468 IP 10.9.0.1.https > 10.9.0.6.45884: Flags [.], seq 1:1347, ack 518, win 9, options [nop,nop,TS val 3700257038 ecr 879082626], length 1346
...
Como HostB tem a rota
10.140.17.141 dev tun010140017141 scope link
por que o pedido não é retransmitido?