Beberapa waktu lalu saya menemukan masalah yang cukup membingungkan pada dua distro WSL 2 yang saya gunakan, yaitu Ubuntu 26 dan Fedora 42. Keduanya dapat dijalankan seperti biasa, tetapi sama-sama tidak bisa mengakses internet.

Menariknya, koneksi internet di Windows tetap normal. Browser dapat membuka situs, DNS Windows bekerja, dan koneksi ke alamat publik juga tidak bermasalah. Karena kegagalan terjadi pada dua distro sekaligus, saya menduga sumber masalahnya bukan berada di konfigurasi Ubuntu atau Fedora, melainkan pada lapisan jaringan WSL di Windows.

Pada artikel kali ini, saya akan membagikan proses troubleshooting yang saya lakukan, bagaimana membedakan masalah DNS dengan masalah routing/NAT, hingga langkah yang akhirnya berhasil memperbaiki koneksi internet di kedua distro tanpa mengubah konfigurasi di dalam Linux.

Latar Belakang Masalah

WSL 2 menjalankan Linux di dalam virtual machine ringan. Secara default, jaringan Linux tidak langsung menggunakan adapter fisik Windows, melainkan melewati jaringan virtual berbasis NAT (Network Address Translation).

Secara sederhana, jalur koneksinya kurang lebih seperti ini:

Ubuntu/Fedora di WSL 2
        ↓
Virtual gateway WSL
        ↓
HNS dan NAT Windows
        ↓
Wi-Fi/Ethernet Windows
        ↓
Internet

Microsoft menjelaskan bahwa WSL menggunakan arsitektur NAT secara default. Di belakangnya, Host Network Service (HNS) dan Internet Connection Sharing (ICS) menangani virtual network, NAT, DNS, DHCP, serta koneksi menuju host Windows.¹²

Artinya, distro Linux bisa saja memiliki alamat IP dan default route yang terlihat benar, tetapi tetap tidak dapat keluar ke internet jika state jaringan HNS atau NAT di Windows bermasalah.

Gejala yang Ditemukan

Pertama-tama saya memeriksa status dan versi WSL dari PowerShell:

wsl --status
wsl --version
wsl --list --verbose

Hasilnya menunjukkan bahwa kedua distro menggunakan WSL 2 dan sedang berjalan:

NAME             STATE      VERSION
Fedora42         Running    2
Ubuntu26         Running    2

WSL yang digunakan juga sudah cukup baru, yaitu versi 2.7.3.0 dengan kernel 6.6.114.1-microsoft-standard-WSL2. Jadi, masalah ini tidak langsung mengarah ke distro yang terlalu lama atau WSL yang belum terpasang dengan benar.

Troubleshooting Koneksi WSL

Hal paling penting ketika menangani masalah jaringan adalah jangan langsung mengganti DNS. Kita perlu mengetahui terlebih dahulu di titik mana koneksi berhenti.

1. Memastikan Windows Masih Memiliki Internet

Dari PowerShell, saya menguji koneksi TCP Windows ke Cloudflare DNS:

Test-NetConnection 1.1.1.1 -Port 443

Hasilnya:

RemoteAddress    : 1.1.1.1
TcpTestSucceeded : True
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.100.3

Saya juga menguji resolusi DNS di Windows:

Resolve-DnsName example.com -Type A

Windows berhasil mendapatkan alamat IPv4 example.com. Dengan demikian, koneksi internet pada host Windows dalam kondisi normal.

2. Memeriksa Alamat IP dan Route di Setiap Distro

Selanjutnya saya menjalankan pemeriksaan berikut pada Ubuntu dan Fedora:

ip -brief addr
ip route

Keduanya mendapatkan konfigurasi jaringan yang sama:

eth0  UP  172.21.213.207/20

default via 172.21.208.1 dev eth0 proto kernel
172.21.208.0/20 dev eth0 proto kernel scope link src 172.21.213.207

Hal ini normal karena seluruh distro WSL 2 dapat berjalan di dalam network namespace virtual yang sama. Yang terpenting, interface eth0 aktif dan default route menuju gateway 172.21.208.1 sudah tersedia.

3. Memeriksa DNS WSL

Isi /etc/resolv.conf pada kedua distro adalah sebagai berikut:

nameserver 10.255.255.254
search tail95555.ts.net tail.ts.net

Kemudian saya menguji resolusi nama:

getent ahostsv4 example.com

