[Problem] wireguard: ssh geht, http nicht - wie debuggen?

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Hallo, ich habe eine fritzbox mit freetz-ng und wireguard server. Daran ist ein client angemeldet. Ich kann vom LAN der fritzbox problemlos per ssh auf den client zugreifen. Die per http bereitgestellten Dienste reagieren fast nicht. Fast heißt, die url läßt sich aufrufen und Bruchteile der Seite bauen sich auf, aber irgendwann bricht es ab. Meine Beobachtungen bisher: wireguard MTU steht auf 1420 - verringern bringt nichts. Ping in beide Richtungen geht problemls. SSH shell geht. Traceroute geht, iperf ist OK:
Code:
[email protected]:~$ iperf -c 192.168.18.88 -b 100M
------------------------------------------------------------
Client connecting to 192.168.18.88, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.8.51 port 59958 connected with 192.168.18.88 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.5 sec  28.9 MBytes  23.1 Mbits/sec

Was mache ich falsch? Wie kann ich die Verbindung debuggen?
Bildschirmfoto vom 2021-10-26 11-51-27.png
[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]
 
Zuletzt bearbeitet von einem Moderator:

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
18,136
Punkte für Reaktionen
112
Punkte
63
Die bei iperf verwendete IP taucht im Bild nicht auf. Wie passt die ins Bild?

Der http Server lauscht auch auf der richtigen IP? Die Konfiguration beinhaltet den richtigen Virtual Host? Ich vermute, das ist eher ein Problem des Webservers denn des Tunnels.
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Die http-Dienste auf dem client funktionieren lokal prima. Ich rufe die passenden ports explizit auf, also z. B. 10.0.0.18:9090 oder die lokale IP des clients in Netz B 192.168.18.88:9090. Der browser beginnt auch zu laden (also er sagt nicht, die Seite sei nicht erreichbar) nur bleibt sie weiß. Von innerhalb des Netzes B sind sie natürlich problemlos aufrufbar.
 

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
18,136
Punkte für Reaktionen
112
Punkte
63
Ich rufe die passenden ports explizit auf, also z. B. 10.0.0.18:9090 oder die lokale IP des clients in Netz B 192.168.18.88:9090.
Genau das hab ich befürchtet. Das sind aus Sicht des Webserver zwei vollkommen verschiedene Dinge. Ich weiß nicht, welchen Web-Server du verwendest, aber da musst du ansetzen.
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Was genau meinst Du mit "ansetzen". Ich denke, wenn der webserver (wireguard client) die wg-IP 10.0.0.18 hat, liefert er auch alle Anfragen an beliebige ports zurück. Ich habe da ja keine Filter drauf.
Hier mal ein screenshot der home assistant GUI. Das hat er in 10 Minuten geschafft:
Bildschirmfoto von 2021-10-26 12-29-20.png
[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]

Also im Prinzip liefern http-Anfragen Daten, aber unfaßbar langsam. Lt. ipferf antwortet er ja eigentlich auf TCP mit 30MB/s (s. o.).
 
