VPN terhubung tetapi satu layanan gagal: isolasi tahapnya

«Terhubung» adalah fakta paling tidak informatif dalam tiket VPN. Itu mencatat bahwa dua pihak menyelesaikan handshake dan tidak mencatat apa pun tentang nama yang ditanyakan, antarmuka tempat paket keluar, ukurannya, atau apakah ujung jauh menerimanya. Itulah sebabnya satu layanan bisa gagal sementara semua aplikasi lain di laptop yang sama bekerja. Lalui tahap-tahapnya secara berurutan dan tahap pertama yang gagal akan menamai kesalahannya.

Mulai dari nama, bukan dari tunnel

Selesaikan sebelum merutekan, karena jawaban buruk membuat setiap pengujian berikutnya tidak berarti. Tanyakan nama dengan resolver sistem dan bandingkan jawaban itu dengan alamat yang benar-benar dipakai aplikasi. Nama privat yang kembali sebagai alamat publik berarti kueri pergi ke resolver yang tidak berurusan menjawabnya. Nama yang gagal diselesaikan adalah kategori yang sama, hanya lebih keras.

resolvectl query host.internal
getent hosts host.internal

Peramban dengan pengaturan DNS aman sendiri gagal di sini sementara bagian sistem lainnya bekerja. Karena itu keluhan yang hanya menyangkut peramban pertama-tama masuk ke tahap ini, sebelum siapa pun menyentuh rute. Bandingkan kedua perintah, bukan satu, karena getent mengikuti jalur NSS dan kueri resolver tidak.

Tanyakan kepada kernel jalur mana yang dipilihnya

Tabel perutean adalah urutan preferensi, dan jalur yang dipilih kernel tidak selalu yang ditunjukkan diagram. Tanyakan langsung kepadanya untuk tujuan yang dimaksud. Jawabannya menyebut antarmuka, hop berikutnya, dan alamat sumber yang akan dipakai. Paket dapat keluar melalui tunnel dengan alamat sumber yang ditolak ujung jauh, dan entri yang lebih spesifik di tabel fisik dapat mengirimnya lewat antarmuka Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Baca bidang dev, via, dan src dalam urutan itu, karena masing-masing menyingkirkan kecurigaan yang berbeda. Tahap ini juga memiliki status yang dipasang klien, karena aturan firewall dan rute dapat bertahan setelah keluar secara tidak normal. Karena itu «tidak ada internet tanpa tunnel» dan «tidak ada internet kecuali klien berjalan» adalah satu keluarga kesalahan, bukan dua.

Uji ukuran paket

Balasan kecil yang kembali saat transfer besar macet menunjuk lebih dulu ke MTU jalur. Satu probe dengan bit do-not-fragment disetel, dikirim dari dalam tunnel, memisahkan tahap ini dari yang lain. Naikkan muatan sampai probe gagal dan Anda punya angka yang penting.

ping -M do -s 1400 10.20.30.40

Probe kecil berhasil sementara daftar direktori atau unggahan menggantung adalah tanda tangan tahap ini. Keluhannya terdengar seperti kredensial atau aturan firewall, dan bukan keduanya.

Angka itu sifat jalur, bukan klien, jadi nilai yang bekerja pada koneksi kantor bisa gagal pada tautan seluler. Simpan perintah probe bersama tiket, karena orang berikutnya membutuhkan pengukuran yang sama. Jika muatan lebih kecil lolos, perbaikannya adalah clamp atau MTU tunnel lebih rendah, bukan cipher baru.

Uji ujung jauh

Uji tujuan dengan alamatnya, lalu lihat apa yang mendengarkan di sana. Koneksi ditolak dan koneksi yang tidak pernah menjawab adalah temuan berbeda. Yang pertama mengatakan ada sesuatu yang berjalan dan tidak melayani port itu, yang kedua mengatakan tidak ada yang kembali. Keduanya bukan masalah klien secara bawaan.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Tidak ada yang dapat dijangkau lewat tunnel bisa menjadi layanan yang hanya mendengarkan di 127.0.0.1, karena pendengar tidak pernah melihat paketnya. Ketika firewall host jauh mengizinkan subnet kantor dan menolak kumpulan tunnel, hasilnya tampak seperti kesalahan klien dan bukan. Remote Desktop atau berbagi file yang rusak sementara lalu lintas web bertahan biasanya berakhir di sini, apa pun kata pengguna.

Petakan keluhan ke satu tahap

Sebagian besar laporan menyusut menjadi salah satu dari lima bentuk, dan setiap bentuk menamai satu tahap. Satu situs yang hanya bekerja lewat tunnel adalah jawaban nama atau kebijakan yang terikat alamat sumber. Pembaruan gagal tanpa tunnel sementara penjelajahan bekerja adalah masalah nama atau rute bagi klien itu.

Semua berhenti saat klien penyedia mulai adalah status terpasang, yaitu soal rute dan firewall. Satu layanan tak terjangkau sementara sisanya baik-baik saja adalah ujung jauh. Transfer macet setelah beberapa detik adalah ukuran paket. Cocokkan bentuknya sebelum menjalankan perintah, karena itu menentukan bukti mana yang dikumpulkan lebih dulu.

Catat tahap yang menghasilkan kegagalan pertama bersama keluaran perintahnya. Tiket yang menyatakan alamat sumber salah, dengan baris rute terlampir, layak ditindaklanjuti, sedangkan yang melaporkan VPN rusak tidak.