Anda memasang VPN di Windows, mem-boot ulang ke Linux, dan koneksi kabel mati. Cerita yang jelas menulis dirinya sendiri: VPN meninggalkan sesuatu. Cerita itu salah, karena kedua boot menjalankan kernel terpisah dengan driver terpisah, tabel rute terpisah, dan resolver terpisah. Filter jaringan Windows tidak berjalan di dalam Linux, jadi kesalahannya ada di tumpukan Linux atau pada sesuatu yang benar-benar dibagi kedua boot, seperti perangkat keras, firmware, atau router.

Gejala dan kesimpulan yang salah

Bagian yang berguna dari pengamatan ini adalah waktu: kegagalan muncul setelah perubahan. Bagian yang tidak berguna adalah lompatan kausal ke VPN Windows, yang tidak bisa berjalan di sistem operasi lain. Memisahkan keduanya adalah seluruh pekerjaannya. Tulis garis waktunya sebelum menyentuh kabel.

Yang memang dibagi kedua boot adalah adaptor fisik, kabel, port switch, dan apa pun di hulu. Itu variabel bersama yang nyata, dan layak diperiksa setelah tumpukan Linux ditelusuri.

Ambil cuplikan tumpukan Linux dengan empat perintah

Mulailah dengan mode hanya-baca dan tangkap keadaannya sebelum mengubah apa pun: ip -br link untuk keberadaan antarmuka, ip -br address untuk alamat, ip route untuk rute IPv4, dan ip -6 route bila IPv6 penting. Referensi alat ip membedakan objek-objek ini, dan munculnya antarmuka dalam daftar bukan bukti bahwa ia punya alamat yang bekerja atau rute yang bisa dipakai.

Simpan keluarannya ke berkas agar nanti bisa dibandingkan dengan boot yang berfungsi. Cuplikan yang tidak bisa Anda reproduksi hanyalah kenangan akan suatu keadaan.

Apakah ini tautan, alamat, rute, atau nama?

Empat kegagalan berbeda tampak sama dari peramban. Perangkat bisa hilang sama sekali, ada tanpa pembawa, tertaut tetapi tanpa alamat yang diharapkan, atau beralamat tanpa rute ke tujuan. Kegagalan resolusi nama sementara alamat mentah bekerja adalah kasus kelima, dan itu milik resolver, bukan driver.

Setiap kasus menunjuk pekerjaan berbeda: driver atau firmware untuk perangkat yang hilang, kabel atau switch saat tidak ada pembawa, DHCP atau konfigurasi statis untuk alamat yang hilang, serta perutean atau kebijakan untuk jalur yang hilang. Masalah resolver menunjuk systemd-resolved, NetworkManager, atau konfigurasi DNS lokal.

Periksa apakah instalasi Linux punya VPN sendiri atau konfigurasi firewall yang menetap. Terowongan lokal atau kumpulan aturan nftables adalah penyebab di sisi Linux, dan jauh lebih mungkin menjelaskan kegagalan daripada program Windows yang tidak berjalan.

Lalu bandingkan transisi boot

Windows Fast Startup adalah mati hibrida yang mempertahankan keadaan sesi kernel alih-alih melakukan boot penuh. Dokumentasi Microsoft tentang status daya membedakannya dari mulai ulang dan dari mati penuh, karena itu perangkat keras yang sama bisa berperilaku berbeda pada kedua transisi.

Jika kegagalan bergantung pada berpindah dari satu sistem operasi ke sistem operasi lain, bandingkan mulai ulang atau mati penuh yang terdokumentasi dengan jalur normal, setelah menyimpan pekerjaan. Hasil yang mengikuti transisi membenarkan pemeriksaan keadaan driver, perangkat, atau firmware, dan itu sendiri tidak membuktikan bahwa Fast Startup menyebabkan kegagalan adaptor tertentu.

Catat sistem operasi mana yang terakhir memakai adaptor, jenis transisinya, keadaan tautan di Linux, dan operasi pertama yang gagal. Perbedaan yang bisa diulang antara boot dingin dan transisi hangat jauh lebih berharga daripada menghapus perangkat lunak VPN dari kedua instalasi tanpa tahu tumpukan mana yang rusak.

Apa yang tidak boleh diubah

Jangan menyetel ulang kedua tumpukan jaringan sebagai langkah pertama. Itu menghancurkan perbandingan dan sering tidak memperbaiki apa pun, karena penyebab sebenarnya tidak pernah diidentifikasi. Jangan memasang ulang VPN Windows untuk memperbaiki Linux, dan jangan mengubah pengaturan firmware secara acak karena transisi boot berkorelasi dengan kegagalan.

Referensi alat ip mendokumentasikan objek tautan, alamat, dan rute yang dipakai di atas. Baca sisi Linux lebih dulu, simpan cuplikannya, dan baru setelah itu putuskan apakah lapisan perangkat keras bersama layak diselidiki.

Artikel terkait