Início / ubuntu / Perguntas / 1300342
Accepted
bomben
Asked: 2020-12-16 08:20:25 +0800 CST

É correto que um torrent seja baixado via enp3s0 (eth0) mesmo que o tráfego de saída seja restrito a uma VPN no tun0?

  • 772

Modifiquei meu iptables de acordo com a resposta do Musclehead aqui para que eu transmission-daemonpossa enviar tráfego de saída para tun0(que é uma VPN).

(Dica: Meu eth0é chamado enp3s0.)

Agora, se eu adicionar um torrent para baixar e assistir o tráfego com sudo iptables -L -vos únicos números crescentes estão relacionados à INPUTcadeia com enp3s0(que é minha porta ethernet). Os números se somam ao status que recebo da VPN.

Isso significa que eu faço download para meu endereço WAN original em vez do túnel?

Eu acho que quando eu adiciono um torrent, as informações sobre o download serão enviadas tun0e, portanto, a resposta deve voltar nesse intervalo de IP.

Como você pode ver aqui com duas saídas que eu gerei com apenas alguns segundos de diferença, o tráfego aumenta de 1356Mpara 2201Mno enp3s0dispositivo.

 $ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2417  172K f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh
 170K   17M ACCEPT     all  --  tun0   any     anywhere             anywhere            
 330K 1356M ACCEPT     all  --  enp3s0 any     anywhere --THIS LINE anywhere            
  942  134K ACCEPT     all  --  lo     any     anywhere             anywhere            

...          

Chain OUTPUT (policy ACCEPT 483K packets, 269M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   19  6545 ACCEPT     tcp  --  any    enp3s0  anywhere             192.168.100.0/24     tcp spt:9091 owner GID match debian-transmission
    0     0 ACCEPT     udp  --  any    enp3s0  anywhere             192.168.100.0/24     udp spt:9091 owner GID match debian-transmission
 229K  210M ACCEPT     all  --  any    tun0    anywhere             anywhere             owner GID match debian-transmission
  221 57168 ACCEPT     all  --  any    lo      anywhere             anywhere             owner GID match debian-transmission
   92  5372 REJECT     all  --  any    any     anywhere             anywhere             owner GID match debian-transmission reject-with icmp-port-unreachable

...

Segunda saída segundos depois:

$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2431  173K f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh
 170K   17M ACCEPT     all  --  tun0   any     anywhere             anywhere            
 384K 2201M ACCEPT     all  --  enp3s0 any     anywhere --THIS LINE anywhere            
  942  134K ACCEPT     all  --  lo     any     anywhere             anywhere            

...          

Chain OUTPUT (policy ACCEPT 536K packets, 272M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   19  6545 ACCEPT     tcp  --  any    enp3s0  anywhere             192.168.100.0/24     tcp spt:9091 owner GID match debian-transmission
    0     0 ACCEPT     udp  --  any    enp3s0  anywhere             192.168.100.0/24     udp spt:9091 owner GID match debian-transmission
 229K  210M ACCEPT     all  --  any    tun0    anywhere             anywhere             owner GID match debian-transmission
  221 57168 ACCEPT     all  --  any    lo      anywhere             anywhere             owner GID match debian-transmission
   92  5372 REJECT     all  --  any    any     anywhere             anywhere             owner GID match debian-transmission reject-with icmp-port-unreachable

...

Também adicionarei minhas saídas da tabela de roteamento para melhor compreensão:

 $ ip route show table local
broadcast 10.8.8.0 dev tun0  proto kernel  scope link  src 10.8.8.5 
local 10.8.8.5 dev tun0  proto kernel  scope host  src 10.8.8.5 
broadcast 10.8.8.255 dev tun0  proto kernel  scope link  src 10.8.8.5 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.100.0 dev enp3s0  proto kernel  scope link  src 192.168.100.91 
local 192.168.100.91 dev enp3s0  proto kernel  scope host  src 192.168.100.91 
broadcast 192.168.100.255 dev enp3s0  proto kernel  scope link  src 192.168.100.91
networking iptables vpn transmission

1 respostas

  1. Best Answer

    Verifiquei com os caras da empresa VPN e eles analisaram a seguinte saída. Eles disseram que ambos os IPs (eu os alterei) são IPs de VPN, então minha VPN não está vazando, mas conectada corretamente. E também está transferindo algum sshtráfego, é claro, porque estou logado no PC com ele.

    Mas eles acharam estranho que esse tráfego tun0não seja visível na iptablecadeia que postei na minha pergunta. Veja abaixo.

    Com relação ao fato de o tráfego ser via enp3s0, isso está correto, pois o tráfego de tun0é encaminhado (criptografado) para a porta ethernet.

     $ sudo tcpdump -i enp3s0 not src 84.17.47.59
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:35:14.533573 IP 192.168.100.91.ssh > 192.168.100.210.59004: Flags [P.], seq 835793677:835793865, ack 3278619125, win 318, options [nop,nop,TS val 19307620 ecr 4023390051], length 188
10:35:14.534084 IP 192.168.100.91.47524 > 203.179.83.129.openvpn: UDP, length 164
10:35:14.534399 IP 206.189.83.129.openvpn > 192.168.100.91.47524: UDP, length 468

    Além disso, minhas regras de firewall ufwestão ausentes do INPUT, FORWARDe das OUTPUTcadeias, bem como de outras cadeias específicas do ufw. Como esses:

      199 13931 ufw-after-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-after-logging-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-reject-output  all  --  any    any     anywhere             anywhere            
  199 13931 ufw-track-output  all  --  any    any     anywhere             anywhere

    Depois que removi o pacote e as configurações, eliminei todas as cadeias específicas iptablese configurei tudo do zero, funcionou. O tráfego de entrada para tun0agora também é visível.

    Para responder à pergunta: Sim, o tráfego de saída será eventualmente transferido para ethdepois de ser encapsulado no tun0. Ambos os valores devem somar.

    • 0

relate perguntas