Por que meu dispositivo TUN não envia o UDP / IP para 192.168.2.x?

Question

Eu configurei um dispositivo TUN no computador host usando este script:

echo 1 > /proc/sys/net/ipv4/ip_forward

#do NAT on packets from our 'local' net
iptables -t nat --flush POSTROUTING
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

#initialise the tun device (tun0)
ip tuntap add dev tun0 mode tun

#give the tun device IP 10.0.0.1
ifconfig tun0 10.0.0.1 netmask 255.255.255.0 up

#disable IPv6 on tun device
sysctl net.ipv6.conf.tun0.disable_ipv6=1

#some firewall rules
iptables -A INPUT -i tun0 -d 127.0.0.0/8 -j DROP

Estou tentando enviar pacotes UDP do meu computador host via Wi-Fi para o meu laptop. O aplicativo conectado ao dispositivo TUN é um aplicativo de servidor que usa um protocolo semelhante ao SOCKS5 para receber pacotes TCP formatados, constrói pacotes UDP / IP e os envia para um endereço especificado com um IP src composto (por algum motivo).

O envio de pacotes UDP pelo TUN com um endereço src de 10.0.0.2 funciona bem. Eu posso obtê-lo até 10.0.0.0/8, alterando a máscara de rede, mas quando eu defino o src (!) Ip do pacote IP que eu quero enviar sobre o dispositivo TUN para 192.168.2.112 (o IP real do meu host) , o dispositivo TUN vai buscá-lo, mas não é recebido no meu laptop. Usar python para enviar um datagrama UDP normalmente funciona como esperado e o src IP correto é lido no meu laptop. O dispositivo TUN envia os pacotes construídos, quando o IP src está no intervalo 10.0.0.0/8, mas não quando é 192. *.

Os iptables estão vazios em ambas as máquinas, antes de usar o script. O que estou perdendo?

/proc/sys/net/ipv4/conf/all/rp_filter: 1
/proc/sys/net/ipv4/conf/default/rp_filter: 1
/proc/sys/net/ipv4/conf/enp0s31f6/rp_filter: 1
/proc/sys/net/ipv4/conf/lo/rp_filter: 0
/proc/sys/net/ipv4/conf/tun0/rp_filter: 1
/proc/sys/net/ipv4/conf/wlp4s0/rp_filter: 1
/proc/sys/net/ipv4/conf/wwp0s20f0u3c2/rp_filter:1

    

Answer 1

Para repetir, seu aplicativo produz um pacote com algum endereço de origem, coloca-o na interface tun, seu computador hospedeiro o encaminha, mascara-o em eth0 e depois da eth0 ele é misteriosamente enviado via WLAN para o seu computador portátil. Isso funciona para 10.0.0.2 como fonte, mas não para 192.168.2.112.

No entanto, na realidade, você não tem uma interface eth0 , mas as interfaces são enp0s31f6 , wlp4s0 e wwp0s20f0u3c2 .

Isso está correto?

Se sim, o provável culpado é que você precisa se mascarar na interface WLAN, em vez de eth0 , e você precisa se mascarar de todos os endereços de origem, não apenas de 10.0.0.0/8. A verdadeira questão é como funcionou para 10.0.0.2 em primeiro lugar, mas isso provavelmente é explicado pela parte de sua configuração que você não nos contou.

Você provavelmente precisará se mascarar na WLAN porque, caso contrário, você teria que definir rotas na outra parte da sua rede.

Ferramentas para depurar: ip route get 1.2.3.4 para verificar rotas, tcpdump -ni wlp4s0 et.c em todas as interfaces que podem ser interessantes para ver onde os pacotes realmente vão.