Cara Menemukan Penyebab WireGuard Lambat

Dari mana sebenarnya kecepatan rendah WireGuard berasal

Kecepatan rendah WireGuard biasanya disebabkan oleh salah satu dari empat hal, dan kemungkinan keempatnya tidak sama. Pertama adalah MTU (maximum transmission unit): tunnel membentuk paket yang terlalu besar untuk salah satu link di jalur jaringan, sehingga transfer data dalam jumlah besar terhenti, sementara transfer kecil tetap berjalan normal. Kedua adalah jalurnya sendiri, yang sudah menjadi batas sebelum tunnel dibuat. Ketiga adalah CPU pada VPS kecil yang digunakan bersama, ketika proses enkripsi harus berbagi sumber daya dengan guest lain pada host yang sama. Keempat adalah koneksi milik peer itu sendiri.

Periksa keempatnya dalam urutan tersebut. MTU diperiksa lebih dahulu karena hanya faktor ini yang diperkenalkan oleh WireGuard, dan gejalanya sama sekali tidak tampak seperti koneksi lambat. MTU yang salah biasanya terlihat dari tunnel yang langsung terhubung, merespons ping, menerima login SSH, lalu berhenti merespons saat Anda pertama kali menyalin file.

Ada satu gejala yang perlu diperiksa sebelum semua hal tersebut. Jika setiap situs baru memerlukan beberapa detik untuk mulai dimuat, lalu data ditransfer dengan kecepatan penuh, masalahnya adalah resolusi nama, bukan throughput. DNS melalui WireGuard memiliki mode kegagalannya sendiri, dan tidak ada perubahan MTU yang dapat memperbaikinya.

Mengapa MTU WireGuard 1420?

Setiap paket yang Anda kirim ke dalam tunnel dienkripsi dan dibungkus di dalam paket baru. Pembungkus ini memerlukan byte tambahan, yang diambil dari payload Anda.

Header data WireGuard berukuran 32 byte: field tipe 4 byte, indeks penerima 4 byte, penghitung 8 byte, dan tag autentikasi Poly1305 16 byte. Di sekelilingnya terdapat header UDP berukuran 8 byte. Di sekelilingnya lagi terdapat header IP luar, yang berukuran 20 byte untuk IPv4 dan 40 byte untuk IPv6. Jadi, total enkapsulasi adalah 60 byte jika Endpoint Anda merupakan alamat IPv4 dan 80 byte jika menggunakan IPv6. Halaman protokol WireGuard mendokumentasikan tata letak pesan yang menjadi dasar angka-angka ini.

wg-quick tidak menebak nilai ini. Perintah tersebut membaca MTU antarmuka yang merutekan trafik ke Endpoint Anda, lalu mengurangkan 80. Pada jalur Ethernet biasa berukuran 1500 byte, hasilnya adalah 1420, yaitu nilai yang dicetak oleh ip link show wg0. Nilai 80 digunakan, bukan 60, agar angka yang sama tetap aman jika endpoint tersebut suatu saat diakses melalui IPv6, yang header luarnya berukuran 20 byte lebih besar.

[
  {
    "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
  }
]

4 baris tersebut merupakan perhitungan aritmetika, bukan hasil pengukuran. Pada jalur bersih berukuran 1500 byte dengan endpoint IPv4, 1440 akan dapat digunakan, sehingga nilai default 1420 menyisakan 20 byte. Margin tersebut memang disengaja dan bukan masalah Anda.

Baris terakhir adalah yang paling bermasalah. Jika salah satu link pada jalur hanya membawa 1400 byte, tunnel yang masih menggunakan 1420 menghasilkan paket luar berukuran 1480 byte pada setiap segmen berukuran penuh ketika endpoint merupakan alamat IPv4. Ukuran tersebut 80 byte lebih besar daripada yang dapat diterima link itu. Dengan endpoint IPv6, paket luarnya berukuran 1500 byte dan kelebihannya adalah 100 byte. Nilai yang muat dalam kedua kondisi tersebut adalah 1320.

Jangan menyalin 1320 begitu saja. MTU jalur merupakan karakteristik jalur Anda, dan satu-satunya cara untuk mengetahuinya adalah dengan mengukurnya.

Tanda-tanda MTU yang salah

Kegagalan ini tidak terjadi secara bertahap. Masalahnya terbagi jelas antara paket kecil dan paket besar.

