Este é um comportamento esperado de 100%. Para rotear todo o tráfego através de sua conexão VPN, uma rota padrão é adicionada à interface virtual como um destino. Mas isso apresenta um problema - os pacotes de rede usados para transportar a própria conexão VPN também seriam roteados para a interface VPN, criando um tipo de loop de roteamento. Para resolver isso, uma rota de host estático para o servidor VPN é adicionada usando seu gatway de Internet normal como destino. Dessa forma, os pacotes criados pelo OpenVPN poderiam viajar para o servidor OpenVPN pela Internet, enquanto todo o restante é direcionado pelo link da VPN.
Por causa da rota do host, se você tentar SSH para o endereço de Internet do seu servidor VPN, a conexão passará por sua conexão normal com a Internet e você verá seu IP na saída de who
ou last
. Por outro lado, se você for SSH para a outra extremidade do túnel VPN, sua conexão parecerá ter origem no endereço IP atribuído ao final do túnel do cliente.
Por exemplo, é assim que uma interface virtual típica do OpenVPN é configurada:
$ ifconfig
...
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.10.11.9 --> 10.10.11.10 netmask 0xffffffff
open (pid 48658)
A extremidade remota do túnel VPN, neste caso, é 10.10.11.10
. Esta é uma saída ifconfig
no estilo BSD (na verdade, OS X). A saída no Linux é um pouco diferente. E esta é a rota do host correspondente (novamente no formato BSD):
$ netstat -rn
Destination Gateway Flags Refs Use Netif Expire
0/1 10.10.11.9 UGSc 0 0 tun0
default 10.0.1.1 UGSc 22 0 en0
10.0.1/24 link#4 UCS 1 0 en0
10.10.11/24 10.10.11.9 UGSc 0 0 tun0
10.10.11.9 10.10.11.10 UHr 5 0 tun0
yy.yy.yy.yy/32 10.0.1.1 UGSc 1 0 en0
A primeira rota direciona todo o tráfego (exceto o direcionado para a rede local 10.0.1/24
) para a interface tun0
, ou seja, para o OpenVPN. A rota estática para o servidor OpenVPN é aquela na última linha. 10.0.1.1
neste caso é o gateway da Internet.