Niska prędkość WireGuard: jak znaleźć przyczynę?

Przyczyny niskiej wydajności WireGuard

Niska wydajność WireGuard wynika z jednej z czterech przyczyn, przy czym prawdopodobieństwo ich wystąpienia jest różne. Pierwszą jest MTU (maximum transmission unit): tunel tworzy pakiety zbyt duże dla jednego z łączy na trasie, przez co transfery masowe ulegają zawieszeniu, podczas gdy małe pakiety są przesyłane poprawnie. Drugą jest sama trasa, która stanowiła ograniczenie jeszcze przed zestawieniem tunelu. Trzecią jest obciążenie procesora na współdzielonym VPS, gdzie szyfrowanie konkuruje o zasoby z innymi użytkownikami na tym samym hoście. Czwartą jest łącze samego partnera (peer).

Należy sprawdzać je w tej właśnie kolejności. MTU jest pierwsze, ponieważ jest to jedyna przyczyna z listy wprowadzana przez sam WireGuard, a jej objawy nie przypominają typowego spowolnienia. Błędne MTU zazwyczaj objawia się tunelem, który łączy się natychmiast, odpowiada na ping, pozwala na logowanie przez SSH, a następnie zawiesza się przy pierwszej próbie skopiowania pliku.

Jeden objaw warto wykluczyć przed przystąpieniem do jakichkolwiek działań. Jeśli każda nowa witryna ładuje się z kilkusekundowym opóźnieniem, a następnie pobiera z pełną prędkością, problemem jest rozwiązywanie nazw, a nie przepustowość. DNS przez WireGuard posiada własne tryby awarii i żadna zmiana MTU ich nie naprawi.

Dlaczego MTU w WireGuard wynosi 1420?

Każdy pakiet wysyłany do tunelu jest szyfrowany i pakowany wewnątrz nowego pakietu. Opakowanie zajmuje określoną liczbę bajtów, które są odejmowane od dostępnego ładunku (payload).

Nagłówek danych WireGuard ma 32 bajty: 4 bajty pola typu, 4 bajty indeksu odbiorcy, 8 bajtów licznika oraz 16-bajtowy znacznik uwierzytelniania Poly1305. Wokół tego znajduje się nagłówek UDP o rozmiarze 8 bajtów. Całość otacza zewnętrzny nagłówek IP, który ma 20 bajtów dla IPv4 oraz 40 bajtów dla IPv6. Łączna enkapsulacja wynosi zatem 60 bajtów, gdy Endpoint jest adresem IPv4, oraz 80 bajtów, gdy jest to IPv6. Strona protokołu WireGuard dokumentuje układ wiadomości, z którego wynikają te liczby.

wg-quick nie zgaduje tych wartości. Odczytuje MTU interfejsu, który kieruje ruch do Endpoint, a następnie odejmuje 80. Na typowej ścieżce Ethernet o rozmiarze 1500 bajtów daje to 1420, czyli wartość, którą wyświetla ip link show wg0. Odejmuje 80 zamiast 60, aby ta sama liczba pozostała bezpieczna w przypadku, gdy punkt końcowy zostanie osiągnięty przez IPv6, gdzie nagłówek zewnętrzny jest o 20 bajtów większy.

[
  {
    "label": "Ethernet, IPv4 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1440
  },
  {
    "label": "Ethernet, IPv6 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1420
  },
  {
    "label": "PPPoE DSL, IPv4 endpoint",
    "path_mtu": 1492,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1432
  },
  {
    "label": "Extra tunnel in the path",
    "path_mtu": 1400,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1320
  }
]

Te 4 wiersze to wynik działań arytmetycznych, a nie pomiarów. Na czystej ścieżce 1500 bajtów z punktem końcowym IPv4, 1440 zmieściłoby się, więc wartość domyślna 1420 pozostawia 20 bajtów niewykorzystanych. Ten margines jest zamierzony i nie stanowi problemu dla użytkownika.

