A resposta para esta pergunta foi muito útil para mim entender o roteamento usado com o openvpn. Mas ainda estou confuso sobre a interface de tunelamento (tun0 abaixo), especialmente no que diz respeito ao acesso à LAN remota.
Aqui está a tabela de roteamento:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
10.172.1.1 10.172.1.5 255.255.255.255 UGH 0 0 0 tun0
10.172.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.172.1.5 128.0.0.0 UG 0 0 0 tun0
168.1.6.15 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
Eu entendo que ao usar o openvpn, ele vai primeiro para 10.172.1.1 e não para 10.172.1.5 por causa dessa regra de unicast:
10.172.1.1 10.172.1.5 255.255.255.255 UGH 0 0 0 tun0
Então, como não há regra para 10.172.1.1, ele vai para eth1. Mas porque eth1 tem essa regra de unicast:
168.1.6.15 192.168.1.1 255.255.255.255 UGH 0 0 0 eth1
Vai para o outro lado do túnel, em 168.1.6.15.
Na resposta da questão mencionada acima, dizemos que poderíamos adicionar esta regra para acessar a LAN remota:
10.172.1.0/24 dev tun0 proto kernel scope link src 10.172.1.5
Mas o que faz para acessar as unidades de rede remota? Eles estão diretamente disponíveis na interface de tunelamento (tun0)? Se eles, como openvpn vai para fora (eles são remotos)? Porque eu estou premindo que não está usando 168.1.6.15 neste caso. Isso?
Obrigado por qualquer esclarecimento!
Todo o tráfego roteado através do dispositivo tun0 (tráfego incluído em direção a 10.172.1.0/24 sub-redes representando PCs da LAN remota ) é criptografado e encapsulado e, em seguida, roteado pela interface eth1.
Pacote encapsulado:
envio de pacotes através da eth1:
Tags networking vpn openvpn ip routing