Hallo,
ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich beziehen und an Clients dahinter verteilen.
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und die des anderen Netzes nicht. Schaue ich mir das aus Sicht des Webservers an, so sendet dieser in beiden Fällen Antworten Richtung anfragendem Client, schaue ich auf dem Router bleiben für die fehlerhaften Clients diese Antworten aber aus. Für mich schien klar, der Provider filtert da aus nicht nachvollziehbaren Gründen das eine Netz. Wohlgemerkt mit z.B. SMTP habe ich das Problem nicht. Zum Glück heißt der Provider nicht TELEKOM oder so, sondern ist bis zum Router runter ansprechbar. Auch dieser sieht schon die Antworten des Webservers angeblich nicht und auch sein Vorgeschalteter würde nicht filtern. Wir halben mal das komplette IPv6-Netz gewechselt, aber das Bild bleibt gleich das erste Segment kann arbeiten, das zweite wieder nicht. Mein Provider meint, es läge an meinem Router (Debian 9, Kernel 4.19, netfilter) - erklärt das aber nicht genauer. Ich komme beim Provider nun nicht mehr weiter und will der Behauptung meine Technik sei Schuld eine Chance geben.
Ich beziehe mit wide-dhcpv6 über ppp0 einen Adressbereich und ordne ihn auf zwei Interfaces wie folgt zu:
profile default { information-only; request domain-name-servers; request domain-name; script "/etc/wide-dhcpv6/dhcp6c-script"; };
interface ppp0 { send ia-pd 999; };
id-assoc pd 999 { prefix ::/56 infinity; prefix-interface eth0 { sla-len 8; sla-id 0; ifid 1; }; prefix-interface eth1 { sla-len 8; sla-id 16; ifid 1; }; };
Zusätzlich verteile ich die Netzinformation für die dahinterliegenden Clients mit radvd wie folgt:
interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; AdvDefaultPreference high; AdvLinkMTU 1280;
prefix 2a00:fda0:6:cd00::/64 { AdvOnLink on; AdvAutonomous off; AdvRouterAddr on; };
RDNSS 2a00:fda0:6:cd00::221 2a00:fda0:6:cd00::222 { # }; DNSSL its-local { # }; };
interface eth1 { AdvSendAdvert on; prefix 2a00:fda0:6:cd10::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; RDNSS 2001:4860:4860::8888 2001:4860:4860::8844 { # }; };
Nennen wir das Netz hinter eth0 LAN und das hinter eth1 LAB. Auf mindestens einen Webserver im WAN mit IPv6 habe ich Zugriff. Daher hier mal die Paketmitschnitte aus Sicht dieses Webservers, wenn eine Anfrage aus dem LAN kommt und eine aus LAB.
Kann denn da einer von Euch orakeln, warum ein Teil der Antworten an LAB irgendwo verloren gehen?
Ich kann auch Dumps von dem zeigen, was mein Router davon noch sieht.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Ronny,
On Tue, Apr 09, 2019 at 11:47:40 +0200, Ronny Seffner wrote:
ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich beziehen und an Clients dahinter verteilen.
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und die des anderen Netzes nicht.
Wohl eher mit grossen Paketen, die vom Server kommen.
[...]
Zusätzlich verteile ich die Netzinformation für die dahinterliegenden Clients mit radvd wie folgt:
interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; AdvDefaultPreference high; AdvLinkMTU 1280;
[...]
interface eth1 { AdvSendAdvert on; prefix 2a00:fda0:6:cd10::/64 {
Ohne radvd besonders gut zu kennen faellt mir auf, dass Du nur fuer eth0 (LAN) die Link-MTU der Clients auf 1280 senkst, bei eth1 (LAB) tust Du das nicht. Entsprechend setzen die Clients im LAN ihre Interface-MTU auf 1280, waehrend die Clients im LAB die Interface-MTU beim Default, also 1500 belassen.
Nennen wir das Netz hinter eth0 LAN und das hinter eth1 LAB. Auf mindestens einen Webserver im WAN mit IPv6 habe ich Zugriff. Daher hier mal die Paketmitschnitte aus Sicht dieses Webservers, wenn eine Anfrage aus dem LAN kommt und eine aus LAB.
TCP handelt beim Verbindungsaufbau die mss (maximum segment size) zwischen Client und Server aus.
Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der Interface-MTU 1280 abgeleitet, die Serverseite antwortet mit mss 1440. Damit muessen sie sich auf der kleineren Wert (1220) einigen, der dann fuer *beide* Richtungen der TCP-Verbindung benutzt wird.
Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich irgendeinem Router auf der Strecke vom Server zum Client zu gross werden.
Gruss, Christian
Hi,
On 4/10/19 9:41 AM, Christian Perle wrote:
Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und die des anderen Netzes nicht.
Wohl eher mit grossen Paketen, die vom Server kommen.
Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der Interface-MTU 1280 abgeleitet, die Serverseite antwortet mit mss 1440. Damit muessen sie sich auf der kleineren Wert (1220) einigen, der dann fuer *beide* Richtungen der TCP-Verbindung benutzt wird.
Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich irgendeinem Router auf der Strecke vom Server zum Client zu gross werden.
Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal 1492.
Hier gibt es einen netten Überblick:
http://www.nwlab.net/art/mtu/mtu.html
Konrad
Hallo Konrad,
On Wed, Apr 10, 2019 at 10:13:26 +0200, Konrad Rosenbaum wrote:
Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal 1492.
Hier gibt es einen netten Überblick:
Und falls ICMPv6 packet too big korrekt zugestellt werden, kann man die Path-MTU auch mit tracepath (Debian-Paket: iputils-tracepath) ermitteln.
$ tracepath <Zieladresse>
Das sollte natuerlich auf einem Client im LAB gemacht werden, weil bei den Clients im LAN die lokale MTU (Interface) schon auf dem IPv6-Minimum (1280) sitzt.
Gruss, Christian
$ tracepath <Zieladresse>
Das sollte natuerlich auf einem Client im LAB gemacht werden, weil bei den Clients im LAN die lokale MTU (Interface) schon auf dem IPv6-Minimum (1280) sitzt.
Das liefert im fehlerhaften Zustand:
1?: [LOCALHOST] 0.010ms pmtu 1500 ... Resume: pmtu 1470 hops 8 back 8
Und nun, wo ich den radvd angepasst habe:
1?: [LOCALHOST] 0.011ms pmtu 1280 ... Resume: pmtu 1280 hops 8 back 8
D.h. mit 1470 sollte ich auch arbeiten können und muss nicht auf 1280 runter?
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Konrad,
Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich irgendeinem Router auf der Strecke vom Server zum Client zu gross werden.
Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal 1492.
Genau da lag wohl das Übel.
Vielen Dank.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hallo Christian,
Ohne radvd besonders gut zu kennen faellt mir auf, dass Du nur fuer eth0 (LAN) die Link-MTU der Clients auf 1280 senkst, bei eth1 (LAB) tust Du das nicht. Entsprechend setzen die Clients im LAN ihre Interface-MTU auf 1280, waehrend die Clients im LAB die Interface-MTU beim Default, also 1500 belassen.
Der Hinweis war wohl Gold wert. Danke.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
lug-dd@mailman.schlittermann.de