Zuletzt bearbeitet von einem Moderator:

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
8,014
Punkte für Reaktionen
28
Punkte
48
Was genau meinst Du mit "ansetzen". Ich denke, wenn der webserver (wireguard client) die wg-IP 10.0.0.18 hat, liefert er auch alle Anfragen an beliebige ports zurück.
Mach mal via WG-VPN einen Portscan auf den lauschenden TCP-Port des Webservers und schau mit z. B. tcpdump nach, ob ein 3-wege-handshake (syn/syn+ack/ack) zwischen Client und Server (via WG-VPN) statt findet.
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Danke schon mal für die Hilfestellung. Allerdings geht das jetzt deutlich über mein Wissen hinaus. Ich kippe hier mal die ersten Zeilen des dumps rein, in der Hoffnung, daß du mir helfen kannst, das zu verstehen. Aufgerufen habe ich die (existierende) Seite 10.0.0.18:9090.
Code:
No.    Time    Source    Destination    Protocol    Length    Info
1    0.000000    192.168.8.51    10.0.0.18    TCP    74    46836 → 9090 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1981931556 TSecr=0 WS=128
2    0.042420    192.168.8.51    10.0.0.18    TCP    66    46836 → 9090 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1981931599 TSecr=1845030753
3    0.042706    192.168.8.51    10.0.0.18    TLSv1.2    583    Client Hello
4    0.085871    192.168.8.51    10.0.0.18    TCP    66    46836 → 9090 [ACK] Seq=518 Ack=134 Win=64128 Len=0 TSval=1981931642 TSecr=1845030809
5    0.114892    192.168.8.51    10.0.0.18    TCP    66    46836 → 9090 [ACK] Seq=518 Ack=1411 Win=63104 Len=0 TSval=1981931671 TSecr=1845030838
6    0.117378    192.168.8.51    10.0.0.18    TLSv1.2    96    Change Cipher Spec, Application Data
7    0.117696    192.168.8.51    10.0.0.18    TCP    66    46836 → 9090 [FIN, ACK] Seq=548 Ack=1411 Win=64128 Len=0 TSval=1981931674 TSecr=1845030838
8    0.118861    192.168.8.51    10.0.0.18    TCP    74    46838 → 9090 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1981931675 TSecr=0 WS=128
9    0.162536    192.168.8.51    10.0.0.18    TCP    66    46836 → 9090 [ACK] Seq=549 Ack=1412 Win=64128 Len=0 TSval=1981931719 TSecr=1845030872
10    0.162646    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1981931719 TSecr=1845030873
11    0.163268    192.168.8.51    10.0.0.18    TLSv1.2    583    Client Hello
12    0.196679    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=518 Ack=134 Win=64128 Len=0 TSval=1981931753 TSecr=1845030925
13    0.219433    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=518 Ack=1411 Win=63104 Len=0 TSval=1981931776 TSecr=1845030945
14    0.220192    192.168.8.51    10.0.0.18    TLSv1.2    130    Change Cipher Spec, Application Data
15    0.220838    192.168.8.51    10.0.0.18    TLSv1.2    892    Application Data
16    0.468870    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=1408 Ack=2397 Win=63232 Len=0 TSval=1981932025 TSecr=1845031108
17    4.257632    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=1408 Ack=3765 Win=63104 Len=0 TSval=1981935814 TSecr=1845034965
18    4.279817    192.168.8.51    10.0.0.18    TCP    78    [TCP Dup ACK 17#1] 46838 → 9090 [ACK] Seq=1408 Ack=3765 Win=63104 Len=0 TSval=1981935836 TSecr=1845034965 SLE=17445 SRE=17756
19    8.112569    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=5133 Win=61824 Len=0 TSval=1981939669 TSecr=1845038837 SLE=17445 SRE=17756
20    11.957664    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=6501 Win=60672 Len=0 TSval=1981943514 TSecr=1845042677 SLE=17445 SRE=17756
21    27.808960    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=7869 Win=60672 Len=0 TSval=1981959365 TSecr=1845058517 SLE=17445 SRE=17756
22    31.597963    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=9237 Win=60672 Len=0 TSval=1981963154 TSecr=1845062293 SLE=17445 SRE=17756
23    31.632418    192.168.8.51    10.0.0.18    TCP    78    [TCP Window Update] 46838 → 9090 [ACK] Seq=1408 Ack=9237 Win=62720 Len=0 TSval=1981963189 TSecr=1845062293 SLE=17445 SRE=17780
24    35.490668    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=10605 Win=61440 Len=0 TSval=1981967047 TSecr=1845066101 SLE=17445 SRE=17780
25    39.585127    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=11973 Win=60288 Len=0 TSval=1981971142 TSecr=1845070293 SLE=17445 SRE=17780
26    43.682928    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=13341 Win=60288 Len=0 TSval=1981975239 TSecr=1845074389 SLE=17445 SRE=17780
27    47.782578    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=14709 Win=60288 Len=0 TSval=1981979339 TSecr=1845078485 SLE=17445 SRE=17780
28    51.989549    192.168.8.51    10.0.0.18    TCP    78    46838 → 9090 [ACK] Seq=1408 Ack=16077 Win=60288 Len=0 TSval=1981983546 TSecr=1845082581 SLE=17445 SRE=17780
29    69.267210    192.168.8.51    10.0.0.18    TCP    66    46838 → 9090 [ACK] Seq=1408 Ack=17780 Win=60288 Len=0 TSval=1982000824 TSecr=1845099989
30    69.287091    192.168.8.51    10.0.0.18    TLSv1.2    711    Application Data
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
8,014
Punkte für Reaktionen
28
Punkte
48
Starte den tcpdump immer bevor Du den Portscan bzw. die Anfrage mit dem http-Client machst.
Aus deinem dump ist ersichtlich, dass nur die IP-Adresse 192.168.8.51 als source-IP-Adresse gesehen wird. Hast Du den richtigen Filter für tcpdump benutzt? Bei einer Antwort (syn+ack) vom Server. müsste man auch Datenpakete mit der IP-Adresse 10.0.0.18 als source-IP-Adresse im dump sehen. Das ist aber nicht der Fall. Liegt es am Filter oder an der Konfiguration?
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Code:
sudo tcpdump dst 10.0.0.18 -w dump.dmp
habe ich gestartet, bevor ich die Seite aufgerufen habe. Ich gehe daher davon aus, daß das der gesamte traffic ist.
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
8,014
Punkte für Reaktionen
28
Punkte
48
Code:
sudo tcpdump dst 10.0.0.18 -w dump.dmp
habe ich gestartet, ...
Das ist der falsche Filter. Versuch mal mit:
Code:
sudo tcpdump -c 50 -vvveni wg0 host 10.0.0.18 -w dump_2.dmp
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Mit
Code:
sudo tcpdump -c 50 -vvven src 10.0.0.18 or dst 10.0.0.18 -w dump3.dmp
bekomme ich (deine Kommandozeile wurde nicht akzeptiert)
Code:
No.    Time    Source    Destination    Protocol    Length    Info
1    0.000000    192.168.8.51    10.0.0.18    TCP    74    48044 → 9090 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1985263288 TSecr=0 WS=128
2    0.044035    10.0.0.18    192.168.8.51    TCP    76    9090 → 48044 [SYN, ACK] Seq=0 Ack=1 Win=64296 Len=0 MSS=1380 SACK_PERM=1 TSval=1848362481 TSecr=1985263288 WS=128
3    0.044078    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1985263332 TSecr=1848362481
4    0.044463    192.168.8.51    10.0.0.18    TLSv1.3    583    Client Hello
5    0.068957    10.0.0.18    192.168.8.51    TCP    68    9090 → 48044 [ACK] Seq=1 Ack=518 Win=64256 Len=0 TSval=1848362522 TSecr=1985263332
6    0.070359    10.0.0.18    192.168.8.51    TLSv1.3    199    Server Hello, Change Cipher Spec
7    0.070419    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [ACK] Seq=518 Ack=134 Win=64128 Len=0 TSval=1985263358 TSecr=1848362525
8    0.091776    10.0.0.18    192.168.8.51    TLSv1.3    1343    Application Data, Application Data, Application Data, Application Data
9    0.091809    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [ACK] Seq=518 Ack=1411 Win=63104 Len=0 TSval=1985263379 TSecr=1848362548
10    0.092227    192.168.8.51    10.0.0.18    TLSv1.3    96    Change Cipher Spec, Application Data
11    0.092515    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [FIN, ACK] Seq=548 Ack=1411 Win=64128 Len=0 TSval=1985263380 TSecr=1848362548
12    0.093930    192.168.8.51    10.0.0.18    TCP    74    48046 → 9090 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1985263382 TSecr=0 WS=128
13    0.133996    10.0.0.18    192.168.8.51    TCP    68    9090 → 48044 [ACK] Seq=1411 Ack=548 Win=64256 Len=0 TSval=1848362574 TSecr=1985263380
14    0.134024    10.0.0.18    192.168.8.51    TCP    76    9090 → 48046 [SYN, ACK] Seq=0 Ack=1 Win=64296 Len=0 MSS=1380 SACK_PERM=1 TSval=1848362575 TSecr=1985263382 WS=128
15    0.134076    192.168.8.51    10.0.0.18    TCP    66    48046 → 9090 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1985263422 TSecr=1848362575
16    0.134117    10.0.0.18    192.168.8.51    TCP    68    9090 → 48044 [FIN, ACK] Seq=1411 Ack=549 Win=64256 Len=0 TSval=1848362575 TSecr=1985263380
17    0.134135    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [ACK] Seq=549 Ack=1412 Win=64128 Len=0 TSval=1985263422 TSecr=1848362575
18    0.134831    192.168.8.51    10.0.0.18    TLSv1.3    583    Client Hello
19    0.159299    10.0.0.18    192.168.8.51    TCP    68    9090 → 48046 [ACK] Seq=1 Ack=518 Win=64256 Len=0 TSval=1848362614 TSecr=1985263422
20    0.160699    10.0.0.18    192.168.8.51    TLSv1.3    199    Server Hello, Change Cipher Spec
21    0.160722    192.168.8.51    10.0.0.18    TCP    66    48046 → 9090 [ACK] Seq=518 Ack=134 Win=64128 Len=0 TSval=1985263448 TSecr=1848362615
22    0.188419    10.0.0.18    192.168.8.51    TLSv1.3    1343    Application Data, Application Data, Application Data, Application Data
23    0.188439    192.168.8.51    10.0.0.18    TCP    66    48046 → 9090 [ACK] Seq=518 Ack=1411 Win=63104 Len=0 TSval=1985263476 TSecr=1848362644
24    0.188899    192.168.8.51    10.0.0.18    TLSv1.3    130    Change Cipher Spec, Application Data
25    0.189294    192.168.8.51    10.0.0.18    TLSv1.3    899    Application Data
26    0.223934    10.0.0.18    192.168.8.51    TCP    68    9090 → 48046 [ACK] Seq=1411 Ack=582 Win=64256 Len=0 TSval=1848362668 TSecr=1985263477
27    0.223951    10.0.0.18    192.168.8.51    TCP    68    9090 → 48046 [ACK] Seq=1411 Ack=1415 Win=64256 Len=0 TSval=1848362674 TSecr=1985263477
28    0.285575    10.0.0.18    192.168.8.51    TLSv1.3    1052    Application Data
29    0.285607    192.168.8.51    10.0.0.18    TCP    66    48046 → 9090 [ACK] Seq=1415 Ack=2397 Win=63232 Len=0 TSval=1985263573 TSecr=1848362742
30    0.384571    10.0.0.18    192.168.8.51    TLSv1.3    355    [TCP Previous segment not captured] , Continuation Data
31    0.384604    192.168.8.51    10.0.0.18    TCP    78    [TCP Dup ACK 29#1] 48046 → 9090 [ACK] Seq=1415 Ack=2397 Win=63232 Len=0 TSval=1985263672 TSecr=1848362742 SLE=17445 SRE=17734
32    4.116192    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=2397 Ack=1415 Win=64256 Len=1368 TSval=1848366485 TSecr=1985263672
33    4.116251    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=3765 Win=61952 Len=0 TSval=1985267404 TSecr=1848366485 SLE=17445 SRE=17734
34    7.899720    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=3765 Ack=1415 Win=64256 Len=1368 TSval=1848370325 TSecr=1985267404
35    7.899762    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=5133 Win=60672 Len=0 TSval=1985271187 TSecr=1848370325 SLE=17445 SRE=17734
36    11.792315    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=5133 Ack=1415 Win=64256 Len=1368 TSval=1848374197 TSecr=1985271187
37    11.792371    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=6501 Win=60672 Len=0 TSval=1985275080 TSecr=1848374197 SLE=17445 SRE=17734
38    15.784477    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=6501 Ack=1415 Win=64256 Len=1368 TSval=1848378133 TSecr=1985275080
39    15.784518    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=7869 Win=60672 Len=0 TSval=1985279072 TSecr=1848378133 SLE=17445 SRE=17734
40    19.983002    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=7869 Ack=1415 Win=64256 Len=1368 TSval=1848382421 TSecr=1985279072
41    19.983046    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=9237 Win=60672 Len=0 TSval=1985283271 TSecr=1848382421 SLE=17445 SRE=17734
42    24.078609    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=9237 Ack=1415 Win=64256 Len=1368 TSval=1848386517 TSecr=1985283271
43    24.078698    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=10605 Win=60672 Len=0 TSval=1985287366 TSecr=1848386517 SLE=17445 SRE=17734
44    32.579384    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=10605 Ack=1415 Win=64256 Len=1368 TSval=1848394965 TSecr=1985287366
45    32.579441    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=11973 Win=60672 Len=0 TSval=1985295867 TSecr=1848394965 SLE=17445 SRE=17734
46    32.628003    10.0.0.18    192.168.8.51    TLSv1.3    92    Application Data
47    32.628035    192.168.8.51    10.0.0.18    TCP    78    [TCP Window Update] 48046 → 9090 [ACK] Seq=1415 Ack=11973 Win=62720 Len=0 TSval=1985295916 TSecr=1848394965 SLE=17445 SRE=17758
48    36.980876    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=11973 Ack=1415 Win=64256 Len=1368 TSval=1848399317 TSecr=1985295916
49    36.980924    192.168.8.51    10.0.0.18    TCP    78    48046 → 9090 [ACK] Seq=1415 Ack=13341 Win=61440 Len=0 TSval=1985300269 TSecr=1848399317 SLE=17445 SRE=17758
50    41.281504    10.0.0.18    192.168.8.51    TCP    1434    [TCP Retransmission] 9090 → 48046 [ACK] Seq=13341 Ack=1415 Win=64256 Len=1368 TSval=1848403669 TSecr=1985300269
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
8,014
Punkte für Reaktionen
28
Punkte
48
Mit
Code:
sudo tcpdump -c 50 -vvven src 10.0.0.18 or dst 10.0.0.18 -w dump3.dmp
bekomme ich ...
Code:
No.    Time    Source    Destination    Protocol    Length    Info
1    0.000000    192.168.8.51    10.0.0.18    TCP    74    48044 → 9090 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1985263288 TSecr=0 WS=128
2    0.044035    10.0.0.18    192.168.8.51    TCP    76    9090 → 48044 [SYN, ACK] Seq=0 Ack=1 Win=64296 Len=0 MSS=1380 SACK_PERM=1 TSval=1848362481 TSecr=1985263288 WS=128
3    0.044078    192.168.8.51    10.0.0.18    TCP    66    48044 → 9090 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1985263332 TSecr=1848362481
4    0.044463    192.168.8.51    10.0.0.18    TLSv1.3    583    Client Hello
D. h. die Verbindung/Kommunikation über den WG-Tunnel funktioniert.
Dann kann es auch m. E., wie hier schon vermutet worden ist, nur an der Konfiguration des Webservers bzw. des Clienten liegen.
 
  • Like
Reaktionen: frank_m24

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
18,136
Punkte für Reaktionen
112
Punkte
63
Ich denke, wenn der webserver (wireguard client) die wg-IP 10.0.0.18 hat, liefert er auch alle Anfragen an beliebige ports zurück.
Nein, das tut er nicht. Man muss dem Webserver explizit sagen, dass er nicht nur auf 192.168.18.88 lauschen soll, sondern auch auf 10.0.0.18. Außerdem kann es für den Webserver ein Unterschied sein, ob die Anfrage http://192.168.18.88, http://10.0.0.18 oder http://www.homepage.de ist - völlig egal, über welches Netzwerkinterface die Anfrage reinkommt. Die Konfiguration deines Servers muss zu den Aufrufen passen, die du in deinen Clients absetzt. Das meinte ich mit vHosts. Auf einem Webserver können komplett unterschiedliche Webseiten ausgeliefert werden, die nur anhand der Adresse, die mal in den Browser eingetippt wurde, unterschieden werden.

Was auch sein kann: Webserver und drum herum arbeiten teilweise mit Reverse DNS Lookups, und sei es nur für Logs. Heißt, sie überprüfen beim Übertragen der Daten die Hostnamen der beteiligten Endgeräte. Eine solche Auflösung wird für die wg Adressen vermutlich nicht funktionieren, das kann sich deutlich auf Ladezeiten auswirken.

Ich weiß nicht, ob wir das richtige Forum für dein Anliegen sind. Das Problem liegt definitiv auf Applikationsebene. Da sind wir hier eher nicht so die Experten.
 
Zuletzt bearbeitet:

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Aber Danke für die Hinweise. Dann grabe ich mich jetzt mal in die configs der ausliefernden webserver. Das ist nicht ganz trivial, da es z.B. bei project-cockpit.org wenig doku dazu gibt und andere Dienste auf meinem client kommen aus docker containern, die vielleicht auch jeweils ihre eigenen Vorstellungen haben.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,249
Punkte für Reaktionen
1,393
Punkte
113
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:~ $
 
Zuletzt bearbeitet:

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Vielen Dank an euch, daß ihr euch Zeit nehmt, meinen Fall zu diskutieren und zu helfen. Ich bin sehr beeindruckt!
Ich habe, um die laufenden Dienste nicht zu stören, mal lighttpd installiert. Der liefert die Startseite unverschlüsselt problemlos aus. Der Hase liegt also offenbar - wie von euch vermutet - in der Verschlüsselung begraben. Die muß ich jetzt loswerden. Die Dienste laufen ohnehin nur im LAN. Die der Mitschnitt des Aufrufs von lighttpd:
Code:
No.    Time    Source    Destination    Protocol    Length    Info
1    0.000000    192.168.8.51    10.0.0.18    TCP    66    52032 → 80 [FIN, ACK] Seq=1 Ack=1 Win=501 Len=0 TSval=1996876381 TSecr=1875150441
2    0.000094    192.168.8.51    10.0.0.18    TCP    74    52034 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1996876381 TSecr=0 WS=128
3    0.043492    10.0.0.18    192.168.8.51    TCP    68    80 → 52032 [ACK] Seq=1 Ack=2 Win=502 Len=0 TSval=1875195584 TSecr=1996876381
4    0.043510    10.0.0.18    192.168.8.51    TCP    76    80 → 52034 [SYN, ACK] Seq=0 Ack=1 Win=64296 Len=0 MSS=1380 SACK_PERM=1 TSval=1875195584 TSecr=1996876381 WS=128
5    0.043525    192.168.8.51    10.0.0.18    TCP    66    52034 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=1996876425 TSecr=1875195584
6    0.043714    192.168.8.51    10.0.0.18    HTTP    709    GET / HTTP/1.1
7    0.068286    10.0.0.18    192.168.8.51    TCP    68    80 → 52034 [ACK] Seq=1 Ack=644 Win=64256 Len=0 TSval=1875195625 TSecr=1996876425
8    0.070222    10.0.0.18    192.168.8.51    HTTP    270    HTTP/1.1 304 Not Modified
9    0.070241    192.168.8.51    10.0.0.18    TCP    66    52034 → 80 [ACK] Seq=644 Ack=205 Win=64128 Len=0 TSval=1996876452 TSecr=1875195625
10    2.421760    192.168.8.51    10.0.0.18    HTTP    709    GET / HTTP/1.1
11    2.452401    10.0.0.18    192.168.8.51    TCP    68    80 → 52034 [ACK] Seq=205 Ack=1287 Win=64256 Len=0 TSval=1875198004 TSecr=1996878803
12    2.456489    10.0.0.18    192.168.8.51    HTTP    270    HTTP/1.1 304 Not Modified
13    2.456509    192.168.8.51    10.0.0.18    TCP    66    52034 → 80 [ACK] Seq=1287 Ack=409 Win=64000 Len=0 TSval=1996878838 TSecr=1875198004
14    5.856559    192.168.8.51    10.0.0.18    HTTP    647    GET / HTTP/1.1
15    5.893491    10.0.0.18    192.168.8.51    TCP    68    80 → 52034 [ACK] Seq=409 Ack=1868 Win=64256 Len=0 TSval=1875201439 TSecr=1996882238
16    5.909050    10.0.0.18    192.168.8.51    TCP    1434    80 → 52034 [ACK] Seq=409 Ack=1868 Win=64256 Len=1368 TSval=1875201440 TSecr=1996882238 [TCP segment of a reassembled PDU]
17    5.909073    192.168.8.51    10.0.0.18    TCP    66    52034 → 80 [ACK] Seq=1868 Ack=1777 Win=63104 Len=0 TSval=1996882290 TSecr=1875201440
18    5.920746    10.0.0.18    192.168.8.51    TCP    1434    80 → 52034 [PSH, ACK] Seq=1777 Ack=1868 Win=64256 Len=1368 TSval=1875201440 TSecr=1996882238 [TCP segment of a reassembled PDU]
19    5.920764    192.168.8.51    10.0.0.18    TCP    66    52034 → 80 [ACK] Seq=1868 Ack=3145 Win=63104 Len=0 TSval=1996882302 TSecr=1875201440
20    5.929817    10.0.0.18    192.168.8.51    HTTP    917    HTTP/1.1 200 OK  (text/html)

Update: Ich glaube, ich bin vom cache des browsers belogen worden. Ein
Code:
curl http://10.0.018
ist auch zäh.
 
Zuletzt bearbeitet:

frank_m24

IPPF-Urgestein
Mitglied seit
20 Aug 2005
Beiträge
18,136
Punkte für Reaktionen
112
Punkte
63
Gibt es davon auch einen Paketdump, an dem man erkennen kann, dass es ab einer gewissen Paketgröße Probleme gibt?
 

rspring

Neuer User
Mitglied seit
17 Nov 2006
Beiträge
183
Punkte für Reaktionen
1
Punkte
18
Ich habe im freetz MTU auf 1280 herabgesetzt und vor allem im client auch
Code:
MTU = 1280
eingetragen. das scheint der Schlüssel zu sein. Offenbar reicht es nicht, daß der Server die MTU vorgibt, sondern es muß auch der client explizit darauf gesetzt werden. So sausen die Daten.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,249
Punkte für Reaktionen
1,393
Punkte
113
Das dürfte zwar vom Wert her etwas übertrieben sein (es kamen ja auch größere Pakete noch durch), aber Hauptsache es läuft jetzt.

Ich will trotzdem noch einmal darauf hinweisen, daß eine Änderung an einem Parameter, deren Wirksamkeit man nicht gleichzeitig auch verifiziert, als "Beweis" halt nichts taugt. Und wenn eine MTU nicht automatisch "ermittelt" wird (bei IPv6 geht's praktisch gar nicht mehr ohne das, weil's einfach zu viele Variablen gibt, was in einem Paket ("auf dem Draht") noch Platz belegen könnte - nur funktionieren diese Mechanismen innerhalb von VPN-Tunneln auch eher selten), dann ist halt auch zu erwarten, daß man das auf beiden Seiten korrekt einstellen muß, auch wenn man's "manuell" macht.

Bei WG gibt es m.W. keine gesonderte "Verständigung" zwischen den Peers (EDIT: einseitige Änderungen der MTU müßte man (für TCP zumindest) also ggf. über iptable mit TCPMSS-Target machen) und WG fragmentiert seinerseits auch keine PDUs (jedenfalls soweit ich das weiß), das macht das verwendete Protokoll ja gerade so simpel und gleichzeitig ist bei WG aber auch der Overhead vergleichsweise groß - da kommen (bei einem WG-Tunnel über IPv6) dann 40 Byte für die IP-Header, 8 Byte für den UDP-Header und 32 Byte für die WG-Infos zusammen ... das ergibt dann (bei einer MTU von 1500 Byte für die physische Verbindung - bei PPPoE-Kapselung gehen da noch einmal 8 Byte ab, daher auch die MTU von 1492 bei PPPoE-DSL) die bekannten 1420 Byte. Wobei man dann (an einem DSL-Anschluß mit PPPoE und IPv6) eigentlich nur noch die zusätzlichen 8 Byte für PPPoE abziehen müßte - wenn das auf beiden Seiten paßt, sollte dann auch ein Tunnel mit einer MTU von 1412 funktionieren. Allerdings könnten zusätzliche IP-Optionen auch noch weiteren Platz im Paket belegen - da hilft dann auch eine (ausführliche) Analyse der Header, um so etwas zu erkennen.



Es wäre nett, wenn Du den Thread dann noch auf "erledigt" (oder "gelöst" o.ä.) setzen könntest, dann erkennt der/die Nächste schon bei der Treffer-Anzeige in der Suchmaschine, daß es hier eine Lösung gab, die ggf. auch ihm/ihr helfen könnte. Danke.
 
Zuletzt bearbeitet:

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via