Roteamento através do iptables

Question

Eu tenho esse cliente vpn que toca a tabela de roteamento e, em seguida, continua assistindo para sair se ele for tocado.
É o tipo de configuração necessária para um endpoint, como um laptop.

Eu quero usar um pequeno pc como ponto de extremidade vpn e direcioná-lo para outras máquinas na minha LAN (192.168.0.0/24).
Como eu não posso tocar na tabela de roteamento e todos os pacotes são forçados através do dispositivo vpns tun0, eu estava pensando que o iptables poderia me ajudar a POSTROUVER os pacotes para a rede 192.168.0.0 de volta ao dispositivo eth1. Não tenho certeza, porém, como isso funcionaria, porque uma vez que saia da eth1 ela deve resolver o IPtoMAC porque ele já está na rede de destino, e eu não sei se o pacote já resolveu ou não vai acontecer até que alcança o iface.
Alguma dica?

    

Answer 1

Como você não forneceu mais informações, não sei como responder melhor.

Então, aqui vai minha tentativa de dar a você algumas direções, ignorando deliberadamente que você não pode modificar sua tabela de roteamento (você entenderá porque ler minha sugestão):

Dependendo do cliente VPN e onde ele conecta ao FIB (base de informações de encaminhamento) do kernel, você pode ter alguma sorte em monitorar o FIB, ou, usando sua expressão routing tabela, pela VPN só acontece para as tabelas de regra local e main . Você pode verificar suas regras de roteamento usando

ip rule show

Para cada uma das strings atrás da tag "lookup" (que são as entradas da tabela de regras), você pode consultar as informações de roteamento correspondentes a partir do FIB, usando

ip route show table <name>

Com um pouco de sorte, você pode tentar construir uma regra que corresponda aos seus requisitos e dê preferência a ela na tabela de consulta de regras. Por exemplo (criei algo para lhe dar um bom começo), vamos adicionar uma nova regra com maior preferência do que main a determinados fluxos:

ip rule add from 192.168.1.0/24 to 10.10.212.1/30 iif eth0 oif eth2 lookup 888 pref 12000
ip rule show
   0:   from all lookup local 
   12000:   from 192.168.1.0/24 to 10.10.212.1/30 iif eth0 oif eth2 lookup 888 
   32766:   from all lookup main 
   32767:   from all lookup default 

Em um sistema Linux padrão (Ubuntu, no caso desta publicação), você verá as três tabelas de regras padrão local , main e default , das quais normalmente você vê apenas o main tabela ao invocar netstat -rn por exemplo.

Agora queremos preencher as entradas FIB na tabela de consulta 888 com novas entradas de roteamento:

ip route add default via 10.37.129.4 dev eth2 table 888

Vamos ver como nossas entradas de roteamento na tabela 888 se parecem:

ip route show table 888
  default via 10.37.129.4 dev eth2

Eu acho que você entendeu a ideia. Agora, no que diz respeito às suas necessidades específicas de roteamento, não está claro o que exatamente você está tentando alcançar. Certifique-se de liberar o cache de roteamento ao brincar com tabelas de regras:

ip route flush cache

Note que usando a arquitetura iproute2 você pode basicamente filtrar e modificar virtualmente qualquer entrada FIB; entradas de regra podem ser feitas com base em fwmarks e / ou classificadores u32, como segue (exemplo retirado do roteamento de políticas livro ):

tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 \
    match ip src 10.1.1.0/24 classid :1
ip rule add fwmark 1 table 1 prio 15000 realms 3/4
ip route add default via 192.168.1.1 table 1 src 192.168.1.254
ip route flush cache

Para que as coisas fiquem descontroladas nas entradas das tabelas de regras, há muitos anos eu tinha preparado um pequeno snippet bash para colocar meu sistema de volta ao estado original das regras de roteamento:

: ${KEEP:="local main default"}
while read prio rule; do
     continue=0
     for keep in ${KEEP}; do
         if [ "${rule//lookup ${keep}/}" != "${rule}" ]; then
             continue=1
         fi
     done
     if [ ${continue} -eq 0 ]; then
         ip rule del prio ${prio%%:*} ${rule//all/0/0}
     fi
done < <(ip rule show)

Surpreendentemente, parece que depois de mais de 10 anos de existência de iproute2 , ainda assim poucas pessoas parecem saber que existe um universo além das ferramentas clássicas "quebradas" como ifconfig ou netstat .