Existem duas abordagens para isso, baseadas em roteamento e baseadas em firewall.
Abordagem de roteamento
A tabela de roteamento típica de uma máquina não conectada a uma VPN é semelhante a esta:
10.23.11.0/24 dev eth0
default via 10.23.11.1
A primeira rota é para hosts na LAN, e a segunda rota envia tudo para o gateway padrão. Quando conectado a uma VPN, a tabela de roteamento se parece com algo assim (onde 1.2.3.4 é o IP público do servidor VPN e 10.8.0.1 é o IP privado do servidor VPN):
10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1
A primeira rota é a mesma e a terceira rota é o que envia tudo pela VPN. Observe a segunda regra, no entanto: ele diz que para alcançar os pacotes IP públicos do servidor VPN deve ser enviado através do gateway padrão. Isso é para que os pacotes sintonizados criados pelo cliente VPN realmente alcancem o servidor; se essa rota não estiver no lugar, os pacotes criados pelo cliente VPN serão enviados pela VPN novamente e nunca chegarão ao servidor.
Agora, se a terceira rota for removida, os pacotes destinados a qualquer lugar na Internet, exceto o servidor VPN, não terão uma rota correspondente e, portanto, o host nunca os enviará para fora. Portanto, queremos que a tabela de roteamento tenha essa aparência quando a VPN não estiver conectada:
10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
Os hosts na LAN ainda podem ser acessados e o servidor VPN ainda pode ser acessado (já que precisamos iniciar a VPN), mas o restante não será encaminhado. Obter essa configuração pode ser um pouco complicado, especialmente se você estiver usando DHCP. Uma configuração estática no Debian envolveria o seguinte em /etc/network/interfaces :
auto eth0
iface eth0 inet static
address 10.23.11.10
netmask 255.255.255.0
up ip route add 1.2.3.4 via 10.23.11.1
Observe que não há instrução gateway , pois é isso que instala a rota padrão.
A desvantagem dessa abordagem é que o tráfego não VPN para o servidor VPN ainda é permitido sem criptografia. Se você executar outros serviços no servidor VPN e precisar garantir que eles estejam protegidos, será necessário usar a abordagem de firewall.
Editar : @JamesRyan sugere que essa abordagem é frágil porque uma rota padrão pode ser adicionada automaticamente ou acidentalmente. Outra abordagem é adicionar uma rota blackhole, que envia o tráfego para algum lugar que não o encaminha mais. Isso não funcionará com uma rota padrão automaticamente adicionada, pois ela já usa a métrica de prioridade mais alta 0. A rota padrão ainda precisa ser removida, mas algo como o seguinte pode ser adicionado.
default via 127.255.255.255
Abordagem de firewall
A ideia aqui é bloquear todo o tráfego de saída na interface física, além do tráfego de tunnells criado pelo cliente VPN e do tráfego destinado à LAN. O tráfego para permitir a VPN depende do protocolo que está sendo usado. O PPTP usa a porta TCP 1723 como um canal de controle e GRE como o túnel real. O OpenVPN usa a porta UDP 1194. As regras do firewall se parecem com isso:
iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT
A primeira regra aceita tráfego para a LAN. A segunda e terceira regras aceitam tráfego de VPN para o servidor VPN. A quarta regra rejeita todo o outro tráfego que sai da interface física.
A outra coisa que você pode precisar aceitar é o DNS se você usar um servidor DNS que não esteja na LAN, porque o cliente VPN provavelmente precisará fazer uma pesquisa de DNS para encontrar o servidor VPN. A regra a seguir inserida antes do REJECT permitiria o tráfego DNS para o serviço de DNS público do Google.
iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT