Ich würde hier doch noch einmal nach der MTU schauen, auch wenn da:
wireguard MTU steht auf 1420 - verringern bringt nichts
steht in #1.
Was fällt im (zweiten) Mitschnitt auf?
Solange die Pakete alle unterhalb einer bestimmten Größe bleiben (während des Handshakes in den ersten 380 ms ist das aufgezeichnete Maximum ein Paket mit 1343 Byte Länge), geht es relativ flott (und protokollkonform) vonstatten (bis Paket 29 in #11). Aber schon mit Paket 30 tritt der erste Fehler auf - das kann schon nicht mehr richtig in den TLS-Stream eingeordnet werden und der Client sendet in Paket 31 noch einmal ein ACK für das/die bereits mit Paket 29 bestätigte(n).
Danach passiert aber erst mal nicht mehr viel ... nach knapp 4 Sekunden überträgt der Server noch einmal ein Paket, was er vermeintlich bereits gesendet hat - hier ist sicherlich die Annahme gestattet, daß es sich um die Wiederholung der Übertragung des Paketes handelt, von dem in Nr. 30 nur ein Chunk (nämlich 355 Byte) in einem TLS-Paket zu sehen ist. Und das geht dann so weiter ... mit wachsendem Retransmission-Timeout. Die ACKs, die der Client so verzweifelt senden will, kommen offenbar aber auch beim Server nicht an (sonst würde der ja mit den Retransmissions auch aufhören).
Nun kann das in diesem konkreten Fall tatsächlich an allem möglichen liegen ... denn für einen sinnvollen Test ist eine TLS-Verbindung über einen WG-Tunnel wohl kaum das geeignete Werkzeug (das geht schon damit los, daß "Paketnummer" eigentlich als Charakterisierung nicht mehr stimmt, weil die Zeilen des TLS-Dissectors ja auch auftauchen und das sind eigentlich keine "Pakete").
Während man bei einer normalen HTTP-Verbindung wenigstens mit den passenden Parametern auch noch in den Inhalt der Pakete schauen könnte (und damit auch sehen kann, welche Inhalte da übertragen werden und "wieviel" das jeweils ist), klappt das bei den TLS-Paketen schon mal gar nicht.
Außerdem ist eine TLS-Verbindung (die ja für sich die Paketinhalte/-integrität noch einmal gesondert schützt) auch besonders anfällig dafür, daß fehlende Pakete (bei der Übertragung, also unter Beteiligung der WG-Software) die komplette Verbindung unbrauchbar machen (und erneut übertragen werden müssen) ... ohne korrekte Reassemblierung von TLS-Paketen aus dem zur Übertragung genutzten TCP-Stream kann auch der "gekapselte" HTTP-Stream (der auch wieder aus TCP-Paketen besteht, aber nicht aus denen, die man im
tcpdump in #11 sieht, denn das SIND nur die Fragmente von TLS-Paketen) nicht extrahiert werden.
Wenn man mit einem Packet-Dump etwas anfangen will, sollte man für die zum Test genutzte Verbindung dann eben KEIN TLS verwenden (weil die doppelte Verschlüsselung die Analyse der Daten unmöglich macht) - notfalls muß man eben noch (zeitweilig) einen HTTP-Service auf 10.0.0.18 aktivieren. Auch ist es nicht hilfreich, wenn man dann zum Testen einen Browser o.ä. verwendet, denn wenn man sich den Mitschnitt besonders am Beginn genau ansieht, werden da mehrere TCP-Verbindungen protokolliert (bzw. "nur" zwei, aber die auch noch alle per TLS) und ineinander "verwoben" (man sieht's an den unterschiedlichen Portnummern der Pakete, die von der 192.168.8.51 gesendet werden) und man kann bei der Dissector-Ausgabe "TLSv1.3 [size] [tls_message_type]" gar nicht mehr zuordnen, zu welcher TLS-Verbindung das gehören soll.
Wobei der erste Versuch tatsächlich nur so aussieht, als würde sich da ein Browser vergewissern wollen, daß das Ziel auch über HTTPS (halt auf Port 9090, aber das ist nicht entscheidend) zu erreichen wäre - denn "Nutzdaten" werden in dieser Verbindung offenbar nicht ausgetauscht (bis Paket 17). Dennoch ist hier ein Test mit einem Programm, was tatsächlich nur eine einzelne HTTP-Verbindung aufbaut (notfalls, weil es durch passende Parameter von automatischen Weiterleitungen o.ä. abgehalten wird), deutlich übersichtlicher in der Ausgabe.
In "Zeile 25" dürfte jedenfalls der eigentliche HTTP-Request (halt verschlüsselt) von 192.168.5.1 an 10.0.0.18 übermittelt werden ... das darauf folgende ACK (ohne weitere Daten) spricht dafür. Und in Zeile 28 startet dann wohl die Antwort des "Servers", die aber nie so weit sinnvoll übertragen werden kann, daß der TLS-Dissector sie noch einmal identifizieren kann. Zeile 46 zeigt dann zwar wieder eine "komplette" TLS-Message, aber da dürfte es sich nach 30 Sekunden eher um eine Fehlermeldung des Servers handeln, die wieder so kurz ist (mit ihren 92 Bytes), daß sie erfolgreich übertragen werden kann. Wenn man keine TLS-Verbindung zum Test nutzt, kann man auch lesen, WAS da übertragen wird.
Und auch wenn
tcpdump für eine "schnelle Diagnose" auf der Kommandozeile taugen mag (zumindest dann, wenn es ein "ausgewachsenes"
tcpdump ist und nicht irgendeine beschnittene Version) - die Dissectoren von Wireshark gehen deutlich weiter beim Aufdröseln von Paketen (auch wenn
tcpdump üblicherweise mittels
-v und
-X zu weiteren Ausgaben überredet werden kann) und vor allem erfolgt da eine persistente Aufzeichnung, die man auch jenseits von ("flüchtigen") Ausgaben im Terminal-Fenster noch genauer untersuchen kann.
Zusammengefaßt würde ich in dem Mitschnitt aber eher ein Transport-Problem erkennen wollen und kein Server-Problem - die Retransmissions haben ja nichts damit zu tun, daß/ob der adressierte Server nicht reagiert oder falsche Inhalte (falls es einen "default"-Service gibt) ausliefert. Und wenn es tatsächlich ein Transport-Problem ist, dann ist ziemlich sicher auch die MTU ein Thema - ich würde zumindest noch einmal prüfen, ob eine geänderte Einstellung (s. Zitat aus #1 oben) auch tatsächlich
wirksam war - dann müßten ja auch die Pakete im Mitschnitt (die für den "Tunnel" - und auch das kann man auf der FRITZ!Box auf dem Internet-Interface mitschneiden, was da in der WG-Verbindung transportiert wird und auch wenn man den Inhalt nicht sieht, ist doch die Paketgröße erkennbar) entsprechend kleiner werden.
EDIT: Man kann üblicherweise die MTU ja auch "manuell" mittels
ping o.ä. ermitteln ... hier mal ein Beispiel auf einem Linux-System:
Rich (BBCode):
vidar:~ $ ping -s 1472 -c 5 -M do 192.168.169.1
PING 192.168.169.1 (192.168.169.1) 1472(1500) bytes of data.
1480 bytes from 192.168.169.1: icmp_seq=1 ttl=64 time=35.4 ms
1480 bytes from 192.168.169.1: icmp_seq=2 ttl=64 time=31.8 ms
1480 bytes from 192.168.169.1: icmp_seq=3 ttl=64 time=57.2 ms
1480 bytes from 192.168.169.1: icmp_seq=4 ttl=64 time=25.5 ms
1480 bytes from 192.168.169.1: icmp_seq=5 ttl=64 time=28.5 ms
--- 192.168.169.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 25.496/35.679/57.166/11.238 ms
vidar:~ $ ping -s 1473 -c 5 -M do 192.168.169.1
PING 192.168.169.1 (192.168.169.1) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
--- 192.168.169.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4076ms
vidar:~ $
