NGINX SSL antwortet nicht über IPv6

10

Auf einem Debian-Server mit nginx erhalte ich keine Antwort von einem Webserver über HTTPS und IPv6. HTTP funktioniert gut.

  • netstat meldet, dass Port 443 die IPv6-Adresse abhört
  • Die Firewall ist geöffnet. IPv6scanner.com meldet, dass Port 443 geöffnet ist
  • lokal (über Terminal) erhalten wget und curl eine korrekte Antwort, sodass die Nginx-Konfiguration in Ordnung ist
  • Keine Anzeichen eines Fehlers von nginx error.log
  • Kein Datensatz in access.log, wenn dies fehlschlägt, sodass die Kommunikation wahrscheinlich nicht den Webserver erreicht
  • DNS ist in Ordnung. Die Übersetzung funktioniert und die Verbindung funktioniert auch dann nicht, wenn direkt auf die IP-Adresse zugegriffen wird

Jeder Versuch, eine Verbindung von "außerhalb" (dh außerhalb des Netzwerks, über das Internet) herzustellen, schlägt fehl (Webbrowser, Telnet, ipv6-test.com, Curl ...). Es gibt überhaupt keine Antwort.

Es kann auf www.ekasparova.eu getestet werden. Ich bin ahnungslos. Was kann ich noch überprüfen?

bearbeiten:

Die Ausgabe von traceroute6 --mtu www.google.comist wie folgt:

traceroute to www.google.com (2a00:1450:4014:800::2004), 30 hops max, 65000 byte packets
1  * F=1500 * *
2  * * *
~
30  * * *

Es erreicht also nie das Ende ...

edit2:

Meine ip6tables-Save-Ausgabe (lokale Firewall):

# Generated by ip6tables-save v1.6.0 on Wed Oct 17 06:25:40 2018
*filter
:INPUT DROP [32:9320]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw6-after-forward - [0:0]
:ufw6-after-input - [0:0]
:ufw6-after-logging-forward - [0:0]
:ufw6-after-logging-input - [0:0]
:ufw6-after-logging-output - [0:0]
:ufw6-after-output - [0:0]
:ufw6-before-forward - [0:0]
:ufw6-before-input - [0:0]
:ufw6-before-logging-forward - [0:0]
:ufw6-before-logging-input - [0:0]
:ufw6-before-logging-output - [0:0]
:ufw6-before-output - [0:0]
:ufw6-logging-allow - [0:0]
:ufw6-logging-deny - [0:0]
:ufw6-reject-forward - [0:0]
:ufw6-reject-input - [0:0]
:ufw6-reject-output - [0:0]
:ufw6-skip-to-policy-forward - [0:0]
:ufw6-skip-to-policy-input - [0:0]
:ufw6-skip-to-policy-output - [0:0]
:ufw6-track-forward - [0:0]
:ufw6-track-input - [0:0]
:ufw6-track-output - [0:0]
:ufw6-user-forward - [0:0]
:ufw6-user-input - [0:0]
:ufw6-user-limit - [0:0]
:ufw6-user-limit-accept - [0:0]
:ufw6-user-logging-forward - [0:0]
:ufw6-user-logging-input - [0:0]
:ufw6-user-logging-output - [0:0]
:ufw6-user-output - [0:0]
-A INPUT -j ufw6-before-logging-input
-A INPUT -j ufw6-before-input
-A INPUT -j ufw6-after-input
-A INPUT -j ufw6-after-logging-input
-A INPUT -j ufw6-reject-input
-A INPUT -j ufw6-track-input
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j ufw6-before-logging-forward
-A FORWARD -j ufw6-before-forward
-A FORWARD -j ufw6-after-forward
-A FORWARD -j ufw6-after-logging-forward
-A FORWARD -j ufw6-reject-forward
-A FORWARD -j ufw6-track-forward
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A OUTPUT -j ufw6-before-logging-output
-A OUTPUT -j ufw6-before-output
-A OUTPUT -j ufw6-after-output
-A OUTPUT -j ufw6-after-logging-output
-A OUTPUT -j ufw6-reject-output
-A OUTPUT -j ufw6-track-output
-A ufw6-after-input -p udp -m udp --dport 137 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 138 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 139 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 445 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 546 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 547 -j ufw6-skip-to-policy-input
-A ufw6-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-before-forward -m rt --rt-type 0 -j DROP
-A ufw6-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-forward -j ufw6-user-forward
-A ufw6-before-input -i lo -j ACCEPT
-A ufw6-before-input -m rt --rt-type 0 -j DROP
-A ufw6-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-input -m conntrack --ctstate INVALID -j ufw6-logging-deny
-A ufw6-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 144 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 145 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 146 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -j ACCEPT
-A ufw6-before-input -d ff02::fb/128 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw6-before-input -d ff02::f/128 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw6-before-input -j ufw6-user-input
-A ufw6-before-output -o lo -j ACCEPT
-A ufw6-before-output -m rt --rt-type 0 -j DROP
-A ufw6-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -j ufw6-user-output
-A ufw6-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw6-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw6-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-skip-to-policy-forward -j DROP
-A ufw6-skip-to-policy-input -j DROP
-A ufw6-skip-to-policy-output -j ACCEPT
-A ufw6-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 20 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 21 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 110 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 143 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 587 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 993 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 995 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8080 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8081 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 10000 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m multiport --dports 29799:29899 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8082 -j ACCEPT
-A ufw6-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw6-user-limit -j REJECT --reject-with icmp6-port-unreachable
-A ufw6-user-limit-accept -j ACCEPT
COMMIT
# Completed on Wed Oct 17 06:25:40 2018

