Eu tenho duas interfaces na máquina do servidor. A saída de ip routeé a próxima:
default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100
e ip addressé o próximo (os MACs estão ocultos):
...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::85:5fff:fe98:6cb7/64 scope link
valid_lft forever preferred_lft forever
O /proc/sys/net/ipv4/ip_forwardvalor é 1; firewall está desabilitado.
O que eu quero é acessar192.168.100.1de10.8.0.100. Acessar o servidor web (que está escutando todas as portas desta máquina) curl --interface 10.8.0.100 http://10.8.0.1funciona bem. Mas curl --interface 10.8.0.100 http://192.168.100.201a saída é Network unreachable.
Curl inicia um handshake tcp e envia o pacote para10.8.0.100interface. O pacote então chega à máquina do servidor em10.8.0.1. O servidor verifica o destino do pacote e vê que ele está192.168.100.201. Então ele olha para a tabela de roteamento e vê isso192.168.100.201é local. Agora a resposta está voltando. O remetente era10.8.0.100. Olhando para a tabela de roteamento, descobrimos que ela é acessível por meio de tap0, que é local. Então agora ele avança tap0e atinge 10.8.0.100.
Mas na verdade -não é. É porque minha linha de pensamento está errada? Achei que as informações fornecidas pela tabela descrita são suficientes para determinar como encaminhar os pacotes. Isso está realmente incompleto?
Responder1
Em primeiro lugar, fornecer endereço IP e interface com o parâmetro -I para pingnão são sinônimos. Primeiro diz qual source IPescolher. Ele irá roteá-lo de acordo com o fluxo da rede, incluindo endereços locais e tabelas de roteamento. O segundo diz para escolher diretamente a interface para a qual enviar o pacote (e escolherá o primeiro IP atribuído como origem).
Em seguida, o que você está fazendo não tem nada a ver com encaminhamento de pacotes. Encaminhamento significa que o pacote deve realmente chegar de "fora". Como você está gerando um pacote deste host, não há encaminhamento envolvido. É um pacote gerado localmente. Como o seu IP de destino é um dos endereços atribuídos localmente quando você não está forçando o ping a enviar pacotes para uma interface específica "externa" (com -I interfaceopção), o kernel processará esse fluxo de pacotes internamente. Ele simplesmente não tentará enviá-lo para uma interface real, pois seu destino "já está aqui". Então é isso que acontece e por que funciona em um caso e não em outro.
PS: Confira também a -ropção da pingferramenta caso você saiba o que está fazendo e ambas as interfaces estejam anexadas a um mesmo domínio de broadcast (duvido disso com a interface TAP).
Responder2
O problema foi com o mal-entendido da diferença entre --interface IPe --interface dev. O primeiro usa tabela de roteamento:
com --interface 10.8.0.100o pacote não será encaminhado para tap0a interface (à qual este ip pertence). Em vez disso, de acordo com a tabela de roteamento, ele será encaminhado para 192.168.100.58(a interface LAN). Então a rota é 10.8.0.100 -> 192.168.100.58 -> 192.168.100.201. Mesmo o fato de o SYN ter sido entregue, o servidor estranhamente não responderá com SYN-ACK - esse é o motivo da falha do curl.
Usando --interface tap0, por exemplo, o endereço da camada de link, funcionará conforme o esperado 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201:. O SYN-ACK será devolvido pela mesma rota.