Nama domain berhasil diterjemahkan menjadi alamat IPv4. Ini membuktikan bahwa DNS sebenarnya bekerja. Jadi, mengganti nameserver secara manual tidak akan menyelesaikan akar masalah.

4. Menguji Gateway dan Alamat Publik Secara Terpisah

Berikutnya saya menguji virtual gateway WSL:

ping -c 2 -W 2 172.21.208.1

Gateway merespons dengan baik:

2 packets transmitted, 2 received, 0% packet loss

Namun, ketika menguji alamat publik:

ping -c 2 -W 2 1.1.1.1

Hasilnya gagal:

2 packets transmitted, 0 received, 100% packet loss

Saya tidak hanya mengandalkan ping, karena ICMP dapat saja diblokir oleh jaringan tertentu. Oleh karena itu, koneksi HTTPS juga diuji:

curl -4 -I --connect-timeout 5 https://example.com

Koneksi tetap mengalami timeout. Pada titik ini pola masalahnya sudah cukup jelas:

• Windows dapat mengakses internet.
• DNS di dalam WSL bekerja.
• Distro dapat mencapai virtual gateway WSL.
• Paket tidak dapat diteruskan dari gateway menuju internet.
• Ubuntu dan Fedora mengalami kegagalan yang identik.

Kesimpulan sementara: masalah berada di jalur NAT/HNS Windows yang digunakan bersama oleh WSL 2, bukan di konfigurasi masing-masing distro.

5. Memeriksa Hyper-V Firewall dan Service Jaringan

Untuk memastikan koneksi tidak diblokir oleh kebijakan outbound Hyper-V, saya menjalankan PowerShell sebagai Administrator:

Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore |
  Format-List Name,Enabled,DefaultInboundAction,DefaultOutboundAction,LoopbackEnabled

Hasil yang relevan:

Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
LoopbackEnabled       : True

DefaultOutboundAction sudah bernilai Allow, sehingga firewall bukan penyebab utama kegagalan trafik keluar.

Saya juga memeriksa service yang berkaitan dengan WSL dan virtualisasi:

Get-Service hns,vmcompute,WslService

Ketiganya berstatus Running. Meskipun begitu, status Running tidak selalu berarti state jaringan virtual di dalam HNS masih sehat.

Percobaan Awal: Restart WSL

Sebelum menyentuh Windows service, saya mencoba solusi yang paling ringan terlebih dahulu:

wsl --shutdown

Perintah tersebut menghentikan seluruh distro dan virtual machine WSL. Microsoft juga menyarankan wsl --shutdown sebagai salah satu langkah untuk me-restart semua instance WSL.¹³

Setelah WSL dijalankan kembali, DNS masih bekerja tetapi koneksi ke 1.1.1.1 dan HTTPS tetap gagal. Ini berarti restart WSL biasa belum cukup untuk membersihkan state NAT yang bermasalah.

Solusi: Reset HNS, Virtual Machine Compute, dan WSL Service

Solusi yang akhirnya berhasil adalah menghentikan WSL, kemudian me-restart service jaringan dan virtualisasi Windows yang menjadi fondasinya.

Quote

Jalankan Windows Terminal atau PowerShell menggunakan Run as Administrator. Proses ini akan menghentikan semua distro WSL yang sedang berjalan, termasuk backend WSL milik Docker Desktop.

Pertama, hentikan seluruh instance WSL:

wsl --shutdown

Kemudian restart Host Network Service dan Hyper-V Virtual Machine Management/Compute Service:

Restart-Service -Name hns -Force
Restart-Service -Name vmcompute -Force

Terakhir, restart WSL Service agar handle virtualisasi dan disk WSL dibuat ulang dengan state yang baru:

Restart-Service -Name WslService -Force

Microsoft mendokumentasikan bahwa Restart-Service akan menghentikan lalu menjalankan kembali service yang dipilih. Perintah tersebut hanya berhasil jika terminal memiliki permission yang dibutuhkan.⁴

Urutan WslService di bagian terakhir cukup penting. Pada percobaan saya, setelah hns dan vmcompute di-restart, WSL sempat menampilkan error berikut ketika distro langsung dijalankan:

Failed to attach disk '...ext4.vhdx' to WSL2:
The interface is unknown.
Error code: Wsl/Service/CreateInstance/MountDisk/HCS/0x800706b5

