WireGuard nad IPv6 DS-Lite rozpoznání MTU

[Jose D]

debugoval jsem si doma (za "UPC" / Vodafone, compal, dslite) wireguard ve scénáři road warrior, v podstatě veškeré konfigy v defaultu..
Nu a nějak mi to nešlapalo.

Zjistil jsem, že mi to nějak kazí snížení MTU na Compalu způsobené balením ipv4 do ipv6 packetů.

Zafixování MTU wireguardu na 1400 to vyřeší.

Je tohle očekávané chování? Nemělo by se to nějak "samo" řešit pomocí fragmentace atp?

Tady je vidno, že iperfem data na začátku tečou, pak už ne:

$ iperf3 -c 10.9.0.1
Connecting to host 10.9.0.1, port 5201
[  5] local 10.9.0.3 port 46894 connected to 10.9.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   331 KBytes  2.71 Mbits/sec    2   1.34 KBytes       #<-----cosi projde na zacatku, pak uz ne.
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.34 KBytes       
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.34 KBytes       
^C[  5]   3.00-3.29   sec  0.00 Bytes  0.00 bits/sec    0   1.34 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.29   sec   331 KBytes   825 Kbits/sec    3             sender
[  5]   0.00-3.29   sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: interrupt - the client has terminated
$

tracepath indikuje snížení::


$ tracepath vm1.nekde.nekde.cz
 1?: [LOCALHOST]                      pmtu 1500
 1:  compalhub.home                                        2.668ms
 1:  compalhub.home                                        2.398ms
 2:  compalhub.home                                        2.219ms pmtu 1460 #<-----ha
 2:  no reply
 3:  no reply
 4:  ae8-100-ucr1.czs.cw.net                              11.764ms
 5:  ae8-ucr1.pra.cw.net                                  11.922ms
 6:  prag-b4-link.ip.twelve99.net                         14.411ms asymm  5
....
^C
$

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

V jakém.směru chodí nadměrný náklad? A  pro odchozí nebo příchozí spojení ?

Já na routeru mám  FORWArD -o wf3g -j tcpmss -clamp-mss-to-pmtu

( hint: zkus iperf3 -R (opačný směr) a iperf3 -b 40k(abys to stíhal číst  ))
... iperf3 --bidi jaksi nefunguje

Na kterých endpointech běží wireguard démoni a jaký mají os ajaká je tam implementace?

O zafixování provadíš jak? Co hlásí ip link ? Je tam i hodnota mtu?

[Martin Sivák]

Wireguard používá UDP a UDP rozumně řízenou fragmentaci neumí.

Takže ano, mám na ex-UPC síti stejný problém, ale protože navíc provozuju ten tunel po IPv6, tak jsem musel použít MTU 1392.

[Jose D]

V jakém.směru chodí nadměrný náklad? A  pro odchozí nebo příchozí spojení ?

no, při tom iperf3 testu je defaultní test upload. UPC compal byl při daném testu na straně klienta. Takže odchozí spojení?

Já na routeru mám  FORWArD -o wf3g -j tcpmss -clamp-mss-to-pmtu

No a to máš na stroji který je wg klient, nebo wg koncentrátor, nebo je to něco před UPC/Vodafone compalem?
A je to schopný vůbec ovlivnit udp provoz wireguardu? TCP věci by to asi opravit mohlo.

Na kterých endpointech běží wireguard démoni a jaký mají os ajaká je tam implementace?

je to trochu zoo, koncentrátor je arm server na Oracle Linuxu,
jeden klient je Mikrotik ROS7, druhý je recentní Ubuntu x86_64.

O zafixování provadíš jak?

ve wireguardu (tedy v /etc/wireguard či v GUI mikrotiku ) / (zatím jsem to konfiguroval konzistentně, tedy měnil jsem to všude stejně)
nastavím pevnou MTU, kterou jsem si empiricky určil tím, že jsem snižoval MTU, a v momentě když to začalo fungovat jsem tu hodnotu použil.

[Jose D]

Takže ano, mám na ex-UPC síti stejný problém

díky za potvrzení.

Já jsem měl z wireguardu takový dojem, že by si to MTU mohl pořešit na aplikační úrovni sám.
Ale jestli v podstatě reprodukuju tvoje pozorování, tak tomu tak není.

[Reklama]