edit3:

Dank der Hilfe aller konnte ich den Betreiber des Rechenzentrums davon überzeugen, dass das Problem in seiner Infrastruktur liegt. Das Problem lag wirklich in der MTU-Einstellung auf einem virtuellen Router auf dem Weg zum Internet.

nginx ssl ipv6 j.kaspar
quelle
Außerhalb = Außerhalb des Netzwerks in einem separaten LAN-Segment oder von einem Computer in demselben LAN-Segment?
IceMage
1
@IceMage Outside bedeutet aus dem Internet. Außerhalb des Netzwerks. Ich werde die Frage bearbeiten, um zu klären
j.kaspar
Haben Sie eine Firewall auf dem Server konfiguriert? Wenn auf dem Server Linux ausgeführt wird, ist die Ausgabe von ip6table-saverelevant.
Kasperd
@kasperd Ich habe alle icmp-bezogenen Regeln zu der Frage
hinzugefügt
@ j.kaspar Es ist die Ausgabe von, die ip6tables-saveich sehen wollte. Dieser Befehl gibt die vollständigen Regeln aus.
Kasperd

Antworten:

19

Sie haben ein MTU-Problem.

Ich habe getestet, wget -O /dev/null https://www.ekasparova.euwährend ich den Verkehr mit beobachtet habe tcpdump. Das habe ich gesehen:

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0

Die ersten 3 Pakete sind der Handschlag. Beide Enden kündigen an, mss 1440was bedeutet, dass sie Pakete mit 1440 Byte TCP-Nutzlast empfangen können, wobei auch die Header gezählt werden. Dies entspricht 1500 Byte IP-Verkehr, was Ethernet üblicherweise unterstützt.

Die nächsten 2 Pakete sind Client-Hallo und Bestätigung, dass es vom Server empfangen wurde.

In den letzten beiden Paketen werden die Dinge interessant. Standardmäßig tcpdumpwerden relative Sequenznummern angezeigt , die in diesem Fall das Lesen der Erfassung erleichtern. Im Paket vom Server ist dies der interessante Teil seq 2857:3678. Wir sehen einen Sprung von 1zu, 2857was bedeutet, dass es eine Lücke von 2856 Bytes gibt, die der Client noch nicht empfangen hat. 2856 Bytes entsprechen zwei Paketen mit 1428 Bytes. Der Unterschied zwischen 1440 und 1428 ist die Größe einer Zeitstempeloption.

Also schickte der Server den Server Hallo aufgeteilt auf 3 Pakete. Die ersten beiden waren jedoch zu groß für das Netzwerk und wurden nicht an den Client geliefert.

Im letzten Paket vom Client zum Server sehen wir dies sack 1 {2857:3678}. Dies ist eine selektive Bestätigung, die vom Client gesendet wird und den Server darüber informiert, dass es eine Lücke in den Daten gibt, die er bisher empfangen hat.