Ostatni wiersz jest tym, który powoduje problemy. Gdy którekolwiek łącze na ścieżce obsługuje tylko 1400 bajtów, tunel ustawiony na 1420 generuje zewnętrzny pakiet 1500 bajtów dla każdego segmentu o pełnym rozmiarze, co przekracza limit łącza o 100 bajtów. Wartością, która pasuje, jest 1320.

Nie należy również kopiować wartości 1320. MTU ścieżki jest właściwością danej trasy, a jedynym sposobem na jej poznanie jest wykonanie pomiaru.

Jak objawia się nieprawidłowe MTU

Awaria nie przebiega stopniowo. Występuje wyraźny podział na pakiety małe i duże.

• ping przez tunel działa przy każdym standardowym rozmiarze.
• Logowanie przez SSH kończy się powodzeniem, a wpisywanie znaków jest responsywne.
• curl -I https://example.com natychmiast zwraca nagłówki.
• curl https://example.com dla dużej strony zawiesza się po przesłaniu kilku pierwszych kilobajtów.
• scp dużego pliku rozpoczyna się, a następnie zatrzymuje przy określonym procencie.
• Sesja SSH zamraża się w momencie uruchomienia polecenia generującego dużą ilość danych wyjściowych.

Wszystko to dzieje się, ponieważ połączenie TCP tworzy segmenty o pełnym rozmiarze dopiero wtedy, gdy musi przesłać większą ilość danych. Uścisk dłoni (handshake) oraz pierwsze żądanie mieszczą się w limicie każdego MTU na ścieżce. Zastój zaczyna się przy pierwszym segmencie o pełnym rozmiarze, dlatego połączenie wygląda na sprawne aż do momentu, w którym staje się bezużyteczne.

Pakiet zewnętrzny większy niż MTU kolejnego łącza spotyka jeden z dwóch losów.

Jest fragmentowany. Router dzieli go na części, a punkt końcowy składa je ponownie. Transfer działa, choć jest wolniejszy, ponieważ za jeden pakiet płaci się dwoma, a odbiorca musi utrzymywać stan do momentu nadejścia wszystkich części. Utrata jednego fragmentu powoduje utratę całego oryginalnego pakietu, więc ścieżka z 1% stratą zachowuje się znacznie gorzej. Wiele firewalli odrzuca fragmenty IP zgodnie z polityką bezpieczeństwa, co zmienia ten scenariusz w kolejny.

Jest odrzucany, z powiadomieniem lub bez. Router, który nie fragmentuje pakietów, wysyła do nadawcy komunikat ICMP (internet control message protocol) o treści "fragmentation needed", zawierający informację o akceptowalnym MTU. Jeśli komunikat dotrze, mechanizm path MTU discovery działa poprawnie, a nadawca samodzielnie zmniejsza rozmiar segmentu. Wiele sieci filtruje ICMP, więc komunikat często nie dociera. Żaden inny mechanizm nie zgłasza utraty. To jest tzw. czarna dziura: pakiet wychodzi, nic nie wraca, w żadnym dzienniku po obu stronach nie pojawia się błąd, a transfer wisi do momentu przekroczenia czasu oczekiwania (timeout).

Jak ustalić właściwą wartość MTU?

Zmierz ścieżkę, a następnie wykonaj odejmowanie. Testuj warstwę podkładową, a nie tunel, więc wyślij ping na publiczny adres serwera z klienta i zabroń fragmentacji.

ping -M do -s 1472 -c 3 203.0.113.10

