O que o netstat -r no OSX informa sobre os gateways?

Question

Eu notei que a tabela de rotas tem muitas entradas que eu não entendo.

A tabela de rotas é:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.0.254      UGSc           28        0     en1
10.8.0.1/32        10.8.0.5           UGSc            1        2    tun0
10.8.0.5           10.8.0.6           UH              2        3    tun0 
127                localhost          UCS             0      284     lo0 
localhost          localhost          UH             10     3663     lo0
169.254            link#5             UCS             0        0     en1
192.168.0          link#5             UCS             4        0     en1
192.168.0.25       localhost          UHS             0        0     lo0
192.168.100        10.8.0.5           UGSc            0        7    tun0

Eu acredito que esta rota diz:

1. Todo o tráfego em 192.168.100. * deve ser encaminhado para 10.8.0.5 (!?)
2. Todo o tráfego para 10.8.0.5 deve ser encaminhado para 10.8.0.6 (!?)
3. Todo o tráfego para 10.8.0.1/32 deve ser encaminhado para 10.8.0.5 (!?)

Por que 192.168.100 não vai para 10.8.0.1, mas em vez para 10.8.0.5, e depois de 5 para 6, e então eu acho que 1/32 deve combinar 6, e parece que há um loop .

Eu não consigo pingar 10.8.0.5, mas achei que era o meu ip na vnetwork. Eu não posso pingar 10.8.0.6, no entanto eu acho que é mascarado, eu recebo alguma saída "Comunicação proibida pelo filtro"

ifconfig mostra:

tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 
    open (pid 1307)

E há 6 - > 5 de novo!

OBSERVAÇÃO: a partir daqui, são apenas específicos, caso você precise de mais informações para entender as rotas.

Minha configuração é: - Laptop na rede local (192.168.0 ..) com roteador (192.168.0.254) - VPN conectada via roteador virtual (10.8.0.1) na rede (10.8.0 ...) a uma rede de (192.168.100 ...) com roteador (192.168.100.1) - 192.168.100.200 é um servidor na rede remota

Agora quando eu traceroute 192.168.100.200 ', eu esperava

10.8.0.1 (VPN router on the other side) 192.168.100.1 (Router on the physical network on the other side) 192.168.100.200 (host reached.)

Em vez disso, recebo um conjunto interminável de * s

Este não é o mesmo que esta questão , e não consegui encontrar uma resposta, então obrigado!

    

Answer 1

Você está lendo as informações da rota apenas parcialmente corretamente.

tun0 é a interface virtual usada para VPN, que usa (para seu próprio propósito interno) link ponto-a-ponto de 10.8.0.6 (VPNGW seu lado) para 10.8.0.5 (lado remoto do VPNGW). Essa é a mesma coisa que "ifconfig tun0" diz para você. Você não deve acessar esses dois endereços diretamente.

Assim, qualquer tráfego que você rotear via GW 10.8.0.5 entrará no túnel VPN (via interface tun0), e sairá do túnel VPN no outro lado (é claro, assumindo que o túnel VPN esteja estabelecido e funcionando, pelo processo VPN sendo executado com pid 1307).

10.8.0.1/32 10.8.0.5 UGSc 1 2 tun0

Isso significa que qualquer coisa enviada para o host 10.8.0.1 (/ 32 é CIDR notação, significando "apenas isso um host ") será roteado via gateway em 10.8.0.5 (ou seja, ele entrará em um túnel VPN).

Portanto, quando você executar o ping em 10.8.0.1, ele funcionará somente se os túneis VPN funcionarem. É por isso que está aqui (para que você possa verificar se o túnel está funcionando, mesmo que nenhum dos computadores do outro lado esteja ativo).

192.168.100 10.8.0.5 UGSc 0 7 tun0

igual ao anterior, mas para toda a rede de classe C 192.168.100. * (poderia também ter sido escrito como "192.168.100.0/24" no CIDR em vez de "192.168.100" mais curto). Essa é a principal coisa para a qual você configura o tunel - então você acessa essa faixa de endereços no lado remoto via VPN.

10.8.0.5 10.8.0.6 UH 2 3 tun0

este que você errou, observe os sinalizadores "UH" - faltando "G" significa que é link ponto a ponto diretamente conectado, e NÃO um gateway através do qual você pode rotear dados. Portanto, isso NÃO significa que o tráfego para 10.8.0.5 será enviado via 10.8.0.6, mas apenas 10.8.0.5 é diretamente visível para este computador (que possui o IP 10.8.0.6) usando a interface tun0.

Why is 192.168.100 not going to 10.8.0.1, but instead to 10.8.0.5, and then from 5 to 6, and then i guess 1/32 is supposed to match 6, and it seems like there is a loop.

Espero que as informações acima tenham esclarecido esses equívocos.

I can not ping 10.8.0.5, but I thought that was my ip on the vnetwork. I can not ping 10.8.0.6, however i think that is masked, i get some output "Communication prohibited by filter"

Sim, esses dois endereços são usados internamente pela interface tun0, e você não deve se preocupar com eles (a menos que você esteja executando um analisador de tráfego entre redes etc) - eles não funcionarão como endereços comuns.