No momento, estamos tentando rotear todos os pacotes da sub-rede da nossa vlan convidada (eth1.251) através de um túnel wireguard para a Internet. Para conseguir isso, estamos usando roteamento baseado em política com uma regra para usar a tabela de roteamento 10 quando o tráfego vem de nossa sub-rede convidada:
32765: from 10.251.0.0/16 lookup 10
Na tabela de roteamento 10 estamos criando uma rota padrão para nossa interface de túnel:
default dev wg1 scope link
Todos os nossos clientes em nossa rede de convidados conseguem acessar a Internet através do túnel wireguard que é esperado, porém o cliente não consegue acessar o gateway da rede de convidados (10.251.0.1). TCPDump mostra que a resposta de eco ICMP é roteada de volta através da wg1interface para o endpoint do nosso túnel, o que obviamente não é pretendido. Uma solução rápida para isso é adicionar a rota do link de escopo para a eth1.251interface vlan convidada ao roteamento table 10:
default dev wg1 scope link
10.251.0.0/16 dev eth1.251 proto kernel scope link
Agora o cliente pode acessar a interface do roteador e atender.
Neste roteador há outra interface eth1 com a sub-rede 192.168.0.1/16. Quando excluímos nossa 10.251.0.0/16rota recém-adicionada, table 10não podemos 10.251.0.1mais acessar a interface do roteador, no entanto, estamosainda é capaz de alcançara interface 192.168.0.1de um cliente na 10.251.0.0/16sub-rede. Os clientes (por exemplo 192.168.0.2) atrás do roteador na 192.168.0.0/16sub-rede não podem ser recarregados 10.251.0.0/16.
Pergunta principal: Por que podemos alcançar o 192.168.0.1IP da interface em nosso roteador sem uma entrada explícita na tabela de roteamento, mas não o 10.251.0.1IP da interface de nossos clientes na 10.251.0.0/16sub-rede convidada?
Aqui está uma visão geral da estrutura da rede. Acho que isso ajuda a entender nossa configuração.
Responder1
Não há uma explicação geral, é apenas uma questão de acompanhar o que acontece nas configurações de roteamento.
10.251.0.1 é um endereço de roteador local e parte de 10.251.0.0/16.
Ao receber um pacote para umlocalendereço, o roteador corresponde aolocaltabela usando a primeira ip rulecom menor preferência: 0, antes da regra da tabela 10, e correspondências. Lembre-se de que as tabelas de roteamento correspondemdestinos, embora normalmente as regras personalizadas sejam configuradas para corresponderfontes.
Quando o roteador responde, desta vez a tabela local não corresponde: 10.251.0.2 não é localdestino. A próxima regra é verificada e corresponde from 10.251.0.0/16, consulta a tabela 10 e o pacote passawg1.
Para 192.168.0.1, o recebimento do pacote é exatamente como antes com olocalmesa. Agora a resposta não corresponde à regra adicional, e a tabela de roteamento principal se aplica: funciona normalmente: um sistema Linux responderá a partir de qualquer um de seus IPs.
Novamente, para 192.168.0.2: não é umlocalIP, então não corresponde aolocaltabela, mas a consulta corresponde à regra adicionada: os pacotes são perdidos atravéswg1.
Portanto, copiar uma parte da tabela de roteamento principal para a tabela extra para evitar efeitos colaterais ajuda.
Muito disso pode ser testado com ip route geta sintaxe correta, desde que não haja marcas envolvidas:
Sem a entrada adicional na tabela 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
RTNETLINK answers: Invalid cross-device link
# sysctl -w net.ipv4.conf.eth1/251.rp_filter=2 #relax reverse path filtering
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.1
local 192.168.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.2 iif eth1.251 192.168.0.2
192.168.0.2 from 10.251.0.2 dev wg1 table 10
cache iif eth1.251
rota de resposta:
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev wg1 table 10 uid 0
cache
# ip route get from 192.168.0.1 10.251.0.2
10.251.0.2 from 192.168.0.1 dev eth1.251 uid 0
cache
Ao adicionar a entrada na tabela 10:
# ip route get from 10.251.0.2 iif eth1.251 10.251.0.1 #even with strict reverse path filtering, since the reverse route is correct
local 10.251.0.1 from 10.251.0.2 dev lo table local
cache <local> iif eth1.251
# ip route get from 10.251.0.1 10.251.0.2
10.251.0.2 from 10.251.0.1 dev eth1.251 table 10 uid 0
cache