Eu tenho esse cliente VPN que toca a tabela de roteamento e fica observando para sair se for tocado. É o tipo de configuração necessária para um endpoint, como um laptop.
Quero usar um PC pequeno como endpoint VPN e rotear através dele para outras máquinas na minha LAN (192.168.0.0/24).
Como não consigo tocar na tabela de roteamento e todos os pacotes são forçados através do tun0dispositivo VPN, pensei iptablesque poderia me ajudar a fazer o POSTROUTE de pacotes para a rede 192.168.0.0 de volta ao eth1dispositivo.
Não tenho certeza, porém, como isso funcionaria, porque assim que sair, eth1deverá resolver o IPtoMAC porque já está na rede de destino, e não sei se o pacote já foi resolvido ou não acontecerá até chegar o iface.
Alguma dica?
Responder1
Como você não forneceu mais informações, não sei qual a melhor resposta.
Então aqui vai minha tentativa de lhe dar algumas instruções, ignorando propositalmente que você não pode modificar sua tabela de roteamento (você entenderá o porquê lendo minha sugestão):
Dependendo do cliente VPN eondeele se conecta ao FIB (forward information base) do kernel, você pode ter alguma sorte porque o monitoramento do FIB, ou, usando sua tabela de roteamento de expressão, pela VPN só acontece para as tabelas de regras locale . mainVocê 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 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 dar-lhe preferência na tabela de consulta de regras. Por exemplo (inventei algo para lhe dar uma vantagem inicial), vamos adicionar uma nova regra com maior preferência do que mainpara 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 postagem), você veria as três tabelas de regras padrão local, maine default, das quais você normalmente só vê a maintabela ao invocar, netstat -rnpor exemplo.
Agora queremos preencher as entradas FIB na tabela de pesquisa 888 com novas entradas de roteamento:
ip route add default via 10.37.129.4 dev eth2 table 888
Vamos ver como ficam nossas entradas de roteamento na tabela 888:
ip route show table 888
default via 10.37.129.4 dev eth2
Acho que você entendeu. Agora, com relação à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
Observe que usando a arquitetura iproute2 você pode basicamente filtrar e modificar praticamente qualquer entrada FIB; entradas de regras podem até ser feitas com base em fwmarks e/ou classificadores u32, como a seguir (exemplo retirado dolivro de roteamento de políticas):
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 dêem errado nas entradas das tabelas de regras, muitos anos atrás eu preparei um pequeno trecho do 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 iproute2existência de , ainda poucas pessoas parecem saber que existe um universo além do clássico."quebrado"ferramentas como ifconfigou netstat.