Wahrscheinlich sendet der Server die beiden verlorenen Pakete immer wieder. Unabhängig davon, wie oft dieselben zwei Pakete erneut übertragen werden, bleiben sie für das Netzwerk zu groß. Und wahrscheinlich sendet ein Router auf dem Pfad eine Fehlermeldung an den Server zurück und informiert ihn, dass die Pakete zu groß sind und in kleineren Paketen erneut übertragen werden müssen.

Wenn der Server diese Fehlermeldungen empfängt, überträgt er die Pakete nach Bedarf erneut. Und es würde sich an die kleinere PMTU erinnern, so dass sie bei nachfolgenden Anforderungen diesen Erkennungsschritt nicht wiederholen muss.

Eine mögliche Erklärung für all dies ist, dass Sie eine falsch konfigurierte Firewall haben, die alle Fehlermeldungen löscht, die Ihren Server darüber informieren, dass er die Daten in kleineren Paketen erneut übertragen muss.

Kasperd
quelle
1
Interessant. Danke! Diese Fehlermeldungen - ich denke, es ist das ICMP-Protokoll ... Gibt es eine Möglichkeit, es zu testen? Die Firewall auf dem Server und die Firewall zwischen Server und Internet sollten für die gesamte ICMP-Kommunikation geöffnet sein.
j.kaspar
@ j.kaspar Was sind die Firewalls? Wie sind sie konfiguriert? Wie hast du sie getestet?
Michael Hampton
@MichaelHampton Es ist eine iptables-Firewall direkt auf dem Server installiert. Der zweite gehört zum Rechenzentrum und ich kann seine Regeln verwalten. Ich weiß nicht wirklich, wie ich den ICMP testen soll. Aber die Regeln für beide sind auf irgendwo <-> festgelegt, wo es für ICMP erlaubt ist
j.kaspar
1
@ j.kaspar Versuchen Sie auf einem Linux-Server, in die Ausgabezeilen eingefügte Zeilen oder Ausgabezeilen zu traceroute6 --mtu www.google.comsuchen F=####, in denen überhaupt keine Antwort zurückkommt. Führen Sie es beim zweiten Gedanken einfach aus und bearbeiten Sie Ihre Frage mit der Ausgabe.
Michael Hampton
@ MichaelHampton Fertig. Ich bin mir jedoch nicht sicher, wie ich das Ergebnis interpretieren soll. Bedeutet das, dass die Kommunikation den zweiten Sprung überhaupt nicht passiert?
j.kaspar
1

Ich stimme @kasperd zu, dass es sich um ein MTU-Problem handelt. Zum Beispiel wget -6 -O/dev/null http://www.ekasparova.euwürde standardmäßig nicht funktionieren (es würde eine kurze Umleitung https://www.babysoul.cz/auf dieselbe IP erhalten, aber dann würde es am nächstgrößeren Paket hängen bleiben). Dann habe ich MSS für Ihren Host erzwungen:

ip -6 ro add 2a04:f310:100:3:f816:3eff:fea3:4553 advmss 1000 via $MY_GW

und danach wgetfunktioniert normal. Es ist also ein MTU-Problem. Ein Vergleich der Ausgabe von mtr -6 -n --psize 1410 www.ekasparova.eu(was funktioniert) mit mtr -6 -n --psize 1411 www.ekasparova.euwürde anzeigen, dass das Problem entweder auf Ihrem Host 2a04:f310:100:3:f816:3eff:fea3:4553oder in dessen Upstream bei liegt2a04:f310:100::125

Was Sie als Problemumgehung tun könnten (abgesehen von der Kontaktaufnahme mit Ihrem Upstream):

