conecta-se a um servidor VPN de terceiros, mas não o usa como rota padrão?

Question

Gostaria de me conectar a um servidor VPN de terceiros no Linux (por exemplo, o Debian Jessie), mas, por padrão, ainda uso minha interface eth0 lan como a rota padrão e estou curioso para conseguir isso. Estarei usando o roteamento de políticas ou namespaces de rede ou conjuntos de regras para selecionar quando eu quiser usar a VPN de terceiros.

Mas não está claro para mim o que o openvpn está fazendo nos bastidores que o estabelece para direcionar todo o tráfego através dele. Para superar isso, é tão simples como substituir "redirecionamento-gateway" ao conectar do meu cliente?

    

Answer 1

Aqui está uma solução completa usando grupos de controle (cgroups), que permite o controle de recursos por processo. Um grupo de controle de rede permite isolar a rota VPN, permite facilmente que qualquer processo e seus filhos sejam executados seletivamente dentro dele, permite que usuários não-root tenham acesso a processos em execução dentro do cgroup e usar uma segunda instância do dnsmasq pode isolar o DNS consultas também. Isso pressupõe que você tenha o openvpn, o dnsmasq, o cgroup e a versão 1.6+ do iptables com o suporte cgroup instalado. Isso tudo foi feito no Debian Jessie

O primeiro passo é criar o cgroup e configurar o iptables de acordo. Isso deve ser feito a cada reinicialização, então coloco o seguinte em /etc/rc.local

# enable ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# create cgroup for 3rd party VPN (can change 'vpn' to your name of choice)
mkdir -p /sys/fs/cgroup/net_cls/vpn

# give it an arbitrary id 
echo 11 > /sys/fs/cgroup/net_cls/vpn/net_cls.classid

# grant a non-root user access (change user:group accordingly)
cgcreate -t user:group -a user:group -g net_cls:vpn

# mangle packets in cgroup with a mark
iptables -t mangle -A OUTPUT -m croup --cgroup 11 -j MARK --set-mark 11

# NAT packets in cgroup through VPN tun interface
iptables -t nat -A POSTROUTING -m cgroup --cgroup 11 -o tun0 -j MASQUERADE

# redirect DNS queries to port of second instance, more on this later
iptables -t nat -A OUTPUT -m cgroup --cgroup 11 -p tcp --dport 53 -j REDIRECT --to-ports 5354
iptables -t nat -A OUTPUT -m cgroup --cgroup 11 -p udp --dport 53 -j REDIRECT --to-ports 5354

# create separate routing table
ip rule add fwmark 11 table vpn

# add fallback route that blocks traffic, should the VPN go down
ip route add blackhole default metric 2 table vpn

# disable reverse path filtering for all interfaces
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $i; done

O próximo passo é editar o arquivo de configuração do cliente da VPN de terceiros, por exemplo, /etc/openvpn/client.conf . Deixe o resto da sua configuração inalterada.

# redirect-gateway def1  <--- comment or remove the redirect-gateway line if it exists

# disable automatically configuring routes and run our own routeup.sh script instead
route-noexec
route-up /etc/openvpn/routeup.sh

# run our own update-dnsmasq-conf script on interface up/down; comment out existing up/down lines
up /etc/openvpn/update-dnsmasq-conf
down /etc/openvpn/update-dnsmasq-conf

Agora precisamos criar o script /etc/openvpn/routeup.sh

#!/bin/bash
# add default route through vpn gateway to our separate routing table
/sbin/ip route add default via $route_vpn_gateway dev $dev metric 1 table vpn
exit 0

E agora precisamos criar uma versão modificada do update-resolv-conf, que geralmente vem instalado em / etc / openvpn, para criar a segunda instância do dnsmasq. Eu chamo de / etc / openvpn / update-dnsmasq-conf

#!/bin/bash

[ "$script_type" ] || exit 0

split_into_parts()
{
    part1="$1"
    part2="$2"
    part3="$3"
}

case "$script_type" in
  up)
    NMSRVRS=""
    for optionvarname in ${!foreign_option_*} ; do
        option="${!optionvarname}"
        split_into_parts $option
        if [ "$part1" = "dhcp-option" ] ; then
            if [ "$part2" = "DNS" ] ; then
                NMSRVRS="${NMSRVRS:+$NMSRVRS }--server $part3"
            fi
        fi
    done
    dnsmasq $NMSRVRS --no-hosts --no-resolv --listen-address=127.0.0.1 \
        --port=5354 --bind-interfaces --no-dhcp-interface=* \
        --pid-file=/var/run/dnsmasq/dnsmasq2.pid
    ;;
  down)
    kill -9 $(cat /var/run/dnsmasq/dnsmasq2.pid)
    ;;
esac

E deveria ser isso. Agora você pode iniciar sua conexão vpn e executar processos seletivamente através dessa interface (a opção --sticky garante que os processos filhos sejam executados no mesmo cgroup).

cgexec -g net_cls:vpn --sticky chromium &

NOTA: Para dnsmasq, assegure-se de que /etc/resolv.conf aponte para o host local (servidor de nomes 127.0.0.1). Sua instância principal do dnsmasq processará as consultas em sua rota normal não-VPN e usará (/var/run/dnsmasq/resolv.conf) que normalmente consiste em seu gateway padrão ou em algum DNS público (por exemplo, o 8.8.8.8 do Google). A segunda instância é usada apenas pelo cgroup isolado

    

Answer 2

Eu sugeriria usar as tabelas de rotas. Você pode especificar a rota padrão para todo o tráfego e adicionar as rotas pela VPN conforme necessário.

Nossos amigos no nx.xc têm um bom artigo sobre como fazer isso