-M do ustawia bit DF (don't fragment), dzięki czemu żaden router na drodze nie może podzielić pakietu. -s to rozmiar ładunku ICMP. Pełny pakiet IPv4 to ten ładunek plus 8 bajtów nagłówka ICMP oraz 20 bajtów nagłówka IP, więc -s 1472 wysyła dokładnie 1500 bajtów do sieci.

Istotne są trzy wyniki. Poprawne odpowiedzi oznaczają, że 1500 bajtów mieści się w limicie i MTU nie jest problemem. Błąd lokalny oznacza, że własny interfejs jest już mniejszy niż żądana wartość:

ping: local error: message too long, mtu=1500

Odpowiedź od routera pośredniczącego wskazuje bezpośrednio na rozwiązanie i na tym można zakończyć:

From 203.0.113.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

100% utraty pakietów przy 1472 bajtach, przy poprawnych odpowiedziach dla mniejszych rozmiarów, oznacza tzw. czarną dziurę. Żaden router nie przesyła informacji zwrotnej, więc należy znaleźć granicę metodą połowienia. Zachowaj rozmiar, który działa, oraz ten, który zawodzi, przetestuj punkt środkowy i przesuń odpowiednią granicę w zależności od wyniku. Każda runda dzieli pozostały zakres na pół, więc pięć lub sześć rund jest wystarczające.

ping -M do -s 1472 -c 3 203.0.113.10   # 100% loss, so 1500 is too big
ping -M do -s 1272 -c 3 203.0.113.10   # replies, so 1300 fits
ping -M do -s 1372 -c 3 203.0.113.10   # replies, so 1400 fits
ping -M do -s 1422 -c 3 203.0.113.10   # 100% loss, so 1450 is too big
ping -M do -s 1397 -c 3 203.0.113.10   # 100% loss, so 1425 is too big
ping -M do -s 1384 -c 3 203.0.113.10   # 100% loss, so 1412 is too big

tracepath wykonuje to samo wyszukiwanie automatycznie i warto uruchomić je raz przed rozpoczęciem ręcznej bisekcji:

tracepath -n 203.0.113.10

Ostatnia linia raportuje znalezioną wartość:

     Resume: pmtu 1492 hops 12 back 12

Traktuj oba narzędzia jako punkt wyjścia, a nie dowód. Niektóre hosty ograniczają szybkość lub całkowicie odrzucają ICMP, więc bisekcja może wskazać mniejsze MTU niż faktycznie obsługuje ścieżka. Transfer, który kończył się niepowodzeniem, jest prawdziwym testem.

Zastosuj wartość na żywo, ponieważ błędne założenie można cofnąć jednym poleceniem:

sudo ip link set mtu 1320 dev wg0

Ponów transfer, który zawieszał się wcześniej. Jeśli zakończy się powodzeniem, utrwal wartość w bloku [Interface] klienta:

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
MTU = 1320

sudo wg-quick down wg0 && sudo wg-quick up wg0
ip link show wg0

ip link show wg0 powinno teraz wyświetlić mtu 1320. Jeśli nadal wyświetla starą wartość, wg-quick nie odczytało edytowanego pliku. Sprawdź, czy edytowano /etc/wireguard/wg0.conf oraz czy MTU znajduje się w sekcji [Interface], a nie [Peer], gdzie jest ignorowane.

MTU jest właściwością interfejsu i nigdy nie jest negocjowane między partnerami. Ustawienie go tylko na kliencie zmniejsza pakiety wysyłane przez klienta. Serwer nadal tworzy pakiety zgodnie z własnym MTU dla wg0, więc pobieranie danych może nadal wpadać w czarną dziurę, nawet jeśli wysyłanie zacznie działać. Ustaw wartość na obu końcach lub zastosuj MSS clamping na serwerze.

Dlaczego MSS clamping naprawia tylko TCP

Jeśli serwer przekazuje ruch dla swoich partnerów, co ma miejsce w każdej standardowej konfiguracji WireGuard VPS z użyciem NAT (network address translation), jedna reguła naprawia TCP dla każdego partnera i pozwala uniknąć ręcznego ustawiania wartości na każdym kliencie, nad którym nie sprawuje się kontroli.

MSS (maximum segment size) to opcja TCP, którą każda ze stron umieszcza w pakiecie SYN, aby określić, jak duży segment jest w stanie odebrać. Clamping nadpisuje tę opcję w locie, aby dopasować ją do rzeczywistego MTU trasy, dzięki czemu obie strony uzgadniają mniejszy segment przed przesłaniem jakichkolwiek danych. Rozwiązanie to działa, ponieważ odbywa się podczas nawiązywania połączenia i nie zależy od komunikatów ICMP, które są często blokowane na trasie.

W przypadku nftables należy dodać poniższą tabelę do /etc/nftables.conf pod istniejącymi tabelami:

table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    tcp flags syn tcp option maxseg size set rt mtu
  }
}