Testen Sie, bei welcher Paketgröße es kaputt geht (dh wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.dates wird wahrscheinlich nicht für Sie funktionieren, solange es sollte, aber es wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.datwird gut funktionieren), und dann entweder:

  • (schlimmer) Klemmen Sie Ihr MSS für die Standard-IPv6-Route (wie oben beschrieben). Beachten Sie, dass dies nur für TCP funktioniert. Beispielsweise werden UDP-DNS-Pakete weiterhin beschädigt, oder
  • (besser) reduzieren Sie Ihre Schnittstellen-MTU (zum Beispiel ifconfig eth0 mtu 1200). Dies sollte für alle Pakete funktionieren. Das Problem ist, dass Sie nicht mit ihnen kommunizieren können, wenn etwas auf dem Weg eine noch niedrigere MTU hat. Und eine Verringerung der MTU führt zu einer etwas geringeren Leistung (keine große Sache, es sei denn, Sie sind normalerweise eine große Site).
  • (am besten) versuchen Sie, ob das Entfernen der IPv6-Firewall (Ihrer und Ihres Upsteams) hilft; Wenn Sie dies herausfinden, versuchen Sie, es Schritt für Schritt wieder zusammenzusetzen, ohne die PMTU-Erkennung zu unterbrechen, bis Sie eine problematische Zeile finden. Das Problem ist, dass Ihr ISP mehr Arbeit und Zusammenarbeit benötigt (und das Öffnen der Firewall Sie möglicherweise für die Zeit anfällig macht).
Matija Nalis
quelle
Das Reduzieren von MSS auf der Standardroute ist kein schlechter Vorschlag. Es ist etwas, was ich in Produktionsumgebungen getan habe, um MTU-Probleme in den Netzwerken anderer Leute zu umgehen. Ich gehe aber nicht so niedrig wie 1000. 1220 ist klein genug, um das gesamte Paket innerhalb der 1280 Bytes zu halten, die IPv6 garantiert, um Ende-zu-Ende zu arbeiten. Das fragliche Problem wäre jedoch nicht durch die Reduzierung von MSS auf der Standardroute gemildert worden, da es nur die Paketgrößen in eine Richtung betrifft.
Kasperd
Man kann das MSS während des Transports entstellen (sollte damit möglich sein ip6tables). Sie sollten das nicht tun, aber es stellt sich heraus, dass das Festklemmen des MSS während des Transports auf maximal 1220 eine sehr effiziente Problemumgehung für MTU-Probleme darstellt. Dies kann entweder an einem Endpunkt oder an einem beliebigen Zwischenrouter erfolgen und verringert die MTU-Probleme für TCP in beide Richtungen.
Kasperd
Das Verringern der MTU auf einem Endpunkt beeinflusst die ausgehende MSS und begrenzt auch die von Ihnen gesendeten Pakete, selbst wenn Sie eine höhere MSS erhalten haben. Eine niedrigere MTU an einem Endpunkt kann somit die MTU-Probleme für TCP in beide Richtungen verringern. Es hilft jedoch nur für UDP in eine Richtung. Durch die Reduzierung der MTU auf Routern dazwischen kann das MTU-Problem gemindert oder je nach den Umständen neue MTU-Probleme eingeführt werden. Die Reduzierung von MSS ist daher die einzige Abschwächung, die helfen kann, ohne potenziell neue MTU-Probleme einzuführen.
Kasperd
@kasperd sollte das MSS nicht einseitig senken, wenn der Datenverkehr in beide Richtungen fließt, da er (als niedrigeres MSS) für die gesamte TCP-Sitzung während des 3-Wege-Handshakes ausgehandelt wird. Was das Verringern der MTU und das Brechen eingehender UDPs betrifft, sollte das Problem zwar nicht gelöst werden, es sollten jedoch keine zusätzlichen Probleme entstehen, da diese zu großen UDPs ohnehin nicht funktionieren würden (da sein defekter Upstream sie sowieso fallen lassen würde). .
Matija Nalis
1
Nein. MSS wird unabhängig für die beiden Richtungen ausgehandelt. Jede Seite kennt das Maximum, das sie senden möchten, und teilt dem anderen Ende das Maximum mit, das sie empfangen möchten. Wenn Sie festlegen advmss, beeinflussen Sie nur die Größe der Segmente, die Sie empfangen möchten, nicht die Segmente, die Sie senden möchten. Das Maximum, das Sie senden möchten, wird nicht mitgeteilt - da dies nicht erforderlich ist. Beide leiten ihren Standardwert von der MTU ab, einer der beiden kann mit überschrieben werden advmss. Ich weiß nicht, wie ein Routing-Eintrag den anderen überschreiben kann, aber wenn es einen Weg gibt, würde ich gerne lernen.
Kasperd