File ext4.vhdx tidak rusak dan tidak perlu dihapus. Error tersebut muncul karena WSL Service masih menyimpan handle virtualisasi lama setelah vmcompute di-restart. Me-restart WslService menyegarkan handle tersebut dan membuat distro dapat dijalankan kembali.

Verifikasi Setelah Perbaikan

Setelah semua service kembali berjalan, saya menguji kedua distro menggunakan perintah berikut:

foreach ($distro in @('Ubuntu26', 'Fedora42')) {
    Write-Output "===== $distro ====="
    wsl -d $distro -- sh -lc '
        ip route show default
        ping -c 1 -W 3 1.1.1.1
        curl -4 -sS -o /dev/null \
          -w "HTTPS example.com: %{http_code}\n" \
          --connect-timeout 10 https://example.com
    '
}

Hasil pada Ubuntu26:

default via 172.21.208.1 dev eth0 proto kernel
1 packets transmitted, 1 received, 0% packet loss
HTTPS example.com: 200

Hasil pada Fedora42:

default via 172.21.208.1 dev eth0 proto kernel
1 packets transmitted, 1 received, 0% packet loss
HTTPS example.com: 200

Koneksi internet berhasil kembali pada kedua distro. Tidak ada konfigurasi /etc/resolv.conf, /etc/wsl.conf, package Linux, maupun file virtual disk yang perlu diubah.

Versi Ringkas Perbaikannya

Jika gejalanya sama, Windows memiliki internet, DNS WSL bekerja, gateway dapat dijangkau, tetapi trafik publik gagal, jalankan perintah berikut dari PowerShell sebagai Administrator:

wsl --shutdown
Restart-Service -Name hns -Force
Restart-Service -Name vmcompute -Force
Restart-Service -Name WslService -Force

Setelah itu, jalankan distro dan verifikasi:

ping -c 1 -W 3 1.1.1.1
curl -4 -I --connect-timeout 10 https://example.com

Jika menggunakan Docker Desktop, buka kembali aplikasinya setelah proses reset selesai.

Jika Masalah Masih Terjadi

Perbaikan di atas sesuai untuk state HNS/NAT yang macet. Apabila koneksi masih gagal, beberapa hal lain yang perlu diperiksa adalah:

1. Jalankan wsl --update untuk memperbarui WSL.
2. Pastikan service ICS (SharedAccess) tidak dinonaktifkan melalui service atau Group Policy. WSL 2 memerlukannya untuk membuat jaringan HNS.¹
3. Periksa VPN seperti OpenVPN, Cisco AnyConnect, ExpressVPN, atau security client lain yang dapat mengubah route dan filtering Windows.
4. Periksa kebijakan Windows Defender Firewall, khususnya pada perangkat kantor yang menonaktifkan local rule merging.
5. Pastikan IPv6 tidak dinonaktifkan secara paksa menggunakan registry karena hal tersebut dapat memutus konektivitas WSL.¹
6. Pertimbangkan networkingMode=mirrored pada Windows 11 22H2 atau lebih baru jika NAT terus bermasalah atau membutuhkan kompatibilitas VPN yang lebih baik.²

Jangan langsung menulis DNS statis ke /etc/resolv.conf kecuali pengujian memang membuktikan bahwa hanya resolusi nama yang gagal. Jika getent hosts example.com berhasil tetapi curl ke alamat IPv4 mengalami timeout, masalahnya bukan DNS.

Kesimpulan

Masalah internet pada WSL tidak selalu berasal dari Linux. Dalam kasus ini, dua distro berbeda mengalami kegagalan yang sama karena keduanya menggunakan jalur jaringan WSL 2 yang sama di sisi Windows.

Proses troubleshooting menjadi lebih mudah ketika koneksi diperiksa secara berurutan: mulai dari internet Windows, DNS WSL, interface dan route Linux, virtual gateway, alamat IP publik, hingga koneksi HTTPS. Dari pengujian tersebut dapat diketahui bahwa paket berhasil mencapai gateway, tetapi berhenti di lapisan NAT/HNS Windows.

Me-restart hns, vmcompute, dan WslService dengan WSL dalam keadaan mati berhasil membangun ulang jalur jaringan tersebut. Ubuntu dan Fedora kembali terhubung tanpa perlu mengubah konfigurasi distro atau melakukan reset Windows.

Sekian artikel kali ini, semoga catatan troubleshooting ini dapat membantu apabila distro WSL Anda tiba-tiba tidak bisa mengakses internet meskipun koneksi Windows terlihat normal. Terima kasih. 😊