• ping melalui tunnel berfungsi pada ukuran normal apa pun.
• Login SSH selesai dan pengetikan terasa responsif.
• curl -I https://example.com segera mengembalikan header.
• curl https://example.com pada halaman besar berhenti setelah beberapa kilobyte pertama.
• scp file besar dimulai, lalu berhenti pada persentase tertentu.
• Sesi SSH membeku saat Anda menjalankan perintah yang menghasilkan banyak output.

Semua ini terjadi karena koneksi TCP baru membentuk segmen berukuran penuh setelah memiliki data dalam jumlah besar untuk dikirim. Handshake dan permintaan pertama masih berada di bawah batas setiap MTU pada jalur tersebut. Masalah mulai muncul pada segmen berukuran penuh pertama. Karena itu, koneksi terlihat sehat hingga tiba-tiba tidak dapat digunakan.

Paket luar yang ukurannya melebihi MTU link berikutnya dapat mengalami salah satu dari dua hal.

Paket dipecah menjadi fragmen. Router memecah paket tersebut, lalu sisi penerima menyatukan kembali fragmen-fragmennya. Transfer tetap berfungsi, tetapi lebih lambat karena satu paket kini memerlukan dua paket, dan penerima harus menyimpan status hingga keduanya tiba. Jika satu fragmen hilang, seluruh paket asli ikut hilang. Karena itu, jalur dengan tingkat kehilangan 1% dapat berperilaku jauh lebih buruk. Banyak firewall juga membuang fragmen IP berdasarkan kebijakan. Akibatnya, kondisi ini berubah menjadi kondisi berikutnya.

Paket dibuang, dan Anda mungkin diberi tahu atau tidak. Router yang tidak akan melakukan fragmentasi mengirim pesan ICMP (internet control message protocol) "fragmentation needed" kembali ke pengirim. Pesan tersebut membawa MTU yang dapat diterima router. Jika pesan itu tiba, path MTU discovery berfungsi dan pengirim menurunkan ukuran segmennya secara otomatis. Banyak jaringan memfilter ICMP, sehingga pesan tersebut sering tidak sampai. Tidak ada mekanisme lain yang melaporkan kehilangan ini. Inilah black hole: paket keluar, tidak ada balasan yang masuk, tidak ada error yang muncul dalam log di kedua sisi, dan transfer berhenti hingga terjadi timeout.

Bagaimana cara menemukan MTU yang tepat?

Ukur jalurnya, lalu lakukan pengurangan. Uji underlay, bukan tunnel. Karena itu, ping alamat publik server dari client dan larang fragmentasi.

ping -M do -s 1472 -c 3 203.0.113.10