Przeładuj konfigurację za pomocą sudo systemctl reload nftables. Na systemach z iptables odpowiednikiem jest jedna linia:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Zweryfikuj, czy reguła znajduje się na ścieżce, którą pokonują pakiety. Uruchom sudo nft list table inet mangle lub sudo iptables -t mangle -L FORWARD -n -v w trakcie otwierania nowych połączeń przez klienta i obserwuj wzrost licznika. Licznik pozostający na zerze oznacza, że pakiety nie przechodzą przez ten punkt kontrolny (hook), więc reguła nie działa.

Teraz o ograniczeniach. Clamping obejmuje wyłącznie TCP i dotyczy tylko ruchu przekazywanego (forwarded). Usługa działająca bezpośrednio na serwerze WireGuard nigdy nie przechodzi przez hook forward, więc nie podlega clampingowi. Reguła wpływa również tylko na połączenia otwarte po jej załadowaniu: istniejące sesje zachowują MSS uzgodniony wcześniej.

Ruch UDP pozostaje nienaruszony, ponieważ UDP nie posiada procesu nawiązywania połączenia, w którym można by dokonać modyfikacji. Większość ruchu UDP i tak przechodzi poprawnie. QUIC, protokół transportowy dla HTTP/3, samodzielnie sonduje użyteczny rozmiar pakietu i celowo zaczyna od małych wartości. Problemy sprawia jedynie UDP, który wysyła jeden duży datagram i oczekuje jego dostarczenia, na przykład odpowiedź DNSSEC (DNS security extensions) o rozmiarze powyżej 1400 bajtów. Takie zapytania przekraczają limit czasu i są ponawiane przez TCP, co dla użytkownika objawia się wolniejszym działaniem strony zamiast jej całkowitej niedostępności.

Czy procesor VPS stanowi ograniczenie?

WireGuard szyfruje dane za pomocą ChaCha20-Poly1305, a wymianę kluczy realizuje algorytmem Curve25519. W ścieżce przetwarzania danych nie występuje AES, co prowadzi do błędnego wniosku: instrukcje AES-NI w procesorze nie przyspieszają działania WireGuard. Serwer wspierający AES-NI nie oferuje żadnej funkcji zwiększającej wydajność WireGuard. Algorytm ChaCha20 wybrano ze względu na jego szybkość w implementacjach programowych, nawet na procesorach pozbawionych akceleracji kryptograficznej.

Nie oznacza to, że WireGuard nie obciąża systemu. Na VPS z jednym vCPU ten sam rdzeń obsługuje szyfrowanie, przerwania sieciowe oraz zadania aplikacji.

Wydajność należy mierzyć podczas trwania transferu:

sudo apt install -y sysstat
mpstat -P ALL 1

Należy przeanalizować trzy kolumny. %soft oznacza czas softirq, w którym jądro przetwarza pakiety. %steal to czas, w którym hypervisor przydzielił zasoby innym maszynom. %idle to czas dostępny dla użytkownika.

