Eu tenho um PC (kernel 3.2.0-23-generic ) que foi 192.168.1.2/24configurado para fazer eth0interface e também usa 192.168.1.1e 192.168.1.2endereços para tun0interface:
root@T42:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:16:41:54:01:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 scope global eth0
inet6 fe80::216:41ff:fe54:193/64 scope link
valid_lft forever preferred_lft forever
3: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: irda0: <NOARP> mtu 2048 qdisc noop state DOWN qlen 8
link/irda 00:00:00:00 brd ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:13:ce:8b:99:3e brd ff:ff:ff:ff:ff:ff
inet 10.30.51.53/24 brd 10.30.51.255 scope global eth1
inet6 fe80::213:ceff:fe8b:993e/64 scope link
valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast state DOWN qlen 100
link/none
inet 192.168.1.1 peer 192.168.1.2/32 scope global tun0
root@T42:~# ip route show dev eth0
192.168.1.0/24 proto kernel scope link src 192.168.1.2
root@T42:~#
Como visto acima, tun0está desativado administrativamente ( ip link set dev tun0 down). Agora, quando recebo solicitações de ARP 192.168.1.2, o PC não responde a essas solicitações:
root@T42:~# tcpdump -nei eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:30:34.875427 00:1a:e2:ae:cb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.2 tell 192.168.1.1, length 46
15:30:36.875268 00:1a:e2:ae:cb:b7 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.1.2 tell 192.168.1.1, length 46
15:30:39.138651 00:1a:e2:ae:cb:b7 > 00:1a:e2:ae:cb:b7, ethertype Loopback (0x9000), length 60:
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
root@T42:~#
Somente depois de excluir a tun0interface ( ip link del dev tun0), o PC responderá à solicitação ARP para 192.168.1.2a eth0interface.
A tabela de roteamento é exatamente igual antes e depois ip link del dev tun0:
root@T42:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.30.51.254 0.0.0.0 UG 0 0 0 eth1
10.30.51.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth0
root@T42:~# ip link del dev tun0
root@T42:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.30.51.254 0.0.0.0 UG 0 0 0 eth1
10.30.51.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 192.168.1.2 255.255.255.0 UG 0 0 0 eth0
root@T42:~#
A entrada de roteamento abaixo já foi removida com o ip link set dev tun0 downcomando:
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
No entanto, embora as tabelas de roteamento sejam exatamente iguais antes e depois do ip link del dev tun0comando, as decisões de roteamento reais que o kernel tomará não são:
T42:~# ip route get 192.168.1.1
local 192.168.1.1 dev lo src 192.168.1.1
cache <local>
T42:~# ip link del dev tun0
T42:~# ip route get 192.168.1.1
192.168.1.1 dev eth0 src 192.168.1.2
cache ipid 0x8390
T42:~#
Esse é um comportamento esperado? Por que o kernel ignora a tabela de roteamento?
fonte
tun0interface está desabilitada, mas presente. Veja a saída dosip route getcomandos no meu post inicial atualizado. No entanto, por que o kernel se comporta assim?Respostas:
Sua tabela de roteamento não está sendo ignorada, exatamente. Ele está sendo substituído por uma tabela de roteamento de prioridade mais alta.
O que está acontecendo
A tabela de roteamento que você vê quando digita
ip route shownão é a única tabela de roteamento usada pelo kernel. De fato, há três tabelas de roteamento por padrão e elas são pesquisadas na ordem mostrada peloip rulecomando:A tabela com a qual você está mais familiarizado é
main, mas a tabela de roteamento de prioridade mais alta élocal. Esta tabela é gerenciada pelo kernel para acompanhar as rotas locais e de broadcast: em outras palavras, alocaltabela informa ao kernel como rotear para os endereços de suas próprias interfaces. Parece algo como isto:Confira essa referência de linha
tun0. Isso é o que está causando seus resultados estranhosroute get. Diz 192.168.1.1 é um endereço local, o que significa que, se queremos enviar uma resposta ARP para 192.168.1.1, é fácil; nós enviamos para nós mesmos. E como encontramos uma rota nalocaltabela, paramos de procurar uma rota e não nos incomodamos em verificar as tabelasmainoudefault.Por que várias tabelas?
No mínimo, é bom poder digitar
ip routee não ver todas as rotas "óbvias" bagunçando a tela (tente digitarroute printem uma máquina Windows). Ele também pode servir como uma proteção mínima contra configurações incorretas: mesmo que a tabela de roteamento principal tenha se misturado, o kernel ainda sabe como se comunicar.(Por que manter as rotas locais em primeiro lugar? Portanto, o kernel pode usar o mesmo código de pesquisa para endereços locais e para todo o resto. Isso torna as coisas mais simples internamente.)
Há outras coisas interessantes que você pode fazer com esse esquema de várias tabelas. Em particular, você pode adicionar suas próprias tabelas e especificar regras para quando elas são pesquisadas. Isso é chamado de "roteamento de política" e, se você quiser rotear um pacote com base no endereço de origem , é assim que se faz no Linux.
Se você estiver fazendo coisas especialmente complicadas ou experimentais, poderá adicionar ou remover
localrotas especificandotable localnoip routecomando. A menos que você saiba o que está fazendo, é provável que confunda o kernel. E, é claro, o kernel continuará adicionando e removendo suas próprias rotas, então você deve observar para garantir que o seu não seja sobrescrito.Por fim, se você deseja ver todas as tabelas de roteamento de uma vez:
Para mais informações, consulte a
ip-rule(8)página de manual ou os documentos do iproute2 . Você também pode tentar o HOWTO de roteamento avançado e controle de tráfego para obter alguns exemplos do que você pode fazer.fonte
ip link set dev tun0 downalocal 192.168.1.1 dev tun0 proto kernel scope host src 192.168.1.1regra ainda estava presente nalocaltabela de roteamento. Uma vez executada,ip link del dev tun0a regra mencionada foi removida. Ainda assim, estou certo de que todos os kernels modernos do Linux (2.6.x, 3.x, 4.x) usam RPDB para pesquisas de rotas e, portanto, várias tabelas?ip(8): "ipfoi escrito por Alexey N. Kuznetsof e adicionado no Linux 2.2."Sua configuração de filtragem de caminho reverso provavelmente é o problema. RFC3704 - seção 2.4
Nas distribuições Enterprise Linux (RHEL, CentOS, Scientific Linux, et al), a melhor maneira provável de resolver isso é modificando
/etc/sysctl.confcomrp_filter = 2Quando o RHEL tem vários IPs configurados, apenas um é acessível a partir de uma rede remota. Ou por que o RHEL ignora pacotes quando a rota para o tráfego de saída difere da rota do tráfego de entrada?
fonte
for rp_filter_file in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > "$rp_filter_file"; doneo kernel, aeth0interface não será usada para rotear pacotes para 192.168.1.1. Somente quando eu excluo atun0interface comip link del dev tun0o kernel começa a usar aeth0interface.