-M do menetapkan bit DF (don't fragment), sehingga tidak ada router di sepanjang jalur yang boleh memecah paket. -s adalah ukuran payload ICMP. Paket IPv4 lengkap terdiri atas payload tersebut ditambah 8 byte header ICMP dan 20 byte header IP. Jadi, -s 1472 menempatkan tepat 1500 byte pada jaringan.

Ada tiga hasil yang penting. Balasan tanpa error berarti 1500 byte dapat melewati jalur yang digunakan ping Anda. Jadi, MTU kemungkinan bukan masalahnya. Namun, trafik tunnel menggunakan UDP, bukan ICMP. Router yang menyeimbangkan beban di beberapa jalur juga dapat mengirim trafik tersebut melalui jalur yang berbeda. Jadi, jika transfer masih macet, MTU tetap perlu diperiksa. Error lokal berarti kernel menolak mengirim ukuran tersebut melalui rute ini. Penyebabnya bisa berupa interface Anda lebih kecil daripada ukuran yang diminta, atau kernel telah mempelajari path MTU yang lebih kecil dari pesan ICMP sebelumnya:

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

Balasan dari router di tengah jalur menunjukkan batas router tersebut secara langsung. Uji ulang menggunakan ukuran tersebut sebelum mengandalkannya. Link yang lebih kecil di bagian jalur berikutnya masih dapat menolaknya:

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

Packet loss 100% pada 1472, disertai balasan tanpa error pada ukuran yang lebih kecil, menunjukkan kasus black hole. Tidak ada router yang memberi informasi kepada Anda. Jadi, cari batasnya dengan membagi rentang menjadi dua. Pertahankan satu ukuran yang diketahui berhasil dan satu ukuran yang diketahui gagal, uji nilai tengahnya, lalu pindahkan batas yang sesuai dengan hasil tersebut. Setiap putaran membagi dua rentang yang tersisa. Lima atau enam putaran sudah cukup.

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 menjalankan pencarian yang sama secara otomatis. Jalankan sekali sebelum Anda mulai melakukan bisection:

tracepath -n 203.0.113.10

Baris terakhirnya melaporkan hasil yang ditemukan:

     Resume: pmtu 1492 hops 12 back 12

Anggap kedua tool tersebut sebagai titik awal, bukan bukti pasti. Beberapa host membatasi laju atau sepenuhnya membuang ICMP. Karena itu, bisection dapat melaporkan MTU yang lebih kecil daripada kapasitas sebenarnya pada jalur. Transfer yang sebelumnya gagal adalah pengujian yang sebenarnya.

Terapkan nilai tersebut sementara terlebih dahulu. Jika perkiraan salah, perubahan ini dapat dibatalkan dengan satu perintah:

sudo ip link set mtu 1320 dev wg0

Ulangi transfer yang sebelumnya macet. Jika transfer selesai, jadikan nilai tersebut permanen pada blok [Interface] milik client:

[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 sekarang seharusnya menampilkan mtu 1320. Jika masih menampilkan nilai lama, periksa dua hal. Pertama, pastikan Anda mengedit /etc/wireguard/wg0.conf, yaitu file yang pertama kali dibaca oleh wg-quick. Kedua, periksa apakah file tersebut berisi SaveConfig = true. Jika diaktifkan, wg-quick down menulis ulang file dari interface yang sedang berjalan dan menimpa perubahan Anda. Jadi, nonaktifkan interface terlebih dahulu, edit file, lalu aktifkan kembali. MTU harus berada di bawah [Interface]. Jika ditempatkan di bawah [Peer], parameter tersebut tidak diabaikan. wg-quick meneruskan setiap baris peer ke wg. Komponen tersebut menolak key apa pun yang tidak dikenali dalam bagian peer. Akibatnya, wg-quick up berhenti dengan parse error dan tunnel tidak dapat aktif sama sekali:

Line unrecognized: `MTU=1320'

MTU merupakan properti satu interface dan tidak pernah dinegosiasikan antar-peer. Menetapkannya hanya pada client hanya mengurangi ukuran paket yang dikirim client. Server tetap membuat paket menggunakan MTU wg0 miliknya sendiri. Karena itu, download masih dapat mengalami black hole setelah upload mulai berfungsi. Tetapkan nilai tersebut di kedua sisi, atau lakukan clamp MSS pada server.

Mengapa MSS clamping memperbaiki TCP dan tidak yang lain

Jika server meneruskan trafik untuk peer-nya, seperti yang dilakukan dalam setup WireGuard VPS standar apa pun yang menggunakan NAT (network address translation), satu aturan dapat memperbaiki TCP untuk setiap peer. Anda tidak perlu mencari nilai yang tepat pada setiap client yang tidak Anda kendalikan.

MSS (maximum segment size) adalah opsi TCP yang dicantumkan setiap sisi dalam paket SYN untuk menyatakan ukuran segmen terbesar yang bersedia diterima. Clamping menulis ulang opsi tersebut saat paket melintas agar sesuai dengan MTU rute sebenarnya. Dengan demikian, kedua endpoint menyepakati segmen yang lebih kecil sebelum data apa pun dikirim. Cara ini berhasil karena dilakukan selama handshake dan tidak bergantung pada pesan ICMP yang kemungkinan difilter oleh rute.

Dengan nftables, tambahkan table ini ke /etc/nftables.conf di bawah table yang sudah ada:

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

Muat ulang dengan sudo systemctl reload nftables. Pada server yang menggunakan iptables, padanannya adalah satu baris berikut:

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

Pastikan rule tersebut berada pada jalur yang dilalui paket. Jalankan sudo nft list table inet mangle atau sudo iptables -t mangle -L FORWARD -n -v saat client membuka koneksi baru, lalu pantau counter hingga meningkat. Counter yang tetap 0 berarti paket tidak melewati hook tersebut. Artinya, rule tidak melakukan apa pun.

Sekarang, berikut batasannya. Clamping hanya mencakup TCP dan hanya berlaku untuk trafik yang diteruskan. Service yang berjalan langsung pada WireGuard server tidak pernah melewati forward hook, sehingga tidak pernah terkena clamping. Rule ini juga hanya memengaruhi koneksi yang dibuka setelah rule dimuat. Sesi yang sudah ada tetap menggunakan MSS yang telah disepakati sebelumnya.

UDP tidak terpengaruh karena UDP tidak memiliki handshake untuk ditulis ulang. Sebagian besar trafik UDP tetap berjalan normal. QUIC, yaitu transport di bawah HTTP/3, menguji sendiri ukuran paket yang dapat digunakan dan sengaja memulai dengan ukuran kecil. Yang tidak dapat bertahan adalah UDP yang mengirim satu datagram besar dan mengharapkannya diteruskan, misalnya jawaban DNSSEC (DNS security extensions) yang lebih besar dari 1400 byte. Query tersebut mengalami timeout dan dicoba ulang melalui TCP. Bagi pengguna, hasilnya berupa situs yang lambat, bukan situs yang rusak.

Apakah CPU VPS saya menjadi batasnya?

WireGuard mengenkripsi dengan ChaCha20-Poly1305 dan melakukan pertukaran kunci dengan Curve25519. Tidak ada AES dalam jalur data, dan hal ini menimbulkan satu konsekuensi yang sering disalahpahami: instruksi AES-NI pada CPU Anda tidak berpengaruh pada WireGuard. Host yang mengiklankan AES-NI tidak berarti menyediakan fitur performa WireGuard. ChaCha20 dipilih karena cepat dalam perangkat lunak biasa, termasuk pada CPU yang sama sekali tidak memiliki akselerasi kriptografi.

Namun, WireGuard tetap menggunakan sumber daya. Pada VPS dengan 1 vCPU, satu core menangani enkripsi dan interupsi jaringan, selain beban aplikasi yang sedang berjalan.

Lakukan pengukuran saat transfer berlangsung:

sudo apt install -y sysstat
mpstat -P ALL 1

Baca tiga kolom. %soft adalah waktu softirq, yaitu waktu untuk pemrosesan paket oleh kernel. %steal adalah waktu ketika hypervisor memberikan CPU kepada pihak lain. %idle adalah waktu yang tersisa. Jika %idle rendah pada sebuah core, sementara %soft dan %steal tidak tinggi, waktu tersebut digunakan oleh %usr (aplikasi, termasuk WireGuard di userspace) atau %sys (kernel). Periksa keduanya sebelum menyimpulkan bahwa CPU bukan penyebabnya.

%soft yang mendekati 100 pada satu-satunya core berarti server telah mencapai batas pemrosesan paket. Ini adalah batas nyata yang dapat diatasi dengan menambah jumlah core. top menunjukkan ksoftirqd/0 berada di urutan teratas daftar proses pada saat yang sama. Ini merupakan temuan yang sama dari sudut pandang berbeda.

%steal di atas beberapa persen berarti batas tersebut tidak dapat Anda atasi sendiri, karena host mengalami oversubscription dan vCPU Anda sedang menunggu core fisik. Hal ini umum terjadi pada paket shared termurah dan nilainya berubah sepanjang hari. Steal time dari tetangga yang membebani host memerlukan pemeriksaan tersendiri. Tidak ada nilai MTU yang dapat mengatasinya.

Faktor lain adalah implementasi yang digunakan client. Modul kernel Linux merupakan jalur tercepat dan menyebarkan enkripsi peer ke beberapa core. wireguard-go, yaitu implementasi di userspace, lebih lambat. Implementasi ini digunakan oleh client macOS dan iOS karena platform tersebut tidak mengizinkan aplikasi memuat modul kernel.

Apakah masalahnya ada pada jalur atau tautan milik peer?

Sebelum menyesuaikan apa pun, ambil dua angka dari client yang sama dengan selang beberapa menit: throughput tanpa tunnel dan throughput dengan tunnel. Tanpa pasangan angka ini, Anda hanya menebak.

Jalankan iperf3 -s pada server. Pengujian langsung memerlukan TCP 5201 agar dapat diakses pada alamat publik. Buka akses tersebut selama pengujian, lalu hapus aturannya setelah selesai. Pastikan port kembali tertutup dan jangan hanya menganggapnya demikian.

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

Jika kedua angka tersebut berdekatan, WireGuard hanya menimbulkan sedikit overhead dan keterbatasannya ada pada jalur. Jika angka melalui tunnel jauh lebih rendah daripada angka langsung, sementara setiap core masih memiliki banyak %idle, periksa kembali MTU. Fragmentasi menurunkan throughput tanpa menyebabkan kegagalan, sehingga dampaknya terlihat sebagai persentase kehilangan, bukan hang.

Uji kedua arah karena koneksi rumah biasanya asimetris. iperf3 -c 10.8.0.1 -R membalik aliran sehingga server yang mengirim. Client pada koneksi 500/20 tidak akan pernah dapat mengirim lebih dari 20 Mbit upload melalui tunnel, dan perubahan pada sisi server tidak dapat mengubahnya.

Selanjutnya, uji dengan stream paralel:

iperf3 -c 10.8.0.1 -P 4

Jika empat stream secara bersama-sama menghasilkan throughput yang jauh lebih besar daripada satu stream, satu koneksi TCP tidak berhasil memenuhi kapasitas jalur. Throughput satu stream dibatasi oleh receive window yang dibagi round-trip time, sehingga jalur dengan latensi 150 ms memerlukan window yang besar untuk membawa banyak data. Periksa batas Anda:

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Nilai ketiga pada masing-masing output adalah nilai maksimum yang dapat digunakan Linux melalui autotuning. Packet loss juga membatasi satu stream secara signifikan karena TCP congestion control bereaksi terhadap loss, dan pemulihan pada jalur yang panjang memerlukan biaya besar. Jalankan mtr -rwc 100 203.0.113.10 dari client selama seratus siklus untuk melihat di mana loss muncul di sepanjang rute. Loss yang mulai muncul pada satu hop dan terus berlanjut hingga hop terakhir adalah loss nyata. Loss pada satu hop di tengah yang menghilang setelah hop tersebut berarti router itu menurunkan prioritas ICMP, dan tidak memiliki arti.

Untuk mendapatkan gambaran server yang dapat diulang dan terpisah dari jaringan, benchmark VPS dengan metode yang terdokumentasi agar Anda dapat menjalankan pengujian yang sama setelah perubahan dan membandingkan hasil yang setara.

Hal-hal yang tidak dapat diperbaiki WireGuard

WireGuard adalah tunnel. Kecepatannya tidak dapat melebihi link paling lambat pada jalur yang digunakannya, dan penambahannya selalu membuat jalur sedikit lebih lambat.

WireGuard tidak melakukan kompresi. Tidak ada padanan comp-lzo milik OpenVPN, dan tidak ada rencana untuk menambahkannya karena kompresi sebelum enkripsi membocorkan informasi tentang plaintext. Sebagian besar data berukuran besar sudah terkompresi, sehingga dalam praktiknya hal ini tidak menimbulkan biaya tambahan. Ini adalah salah satu perbedaan nyata yang perlu dipertimbangkan saat membandingkan WireGuard dengan OpenVPN, dan merupakan pilihan desain yang disengaja.

Full tunnel mengubah rute yang dilalui setiap paket. Trafik yang sebelumnya berjalan dari Anda ke CDN (content delivery network) terdekat kini berjalan dari Anda ke VPS, lalu ke CDN. Jika VPS berada di benua lain, setiap permintaan harus melewati rute memutar tersebut dan round-trip time meningkat. Tidak ada nilai konfigurasi yang dapat mempersingkatnya. Pindahkan VPS lebih dekat, atau gunakan split tunnel agar hanya trafik yang memerlukan VPN yang melewati rute lebih jauh. Trafik yang melewati setiap rute sepenuhnya ditentukan oleh AllowedIPs, dan perutean cryptokey menjelaskan cara keputusan tersebut dibuat.

Batasan provider berada di luar tunnel dan mudah terlupakan. Paket layanan dengan kuota bandwidth bulanan sering membatasi kecepatan port menjadi jauh lebih rendah setelah kuota habis, sehingga tunnel tampak rusak. Periksa panel provider sebelum menghabiskan waktu seharian untuk mengatur MTU.

PersistentKeepalive tidak memengaruhi throughput. Fitur ini digunakan untuk mempertahankan mapping NAT tetap terbuka agar server tetap dapat menjangkau client di balik router rumah. Menurunkannya hingga di bawah 25 detik hanya menambah paket dan tidak memperbaiki apa pun.

Ukur dengan urutan berikut

1. Reproduksi masalah dan catat apakah koneksi macet atau melambat secara konsisten. Koneksi yang macet mengarah ke masalah MTU. Perlambatan yang konsisten tidak mengarah ke masalah tersebut.
2. Lakukan bisect dengan ping -M do dari klien ke alamat publik server, lalu catat path MTU.
3. Kurangi nilainya sebesar 80, tetapkan MTU tersebut pada wg0 di kedua sisi, lalu uji ulang transfer yang sebelumnya gagal.
4. Tambahkan MSS clamping pada server jika server meneruskan trafik untuk peer.
5. Jalankan mpstat -P ALL 1 selama transfer, lalu baca %soft, %steal, dan %idle.
6. Jalankan iperf3 di luar tunnel dan di dalam tunnel, pada kedua arah, dengan satu stream dan dengan -P 4.
7. Jalankan mtr -rwc 100 ke server dan periksa apakah packet loss berlanjut hingga hop terakhir.

Ubah paket server hanya setelah langkah 5 menunjukkan bahwa CPU menjadi batas kinerja, atau setelah provider mengonfirmasi bahwa paket yang lebih besar juga menyediakan port jaringan yang lebih cepat. Langkah 1 hingga 4 tidak memerlukan biaya dan menyelesaikan sebagian besar laporan tentang tunnel yang lambat.

FAQ

Mengapa tunnel WireGuard saya cepat untuk ping tetapi lambat saat mengunduh?

Perbedaan tersebut merupakan indikasi masalah MTU. Paket kecil masih muat melalui setiap link pada jalur, sehingga ping dan login SSH tetap berfungsi. Transfer data dalam jumlah besar mengirim segmen berukuran penuh. Versi terenkapsulasi dari segmen tersebut lebih besar daripada ukuran yang dapat diterima oleh beberapa link. Jika router menjatuhkannya tanpa mengirim pesan ICMP kembali, kehilangan paket tidak dilaporkan dan transfer berhenti. Temukan MTU jalur dengan bisection ping -M do ke alamat publik server, kurangi 80 byte untuk enkapsulasi, lalu tetapkan hasilnya sebagai MTU wg0 pada kedua ujung.

MTU berapa yang harus saya tetapkan untuk WireGuard?

Tidak ada angka universal. Itulah sebabnya nilai default 1420 gagal bagi sebagian pengguna. Nilai 1420 adalah 1500 dikurangi 80 byte untuk header WireGuard, header UDP, dan header IPv6 luar. Jika jalur Anda membawa kurang dari 1500 byte, yang umum terjadi pada DSL PPPoE dan saat trafik melewati tunnel lain, Anda memerlukan nilai yang lebih kecil. Ukur MTU jalur terlebih dahulu, lalu kurangi 80 dari hasilnya.

Apakah MSS clamping menggantikan pengaturan MTU?

Tidak. Clamping menulis ulang opsi MSS dalam handshake TCP agar kedua ujung mengirim segmen yang lebih kecil. Cara ini memperbaiki TCP tanpa mengubah interface. UDP tidak memiliki handshake yang dapat ditulis ulang, sehingga tidak terpengaruh. Clamping juga hanya berlaku pada trafik yang diteruskan server. Karena itu, service yang berjalan langsung pada server WireGuard tidak memperoleh manfaat. Gunakan keduanya: MTU yang benar pada interface dan clamping untuk menangani peer yang konfigurasinya tidak Anda kendalikan.

Apakah paket VPS yang lebih cepat akan membuat WireGuard lebih cepat?

Hanya jika CPU menjadi batasnya atau provider memberi paket yang lebih besar dengan port jaringan yang lebih cepat. Satu perintah dapat menunjukkan kondisi CPU. Jalankan mpstat -P ALL 1 saat transfer berlangsung. Nilai %soft yang mendekati 100 pada satu-satunya core berarti pemrosesan paket menjadi batas kinerja, sehingga penambahan core akan meningkatkan throughput. Nilai %steal yang tinggi berarti host mengalami oversubscription, sehingga solusinya adalah paket atau host lain. Jika %idle rendah sementara kedua nilai tersebut tidak tinggi, periksa %usr dan %sys sebelum mengesampingkan CPU. Jika setiap core masih memiliki banyak %idle sementara tunnel tetap lambat, CPU bukan batasnya. Paket yang lebih besar hanya membantu jika juga meningkatkan kecepatan port Anda.

Mengapa Mac saya lebih lambat daripada client Linux pada jaringan yang sama?

Client Linux menggunakan modul WireGuard di kernel. Modul ini memproses paket dalam kernel space dan membagi proses enkripsi peer ke beberapa core CPU. Aplikasi macOS dan iOS menggunakan wireguard-go, yaitu implementasi userspace, karena platform tersebut tidak mengizinkan aplikasi memuat modul kernel. Userspace menyalin setiap paket antara kernel dan aplikasi, dan proses penyalinan ini mengurangi throughput. Perbedaan tersebut memang diharapkan, dan tidak ada pengaturan client yang dapat menghilangkannya.