search

freifunk-ffm / ToDo-Liste

Hier werde Punkte gesammelt, welche umgesetzt bzw. abgearbeitet werden sollten. Siehe https://github.com/freifunk-ffm/ToDo-Liste/issues
0 stars 0 forks source link

NAT64: Webseiten/-dienste, welche nicht funktionieren #53

Closed oszilloskop closed 5 years ago

oszilloskop commented 6 years ago

Webseiten, welcher unter Babel nicht funktionieren:

Webdiensten, welche unter Babel nicht funktionieren:

Falls weitere Seiten/Dienste unter Babel auffällig sind, dann bitte die Listeneinträge ergänzen bzw. editieren.
bildschirmfoto 2017-12-27 um 13 47 24

ctr49 commented 6 years ago

Das Problem lässt sich relativ leicht reproduzieren. Von einem Client zu einer betroffenen Seite per openssl eine Verbindung aufbauen, das hängt direkt nach "CONNECTED(00000005)":

$ echo Q|openssl s_client -connect www.unitymedia.de:443
CONNECTED(00000005)

Vom FF router selbst klappt die gleiche Verbindung dagegen:

# echo Q|openssl s_client -connect www.unitymedia.de:443
CONNECTED(00000003)
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2

Evtl. etwas im NAT64? Alle betroffenen hosts haben nur eine IPv4 Adresse. Ich werde mal mit tcpdump einen Vergleich geht/geht nicht aufzeichnen.

christf commented 6 years ago

Die heutige Analyse zeigt, auf jool1, dass nach upstream "need to frag"-icmp-messages geschickt werden. Der upstream host führt retries mit identischer MTU ohne andere Fragmentierung aus.

18:25:09.901495 IP (tos 0x0, ttl 59, id 24168, offset 0, flags [none], proto TCP (6), length 64)
    185.206.209.198.55333 > 8.247.0.173.443: Flags [S], cksum 0x50ed (correct), seq 883847596, win 65535, options [mss 1440,nop,wscale 5,nop,nop,TS val 1319993858 ecr 0,sackOK,eol], length 0
18:25:09.914813 IP (tos 0x0, ttl 53, id 27814, offset 0, flags [none], proto TCP (6), length 60)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [S.], cksum 0xc1e9 (correct), seq 4234112535, ack 883847597, win 14480, options [mss 1460,sackOK,TS val 4289854759 ecr 1319993858,nop,wscale 7], length 0
18:25:10.069406 IP (tos 0x0, ttl 59, id 20644, offset 0, flags [none], proto TCP (6), length 370)
    185.206.209.198.55333 > 8.247.0.173.443: Flags [P.], cksum 0x56df (correct), seq 1:319, ack 1, win 4105, options [nop,nop,TS val 1319993998 ecr 4289854759], length 318
18:25:10.069447 IP (tos 0x0, ttl 59, id 48852, offset 0, flags [none], proto TCP (6), length 52)
    185.206.209.198.55333 > 8.247.0.173.443: Flags [.], cksum 0x18b1 (correct), seq 1, ack 1, win 4105, options [nop,nop,TS val 1319993998 ecr 4289854759], length 0
18:25:10.082598 IP (tos 0x0, ttl 53, id 27815, offset 0, flags [none], proto TCP (6), length 52)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x265a (correct), seq 1, ack 319, win 122, options [nop,nop,TS val 4289854927 ecr 1319993998], length 0
18:25:10.082807 IP (tos 0x0, ttl 53, id 27816, offset 0, flags [none], proto TCP (6), length 52)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x265a (correct), seq 1, ack 319, win 122, options [nop,nop,TS val 4289854927 ecr 1319993998], length 0
18:25:10.086903 IP (tos 0x0, ttl 53, id 27817, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x60a6 (correct), seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289854931 ecr 1319993998], length 1428
18:25:10.086954 IP (tos 0x0, ttl 53, id 27818, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0xf233 (correct), seq 1429:2857, ack 319, win 122, options [nop,nop,TS val 4289854931 ecr 1319993998], length 1428
18:25:10.086967 IP (tos 0x0, ttl 53, id 27819, offset 0, flags [none], proto TCP (6), length 537)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [P.], cksum 0x526f (correct), seq 2857:3342, ack 319, win 122, options [nop,nop,TS val 4289854931 ecr 1319993998], length 485
18:25:10.087620 IP (tos 0x0, ttl 61, id 37122, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 33222, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289854931 ecr 1319993998], length 1428
18:25:10.087659 IP (tos 0x0, ttl 61, id 56771, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 53789, offset 0, flags [none], proto TCP (6), length 1965)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [P.], seq 1429:3342, ack 319, win 122, options [nop,nop,TS val 4289854931 ecr 1319993998], length 1913
18:25:10.590801 IP (tos 0x0, ttl 53, id 27820, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x5eae (correct), seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289855435 ecr 1319993998], length 1428
18:25:10.591540 IP (tos 0x0, ttl 61, id 29818, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 48524, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289855435 ecr 1319993998], length 1428
18:25:11.599650 IP (tos 0x0, ttl 53, id 27821, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x5abe (correct), seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289856443 ecr 1319993998], length 1428
18:25:11.600478 IP (tos 0x0, ttl 61, id 38619, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 18559, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289856443 ecr 1319993998], length 1428
18:25:13.614899 IP (tos 0x0, ttl 53, id 27822, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x52de (correct), seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289858459 ecr 1319993998], length 1428
18:25:13.615558 IP (tos 0x0, ttl 61, id 26332, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 36281, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289858459 ecr 1319993998], length 1428
18:25:17.646669 IP (tos 0x0, ttl 53, id 27823, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], cksum 0x431e (correct), seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289862491 ecr 1319993998], length 1428
18:25:17.647336 IP (tos 0x0, ttl 61, id 56600, offset 0, flags [none], proto ICMP (1), length 576)
    185.206.209.198 > 8.247.0.173: ICMP 185.206.209.198 unreachable - need to frag (mtu 1292), length 556
    IP (tos 0x0, ttl 50, id 263, offset 0, flags [none], proto TCP (6), length 1480)
    8.247.0.173.443 > 185.206.209.198.55333: Flags [.], seq 1:1429, ack 319, win 122, options [nop,nop,TS val 4289862491 ecr 1319993998], length 1428
