netflix stall via linux iptables nat, erros de soma de verificação tcp (com solução alternativa)

Navegue suas respostas
2

Estou tentando rastrear esse problema há vários dias. Eu ainda não consegui descobrir o que está acontecendo, ou como corrigi-lo corretamente, mas eu tenho uma solução alternativa.

Resumo do problema

Netflix trava ao assistir em qualquer máquina na minha rede interna, acessando a internet através de uma caixa linux atuando como roteador nat e adsl. O Netflix funciona bem ao assistir diretamente na caixa do Linux conectada à Internet.

Detalhes

Minha caixa do servidor linux, "chimpanzé", é conectada à rede interna da casa via um nic (eth0) e ao modem adsl via outro nic (eth3). Ele está executando o pppoe para o modem adsl, e o link da internet funciona bem, com 15Mb / s para baixo e 1Mb / s para cima. O Chimp está executando o debian jessie 8.6.0 (kernel 3.16.0-4-amd64), apesar de ter sido debian wheezy 7.1.0 até que eu o atualizei como parte da investigação deste problema.

Outros computadores na rede doméstica acessam a Internet via regras iptables no chimpanzé que usam o mascaramento (eu também tentei snat) para encaminhar de eth0 para ppp0.

Assistir o Netflix no próprio chimpanzé funciona bem. Assistir BBC iplayer (estou no Reino Unido) em qualquer computador na rede funciona bem. Assistir ao netflix em qualquer computador que não seja o chimp stalls, embora eu acredite que costumava funcionar no início de novembro de 2016. Os computadores que mostram o problema incluem um par de macs (safari) e outra jessie box da Debian (chrome).

Olhando para a figura "bytes RX" de "/ sbin / ifconfig ppp0" mostrou que estava baixando por alguns segundos, então praticamente parou.

Eu encontrei algo na internet que dizia que minhas regras iptables deveriam estar descartando pacotes que marcam marcas como "inválidas". Adicionei regras para descartar pacotes inválidos, mas isso não melhorou a situação. Eu tentei fazer o log também, e vi que eu estava pegando um monte desses pacotes de volta do netflix, mas apenas quando assistia em uma máquina diferente do chimpanzé.

Eu tentei "echo 255 > / proc / sys / net / netfilter / nf_conntrack_log_invalid" e vi que os pacotes inválidos eram devidos a checksums TCP inválidos: 

Dec 30 20:16:40 chimp kernel: [185803.594182] nf_ct_tcp: bad TCP checksum IN= OUT= SRC=78.146.119.61 DST=<my_public_ip_address> LEN=1500 TOS=0x00 PREC=0x00 TTL=59 ID=0 PROTO=TCP SPT=443 DPT=56711 SEQ=92431783 ACK=3940029300 WINDOW=2050 RES=0x00 ACK URGP=0 OPT (0101080AC67B959B27E48AC7) 
Dec 30 20:16:40 chimp kernel: [185803.594200] input invalid: IN=ppp0 OUT= MAC= SRC=78.146.119.61 DST=<my_public_ip_address> LEN=1500 TOS=0x00 PREC=0x00 TTL=59 ID=0 PROTO=TCP SPT=443 DPT=56711 WINDOW=2050 RES=0x00 ACK URGP=0

(O prefixo "input invalid" mostra que ele vem da minha regra iptables para registrar um pacote inválido na cadeia de entrada antes de descartá-lo.)

Eu tentei desabilitar a verificação de checksum em conntrack com "sysctl -w net.netfilter.nf_conntrack_checksum = 0". Isso fez com que as linhas de log acima parassem, mas não corrigiram o problema.

Então, meu melhor palpite é:

  • Alguma coisa está desmembrada a partir de mim, enviando-me um fluxo do NetFlix, por isso obtenho erros de soma de verificação do TCP.
  • Ao assistir o netflix no chimpanzé, um pacote errôneo chega na camada tcp do chimpanzé e é capaz de se recuperar, talvez solicitando o pacote novamente.
  • Ao assistir em outra máquina, mesmo com a verificação da soma de verificação TCP desativada, o conntrack não associará o pacote à conexão para que nunca chegue à camada tcp da máquina cliente. A camada tcp do cliente recupera de uma forma mais drástica, talvez com um tempo limite maior ou com erros em toda a conexão.

Questão atual finalmente

Isso faz algum sentido para quem sabe mais sobre tcp, conntrack e nat do que eu? Ou há algo que eu possa estar fazendo errado?

Solução alternativa

Eu fiquei sem saber investigar isso. Mas talvez essa solução alternativa seja útil para qualquer outra pessoa que encontre o mesmo problema.

A solução é configurar toda a rede da casa usando um proxy http / https em execução no chimpanzé (a máquina conectada à Internet). Eu usei wpad.dat no chimp para autoconfigurar as outras máquinas e configurá-lo apenas para proxy * .netflix.com e * .nflxvideo.net.

Cada máquina cliente precisa de um pouco de configuração para usar a descoberta automática de proxy, apenas uma única caixa de seleção nas configurações de rede no mac e no gnome (e eu acho o mesmo no Windows).

Saída de iptables -L -xvn 

Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID LOG flags 0 level 4 prefix "input invalid: "
       0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
     347    19177 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
     259    33840 ACCEPT     all  --  eth+   *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:1024:5999
       0        0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:6010:65535
       0        0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:123
       0        0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:500
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:143
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:993
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02
       0        0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
       0        0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID LOG flags 0 level 4 prefix "forward invalid: "
       0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
       0        0 ACCEPT     tcp  --  eth0   ppp+    0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02
       0        0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
       0        0 ACCEPT     udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp spt:53
       0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 639 packets, 103120 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Saída do iptables-save 

# Generated by iptables-save v1.4.21 on Mon Jan  2 13:24:22 2017
*nat
:PREROUTING ACCEPT [115:43215]
:INPUT ACCEPT [43:4146]
:OUTPUT ACCEPT [2:606]
:POSTROUTING ACCEPT [2:606]
-A POSTROUTING -o ppp+ -j MASQUERADE
COMMIT
# Completed on Mon Jan  2 13:24:22 2017
# Generated by iptables-save v1.4.21 on Mon Jan  2 13:24:22 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [692:108312]
-A INPUT -m state --state INVALID -j LOG --log-prefix "input invalid: "
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth+ -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --dport 1024:5999 -j ACCEPT
-A INPUT -p udp -m udp --dport 6010:65535 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -j DROP
-A FORWARD -i lo -j ACCEPT
-A FORWARD -m state --state INVALID -j LOG --log-prefix "forward invalid: "
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i eth0 -o ppp+ -p tcp -j ACCEPT
-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A FORWARD -i eth0 -p udp -m udp --dport 53 -j ACCEPT
-A FORWARD -o eth0 -p udp -m udp --sport 53 -j ACCEPT
-A FORWARD -j DROP
COMMIT
# Completed on Mon Jan  2 13:24:22 2017
    
por tpr 31.12.2016 / 14:48

0 respostas

Tags

O Windows 10 não hibernará Controle Remoto do Apple iPad