Eu tenho uma conexão openvpn funcional para um servidor digital do oceano debian.
Aqui está minha tabela de roteamento, ip route :
0.0.0.0/1 via 10.8.0.5 dev tun0
default via 192.168.1.1 dev eth0 onlink
10.8.0.1 via 10.8.0.5 dev tun0
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
128.0.0.0/1 via 10.8.0.5 dev tun0
159.203.40.61 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.132
Tudo está bem.
Se eu traceroute minha máquina debian (159.203.40.61), o primeiro salto é imediatamente o gateway padrão, por causa da regra 159.203.40.61 via 192.168.1.1 dev eth0 . Não há dúvida lá.
Se eu traçar um IP externo, como 8.8.8.8, o primeiro salto é 10.8.0.1.
Isso é por causa da regra 0.0.0.0/1 via 10.8.0.5 dev tun0 e da regra unicast 10.8.0.1 via 10.8.0.5 dev tun0 . Assim, o tráfego é criptografado localmente usando a interface tun0 (primeiro salto 10.8.0.1). Eu acho que vai para 10.8.0.1 (e não para .5) por causa da regra unicast (me corrija se eu estiver errado).
No entanto, o segundo salto (ao traçar um IP externo) é 159.203.24.253. Isso é um IP do oceano digital, mas não é o IP da minha máquina digital do oceano. Por que é que ?
2 159.203.24.253 (159.203.24.253) 117.230 ms 116.918 ms 159.203.24.254 (159.203.24.254) 117.266 ms
(também há um .254, para balanceamento de carga, eu acho)
Eu pensei que, uma vez que ele precisa ir para fora, está mudando da interface tun0 para a interface eth0, onde o gateway padrão é (192.168.1.1). Então, como há a regra unicast 159.203.40.61 via 192.168.1.1 dev eth0 , estou esperando que o segundo salto seja 159.203.40.61, mas não é (em vez disso, é 159.203.24.253).
Atualização: Na máquina debian ocean digital, existe essa regra de roteamento:
159.203.24.0/20 dev eth0 proto kernel scope link src 159.203.40.61
Portanto, 159.203.24.253 e .254 estão na mesma rede da minha máquina digital marítima.
E o gateway padrão é o 159.203.24.1
Talvez haja uma regra no roteador 159.203.24.1 que está enviando o pacote para 159.203.24.253 et .254
Atualização 2 e talvez a resposta:
Solicitando 8.8.8.8 na minha máquina local. Criptografia de dados no tun0. O primeiro salto é 10.8.0.1 (não .5 devido à regra unicast) Para ir lá, precisa mudar para eth0: usando o gateway padrão 192.168.1.1 para ir para 159.203.40.61 (regra unicast).
A máquina digital marítima recebe o pacote. Primeiro vai para 10.8.0.1, descriptografia de dados no tun0. Então, como o destino final é 8.8.8.8, ele muda para eth0: o gateway padrão é 159.203.24.1, que é um roteador que envia o pacote para o segundo salto, que é 159.203.24.253/254
Parece que os gateways envolvidos entre dois saltos não são mostrados em um traceroute.