Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Jose D 29. 04. 2024, 16:43:26
-
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
$
-
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 :D ))
... 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?
-
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.
-
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.
-
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í.