Wartość %soft bliska 100 na jedynym dostępnym rdzeniu oznacza, że serwer osiągnął limit przetwarzania pakietów. Jest to realne ograniczenie, które można zniwelować poprzez dodanie kolejnych rdzeni. Wartość top wskazuje na ksoftirqd/0 na szczycie listy procesów w tym samym momencie, co potwierdza ten sam wniosek z innej perspektywy.

Wartość %steal przekraczająca kilka procent oznacza, że ograniczenie nie wynika z konfiguracji użytkownika, lecz z nadmiernego współdzielenia zasobów hosta (oversubscription), przez co vCPU oczekuje na dostęp do rdzenia fizycznego. Jest to częste zjawisko w najtańszych planach współdzielonych, którego intensywność zmienia się w ciągu dnia. Steal time od sąsiada wymaga odrębnej analizy; żadna zmiana wartości MTU nie rozwiąże tego problemu.

Dodatkowym czynnikiem jest implementacja używana przez klienta. Moduł jądra Linux stanowi najszybszą ścieżkę i rozprasza szyfrowanie między wiele rdzeni. wireguard-go, czyli implementacja w przestrzeni użytkownika, jest wolniejsza. Korzystają z niej klienci macOS oraz iOS, ponieważ systemy te nie pozwalają aplikacjom na ładowanie modułów jądra.

Czy problemem jest ścieżka, czy łącze samego partnera?

Przed przystąpieniem do optymalizacji należy pobrać dwa pomiary z tego samego klienta w odstępie kilku minut: przepustowość bez tunelu oraz przepustowość z tunelem. Bez tej pary danych wszelkie działania są jedynie zgadywaniem.

Uruchom iperf3 -s na serwerze. Test bezpośredni wymaga otwarcia portu TCP 5201 na adresie publicznym, więc otwórz go na czas trwania testu, a następnie usuń regułę. Upewnij się, że port jest ponownie zamknięty, zamiast zakładać to w ciemno.

# on the client, outside the tunnel
iperf3 -c 203.0.113.10
# then through the tunnel
iperf3 -c 10.8.0.1

Jeśli obie wartości są zbliżone, WireGuard generuje minimalny narzut, a ograniczeniem jest sama ścieżka sieciowa. Jeśli przepustowość tunelu jest znacznie niższa od bezpośredniej, podczas gdy %soft pozostaje na niskim poziomie, wróć do ustawień MTU. Fragmentacja obniża przepustowość bez przerywania połączenia, co objawia się jako procentowa strata, a nie zawieszenie sesji.

Przetestuj oba kierunki, ponieważ łącza domowe są zazwyczaj asymetryczne. iperf3 -c 10.8.0.1 -R odwraca kierunek przepływu, więc serwer wysyła dane. Klient na łączu 500/20 nigdy nie prześle do tunelu więcej niż 20 Mbit danych wysyłanych i żadna zmiana po stronie serwera tego nie zmieni.

Następnie przeprowadź test z użyciem równoległych strumieni:

iperf3 -c 10.8.0.1 -P 4

Jeśli cztery strumienie przesyłają łącznie znacznie więcej danych niż jeden, oznacza to, że pojedyncze połączenie TCP nie jest w stanie w pełni wykorzystać ścieżki. Przepustowość jednego strumienia jest ograniczona przez okno odbiorcze podzielone przez czas podróży w obie strony (RTT), więc ścieżka o opóźnieniu 150 ms wymaga dużego okna, aby przesłać znaczną ilość danych. Sprawdź własne limity:

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Trzecia wartość w każdym z tych parametrów to maksimum, do którego system Linux może automatycznie dostosować okno. Utrata pakietów również drastycznie ogranicza pojedynczy strumień, ponieważ mechanizmy kontroli przeciążenia TCP reagują na straty, a długa ścieżka sprawia, że odzyskiwanie danych jest kosztowne. Uruchom mtr -rwc 100 203.0.113.10 z poziomu klienta przez sto cykli, aby sprawdzić, w którym miejscu trasy pojawiają się straty. Straty, które zaczynają się na jednym przeskoku i utrzymują do końca trasy, są rzeczywiste. Straty na pojedynczym środkowym przeskoku, które znikają na kolejnych, wynikają z faktu, że dany router nadaje niski priorytet pakietom ICMP i nie mają one znaczenia.