ctr49 commented 6 years ago

Meine Schlussfolgerung wäre, dass das derzeitige NAT64 Konzept die leider vorhandenen PMTU Blackholes im Internet ausblendet.

Die Jool Doku beschreibt, dass für Fragmentation die Link MTU auf dem IPv6 Interface auf die PMTU zum Client gestellt sein muss, damit der Kernel die Fragmentierung übernimmt. Dies wird im derzeitigen Setup nicht ohne weiteres möglich sein.

Alternativen (bzw. Workarounds) wären eine kleinere MTU per RA an die Clients zu senden (unterstützt uradvd allerdings nicht) oder per MSS Clamping die TCP-MSS auf einen geeigneten Wert zu setzen (z.B. fastd MTU 1312 - 20 - 40 = 1252):

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1252
christf commented 6 years ago

gerade probieren wir den MSS Clamping-Weg mit o.g. Kommando auf jool1 iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1252

=> macht, dass es geht.

christf commented 6 years ago

ich war mal so frei, den Titel anzupassen. Mit babel hat das nicht viel zu tun.

skorpy2009 commented 6 years ago

Ich empfehle 1220 zu nutzten und das immer auf den Knoten schon

ctr49 commented 6 years ago

Das Problem entsteht im Prinzip nur durch NAT64, für reines IPv6 würde eine packet to big Signalisierung auch sauber ankommen. Da man man bei IPv6 only (derzeitiger Stand vor 464XLAT) gar kein Client-seitiges IPv4 hat, müsste/sollte man das dann zumindestens auf "-d 64:ff9b::/96" beschränken wenn man es auf dem Node macht.

Allerdings halte ich MSS Clamping nur für einen Workaround bzw. die drittbeste Lösung. Ich denke wir sollten dem uradvd beibringen, die MTU per RA zu senden und diese dann auf den ebenfalls für fastd konfigurierten Wert zu stellen. So ist das Verhalten Ende-zu-Ende konsistent und die Pakete müssen gar nicht erst angefasst werden, weil der Client gleich die richtige MSS setzt bzw. Pakete in der richtigen Größe sendet (das funktioniert dann auch für andere Protokolle als TCP im Gegensatz zu MSS Clamping).

christf commented 6 years ago

Wir haben jetzt ein Paket, mit dem clamping auf dem node umsetzbar ist.

Teil 2 ist ausstehend: uradvd patchen damit er eine mtu announcen kann.

Am 31. Dezember 2017 11:41:58 MEZ schrieb Christian Tramnitz notifications@github.com:

Das Problem entsteht im Prinzip nur durch NAT64, für reines IPv6 würde eine packet to big Signalisierung auch sauber ankommen. Da man man bei IPv6 only (derzeitiger Stand vor 464XLAT) gar kein Client-seitiges IPv4 hat, müsste/sollte man das dann zumindestens auf "-d 64:ff9b::/96" beschränken wenn man es auf dem Node macht.

Allerdings halte ich MSS Clamping nur für einen Workaround bzw. die drittbeste Lösung. Ich denke wir sollten dem uradvd beibringen, die MTU per RA zu senden und diese dann auf den ebenfalls für fastd konfigurierten Wert zu stellen. So ist das Verhalten Ende-zu-Ende konsistent und die Pakete müssen gar nicht erst angefasst werden, weil der Client gleich die richtige MSS setzt bzw. Pakete in der richtigen Größe sendet (das funktioniert dann auch für andere Protokolle als TCP im Gegensatz zu MSS Clamping).

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/freifunk-ffm/ToDo-Liste/issues/53#issuecomment-354597014

christf commented 6 years ago

Die rule auf jool1 ist wieder aktiv (manuell gesetzt, gültig bis zum nächsten Re-start) sodass die Symptome weg gehen, bis wir das Paket in der Firmware haben.

christf commented 6 years ago

@oszilloskop besteht das PRoblem auch mit der letzten Firmware noch, die das clamping-paket enthält?

oszilloskop commented 6 years ago

Die aktuelle oben aufgeführten Probleme (Stand 02.01.2018) bestehen nicht mehr.

christf commented 6 years ago

was machen wir mit dem Thema? Ist noch etwas zu tun?

christf commented 6 years ago

Nach Korrektur der babeld config gehen nun alle oben genannten URLs

oszilloskop commented 6 years ago

Stand 14.03.2018: Die oben genannten URLs funktionieren nicht mehr.

christf commented 6 years ago

@oszilloskop gehen sie wieder? bei mir schon.....

oszilloskop commented 6 years ago

@christf bei mir auch.