netflix stall über linux iptables nat, tcp-prüfsummenfehler (mit workaround)

Ich habe versucht, dieses Problem seit mehreren Tagen aufzuspüren. Ich habe immer noch nicht herausgefunden, was los ist oder wie man es richtig repariert, aber ich habe eine Problemumgehung.

Problemzusammenfassung

Netflix bleibt stehen, wenn ich auf einem beliebigen Rechner in meinem internen Netzwerk zuschaue und über eine Linux-Box, die als natürlicher Router und ADSL fungiert, auf das Internet zugreift. Netflix funktioniert gut, wenn Sie direkt auf die mit dem Internet verbundene Linux-Box schauen.

Einzelheiten

Meine Linux-Server-Box "Schimpanse" ist über ein nic (eth0) mit dem hausinternen Netzwerk und über ein anderes nic (eth3) mit dem ADSL-Modem verbunden. Es läuft pppoe auf das ADSL-Modem, und die Internetverbindung funktioniert gut, mit 15 MBit / s und 1 MBit / s. Chimp führt debian jessie 8.6.0 (Kernel 3.16.0-4-amd64) aus, obwohl Debian Wheezy 7.1.0 war, bis ich es im Rahmen der Untersuchung dieses Problems aufgerüstet habe.

Andere Computer im Hausnetzwerk greifen auf das Internet über iptables-Regeln für Schimpanse zu, die Masquerading verwenden (ich habe auch versucht, snat), um von eth0 nach ppp0 weiterzuleiten.

Netflix auf Schimpanse selbst zu sehen funktioniert gut. Das Ansehen von BBC iplayer (ich bin in Großbritannien) auf jedem Computer im Netzwerk funktioniert einwandfrei. Ich beobachte Netflix auf einem anderen Computer als Schimpansenständen, obwohl ich glaube, dass es ungefähr Anfang November 2016 funktioniert hat. Zu den Computern, die das Problem zeigen, gehören ein paar Macs (Safari) sowie eine weitere Debian-Jessie-Box (Chrome).

Ein Blick auf die "RX-Bytes" -Zahl aus "/ sbin / ifconfig ppp0" zeigte, dass der Download einige Sekunden dauerte.

Ich habe im Internet etwas gefunden, das besagte, dass meine iptables-Regeln Pakete verwerfen sollten, die als "ungültig" gekennzeichnet sind. Ich habe Regeln hinzugefügt, um ungültige Pakete zu löschen, aber die Situation wurde dadurch nicht verbessert. Ich habe auch versucht, mich anzumelden, und sah, dass ich ein paar solcher Pakete von Netflix erhielt, aber nur, wenn ich auf einer anderen Maschine als Schimpanse beobachtete.

Ich habe "echo 255> / proc / sys / net / netfilter / nf_conntrack_log_invalid" ausprobiert und sah, dass die ungültigen Pakete auf fehlerhafte TCP-Prüfsummen zurückzuführen waren:

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 

(Das Präfix "input invalid" zeigt an, dass es von meiner iptables-Regel stammt, dass ein ungültiges Paket in der Eingangskette vor dem Ablegen protokolliert wird.)

Ich habe versucht, die Checksummenprüfung in conntrack mit "sysctl -w net.netfilter.nf_conntrack_checksum = 0" zu deaktivieren. Dadurch wurden die obigen Protokollzeilen angehalten, das Problem jedoch nicht behoben.

Meine beste Vermutung ist also:

• Etwas ist stromaufwärts gebrochen, weil ich mir einen Netflix-Stream geschickt habe, also bekomme ich TCP-Prüfsummenfehler.
• Beim Betrachten von Netflix auf Schimpanse trifft ein fehlerhaftes Paket in der TCP-Schicht des Schimpansen ein und kann es wiederherstellen, indem es möglicherweise erneut nach dem Paket fragt.
• Bei der Überwachung auf einem anderen Rechner kann conntrack das Paket nicht mit der Verbindung verknüpfen, selbst wenn die Überprüfung der TCP-Prüfsumme deaktiviert ist. Daher wird es niemals auf der TCP-Schicht des Client-Computers angezeigt. Die TCP-Schicht des Clients wird auf drastischere Weise wiederhergestellt, möglicherweise mit einem längeren Timeout oder durch einen Fehler der gesamten Verbindung.

Letzte Frage zuletzt

Ist das für jeden sinnvoll, der mehr über TCP, Conntrack und Nat weiß als ich? Oder kann ich etwas falsch machen?

Problemumgehung

Mir ist die Luft ausgehen, das zu untersuchen. Aber möglicherweise ist diese Problemumgehung für alle anderen Benutzer von Vorteil, die das gleiche Problem haben.

Die Problemumgehung besteht darin, das gesamte Hausnetzwerk über einen http / https-Proxy einzustellen, der auf chimp (dem mit dem Internet verbundenen Computer) ausgeführt wird. Ich habe wpad.dat für chimp verwendet, um die anderen Maschinen automatisch zu konfigurieren, und habe es nur für Proxy * .netflix.com und * .nflxvideo.net eingerichtet.

Jeder Client-Computer benötigt ein wenig Konfiguration, um die automatische Proxy-Erkennung zu verwenden, nur ein einziges Kontrollkästchen in den Netzwerkeinstellungen für Mac und Gnome (und ich denke, das gleiche gilt für Windows).

Ausgabe von 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  

Ausgabe von 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