Aby uzyskać powtarzalny obraz wydajności samego serwera, niezależnie od sieci, przeprowadź benchmark VPS zgodnie z udokumentowaną metodą, co pozwoli na ponowne wykonanie tego samego testu po wprowadzeniu zmian i porównanie wyników w identycznych warunkach.

Czego WireGuard nie naprawi

WireGuard to tunel. Nie może być szybszy niż najwolniejsze łącze na ścieżce, z której korzysta, a jego dodanie zawsze nieznacznie spowalnia połączenie.

WireGuard nie kompresuje danych. Nie istnieje odpowiednik comp-lzo z OpenVPN i nie planuje się jego wprowadzenia, ponieważ kompresja przed szyfrowaniem ujawnia informacje o tekście jawnym. Większość danych przesyłanych masowo jest już skompresowana, więc w praktyce nie stanowi to żadnej straty. Jest to jedna z istotnych różnic, które należy rozważyć, porównując WireGuard z OpenVPN, i jest to świadomy wybór projektowy.

Pełny tunel zmienia trasę każdego pakietu. Ruch, który wcześniej biegł od użytkownika do pobliskiej sieci CDN (content delivery network), teraz biegnie od użytkownika do serwera VPS, a następnie do CDN. Jeśli VPS znajduje się na innym kontynencie, każde żądanie ponosi koszt tego objazdu, a czas odpowiedzi (round trip time) odpowiednio rośnie. Żadna wartość konfiguracyjna tego nie skróci. Należy przenieść VPS bliżej lub użyć tunelu dzielonego (split tunnel), aby tylko ruch wymagający VPN pokonywał dłuższą drogę. O tym, który ruch dokąd trafia, decyduje wyłącznie AllowedIPs, a routing kluczy kryptograficznych wyjaśnia, jak podejmowana jest ta decyzja.

Limity dostawcy znajdują się poza tunelem i łatwo o nich zapomnieć. Plan z miesięcznym limitem transferu często ogranicza przepustowość portu do znacznie niższej prędkości po wyczerpaniu limitu, przez co tunel sprawia wrażenie uszkodzonego. Należy sprawdzić panel zarządzania przed poświęceniem wieczoru na diagnostykę MTU.

PersistentKeepalive nie wpływa na przepustowość. Istnieje po to, aby utrzymać mapowanie NAT otwarte, dzięki czemu serwer może nadal uzyskać dostęp do klienta znajdującego się za domowym routerem. Obniżenie tej wartości poniżej 25 sekund dodaje jedynie zbędne pakiety i niczego nie naprawia.

Pomiary w podanej kolejności

1. Odtwórz problem i określ, czy występuje zawieszenie, czy równomierne spowolnienie. Zawieszenie wskazuje na problem z MTU. Równomierne spowolnienie nie.
2. Wykonaj bisekcję za pomocą ping -M do z klienta na publiczny adres serwera i zanotuj path MTU.
3. Odejmij 80, ustaw tak wyliczone MTU na interfejsie wg0 po obu stronach i ponownie przetestuj transfer, który kończył się niepowodzeniem.
4. Dodaj MSS clamping na serwerze, jeśli przekazuje on ruch dla peerów.
5. Uruchom mpstat -P ALL 1 podczas transferu i odczytaj wartości %soft oraz %steal.
6. Uruchom iperf3 poza tunelem i wewnątrz niego, w obu kierunkach, dla pojedynczego strumienia oraz z użyciem -P 4.
7. Uruchom mtr -rwc 100 do serwera i sprawdź, czy utrata pakietów utrzymuje się do ostatniego przeskoku.

