O mais provável é que o estabelecimento da VPN altere sua tabela de roteamento, de modo que agora uma resposta à sua posição remota passe pelo servidor VPN. Mas como a sua posição remota está tentando entrar em contato com sua casa, não com o seu servidor VPN, ele descartará as respostas enviadas pelo servidor VPN.
Você pode resolver esse problema estabelecendo simultaneamente à VPN uma rota para sua estação remota que não usa o servidor VPN. Por exemplo, suponha que sua estação remota tenha o endereço IP 1.1.1.1, seu gateway / roteador residencial normal é 192.168.0.1, enquanto sua VPN redireciona tudo através de um servidor VPN em 2.2.2.2. Então, o que você precisa é que a VPN defina a nova rota a seguir:
ip route add 1.1.1.1/32 via 192.168.0.1 dev eth0
O problema é que você deve fazer isso antes de configurar a VPN. A maioria das VPNs que conheço deixa essas rotas extremamente específicas no lugar, portanto, você pode tentar a seguinte ordem de operações:
-
Dê o comando acima;
-
inicie sua VPN;
-
mantenha os dedos cruzados.
Se isso não funcionar (porque a VPN reescreve sua tabela de roteamento completamente), você deve tentar, como sudo:
cmd_VPN; sleep 10; ip route add 1.1.1.1/32 via 192.168.0.1 dev eth0
onde cmd_VPN
é o comando que você usa para configurar sua conexão VPN. A vantagem disso é que a nova rota que você precisa é estabelecida após a VPN aparecer. O sleep 10
é necessário para permitir que a VPN altere a tabela de roteamento. Por 10 segundos, você será eliminado, mas o openssh é perfeitamente capaz de resistir a isso.
Você não pode testar isso de dentro de sua LAN: a rota normal para a LAN local é sempre deixada no lugar por todas as VPNs, então o truque acima funcionará, não importa o que aconteça.