Sebuah tunnel bisa melaporkan tersambung sementara tidak ada yang mencapainya, dan kedua fakta itu tinggal di tempat berbeda. Yang satu adalah tabel rute, yang masih bisa mengirim paket ke perangkat yang tidak dimiliki siapa pun. Yang lain adalah resolver, yang masih bisa mencantumkan server pada tautan yang sudah hilang. Perubahan jaringan tidak merusak profil, ia membuat status milik koneksi sebelumnya menjadi yatim, dan perbaikannya bergantung pada mana dari keduanya yang benar-benar Anda lihat.

Pertama, tanyakan kepada kernel perangkat mana yang akan dipakai

Daftar rute menunjukkan apa yang ada; pencarian rute menunjukkan apa yang akan terjadi. Tanyakan sebuah alamat publik dan baca nama perangkat pada jawabannya, karena satu bidang itu menentukan apakah paket sampai ke tempat yang berguna. Ketika jawabannya menyebut perangkat tunnel, kernel akan menyerahkan paket kepadanya meskipun tidak ada proses klien yang masih berjalan di balik antarmuka itu. Ketika jawabannya menyebut adaptor fisik sementara klien mengaku tersambung, tunnel-nya hidup dan sekadar bukan jalur yang dipilih.

Kasus kedua biasa terjadi setelah kabel menggantikan nirkabel, dan ia tampil sebagai VPN yang rusak.

ip route show default
ip route get 203.0.113.9

Baca entri default berikutnya, karena rute yang ditambahkan koneksi dasar sebelumnya bisa bertahan melewati perubahan tautan dan berdiri di depan yang baru. Rute default melalui perangkat yang mati lebih buruk daripada tidak ada rute default, karena kernel tetap mengutamakannya. Perhatikan metrik di samping setiap entri, karena urutan itu menjelaskan preferensi lebih cepat daripada nama antarmuka.

Lalu baca resolver per tautan, bukan per berkas

Resolusi nama membawa statusnya sendiri dan keusangannya sendiri. Resolver yang mencantumkan server DNS per tautan menyimpan server dari tautan tunnel yang mati tetapi masih terdaftar, dan setiap pencarian lalu menunggu server yang tidak akan menjawab. Gejalanya adalah jaringan yang terasa mati sementara tabel rute tampak sempurna.

Periksa status per tautan, bukan berkasnya, karena pada banyak distribusi berkas itu adalah symlink ke resolver dan menyuntingnya entah tidak melakukan apa pun atau cepat ditimpa. Lihat tautan mana yang memiliki server mana dan domain pencarian mana, lalu tanyakan apakah tautan tunnel seharusnya masih terdaftar. Jika tidak, nonaktifkan koneksi yang memilikinya daripada menyunting status yang dihasilkan secara manual. Nama yang teresolusi sementara pencarian rute mengirim paket ke tempat lain adalah kesalahan ketiga yang terpisah.

resolvectl status
resolvectl query app.internal.example

Jika alamat teresolusi dan koneksi gagal, resolver-nya baik dan rutenya tidak. Jika alamat sama sekali tidak teresolusi, di sinilah tempat yang tepat untuk mulai.

Bagaimana rute usang bertahan melewati perubahan

Klien tidak memiliki jaringan sendirian. Pada host NetworkManager sebuah profil VPN diaktifkan di atas koneksi dasar, dan pengaturan koneksi memungkinkan dasar itu menamai VPN yang harus mengikutinya. Ketika dasar berubah karena profil lain menjadi lebih disukai, tunnel mengikuti ke dasar baru atau tertinggal tanpa dasar.

Profil VPN tidak menaikkan dirinya sendiri, jadi pemasangan berpasangan jauh lebih penting daripada preferensi sambung otomatis profil itu sendiri.

Baca daftar aktif dan catat dasar mana yang hidup sebelum menyentuh tunnel. Jika dasarnya tercantum dan tunnel-nya tidak, rutenya hilang bukan usang, dan perbaikannya adalah aktivasi. Jika mengaktifkan tunnel mengeluh bahwa tidak ada koneksi sumber, dasar yang menjadi pasangannya sudah hilang, jadi naikkan dulu atau perbaiki pemasangan itu daripada mencoba tunnel lagi. Mengulang profil yang induknya tidak ada menghasilkan galat yang sama setiap kali, yang merupakan sinyal berguna dan bukan gangguan.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Bedakan status usang dari induk yang hilang

Tiga status menjelaskan hampir setiap laporan, dan masing-masing butuh perbaikan berbeda. Rute default melalui perangkat yang masih ada tetapi tidak lagi membawa tunnel adalah status usang, dibersihkan entah dengan menghapus entri atau dengan me-restart profil yang bertanggung jawab. Perangkat tunnel yang proses kliennya lenyap adalah kegagalan pembersihan, jadi jalur pemutusan yang layak diperhatikan, bukan tabel rute. Tidak ada perangkat tunnel sama sekali berarti induk atau pemasangannya hilang dan tabel rute tidak pernah terlibat.

Reboot menyembunyikan mana dari ketiganya yang Anda alami, dan justru itulah sebabnya ia terasa seperti perbaikan.

Setelah perbaikan, minta kernel satu alamat publik dan satu alamat internal, lalu kueri sebuah nama internal. Ketika alamatnya bekerja dan namanya tidak, Anda menemukan masalah cakupan domain di resolver dan bukan masalah perutean. Catat status mana yang Anda temukan, karena perubahan jaringan berikutnya akan mereproduksi yang Anda biarkan.

Artikel terkait