Zmień plan serwera dopiero wtedy, gdy krok 5 wykaże, że ograniczeniem jest wydajność CPU. Kroki od 1 do 4 nie generują kosztów i rozwiązują większość zgłoszeń dotyczących wolnego działania tunelu.

FAQ

Dlaczego tunel WireGuard działa szybko przy pingowaniu, ale wolno podczas pobierania plików?

Taka rozbieżność jest typowym objawem problemu z MTU. Małe pakiety mieszczą się w każdym łączu na trasie, dlatego ping oraz logowanie przez SSH działają poprawnie. Transfer masowy wysyła segmenty o pełnym rozmiarze, których wersja enkapsulowana przekracza limit dopuszczalny przez niektóre łącza. Jeśli router odrzuci takie pakiety bez odesłania komunikatu ICMP, utrata danych nie zostanie zgłoszona, a transfer zawiśnie. Należy wyznaczyć MTU ścieżki za pomocą metody bisekcji ping -M do do publicznego adresu serwera, odjąć 80 bajtów na enkapsulację i ustawić wynik jako MTU dla wg0 na obu końcach.

Jakie MTU ustawić dla WireGuard?

Nie istnieje uniwersalna wartość, dlatego domyślne 1420 nie sprawdza się w każdym przypadku. 1420 to 1500 minus 80 bajtów nagłówka WireGuard, nagłówka UDP oraz zewnętrznego nagłówka IPv6. Jeśli ścieżka przesyłu obsługuje mniej niż 1500 bajtów, co jest typowe dla łączy PPPoE DSL oraz sytuacji, gdy ruch przechodzi przez inny tunel, wymagana jest mniejsza wartość. Należy najpierw zmierzyć MTU ścieżki, a następnie odjąć od niego 80.

Czy MSS clamping zastępuje ustawienie MTU?

Nie. Clamping modyfikuje opcję MSS w procesie uzgadniania TCP, dzięki czemu obie strony wysyłają mniejsze segmenty, co naprawia działanie TCP bez ingerencji w interfejs. UDP nie posiada procesu uzgadniania, więc pozostaje niepodatne na to rozwiązanie. Clamping dotyczy również tylko ruchu przekazywanego przez serwer, więc usługa działająca bezpośrednio na serwerze WireGuard nie odniesie korzyści. Należy stosować oba rozwiązania: poprawne MTU na interfejsie oraz clamping, aby obsłużyć klientów, których konfiguracji nie można zmienić.

Czy szybszy plan VPS przyspieszy WireGuard?

Tylko jeśli ograniczeniem jest procesor, co można sprawdzić jednym poleceniem. Należy uruchomić mpstat -P ALL 1 podczas trwania transferu. Wartość %soft bliska 100 na jedynym dostępnym rdzeniu oznacza, że przetwarzanie pakietów stanowi barierę i zwiększenie liczby rdzeni poprawi wydajność. Wysoka wartość %steal oznacza, że host jest przeciążony, więc rozwiązaniem jest zmiana planu lub dostawcy. Jeśli obie wartości są niskie, a tunel nadal działa wolno, procesor nie jest w pełni wykorzystany i zmiana planu na wyższy nie przyniesie efektu.

Dlaczego Mac działa wolniej niż klient Linux w tej samej sieci?

Klient Linux korzysta z modułu WireGuard w jądrze systemu, który przetwarza pakiety w przestrzeni jądra i rozkłada szyfrowanie na wiele rdzeni procesora. Aplikacje na macOS i iOS korzystają z wireguard-go, czyli implementacji w przestrzeni użytkownika, ponieważ platformy te nie pozwalają aplikacjom na ładowanie modułów jądra. Przestrzeń użytkownika kopiuje każdy pakiet między jądrem a aplikacją, co obniża przepustowość. Ta różnica jest przewidywalna i nie można jej wyeliminować za pomocą ustawień klienta.