VPN tersambung tetapi perangkat LAN tidak terjangkau: apa yang perlu diperiksa

Lalu lintas masuk ke terowongan, gateway menjawab pada alamatnya sendiri, dan tidak ada apa pun di belakangnya yang menjawab. Pola itu umum dan bukan kontradiksi: balasan dari gateway membuktikan bahwa terowongan berakhir, dan itu tidak membuktikan apa pun tentang apa yang terjadi pada paket yang dialamatkan melewatinya. Kedua pengujian memakai jalur kode yang berbeda pada mesin yang sama.

Mulai sekarang, ujilah sesuatu di sisi lain gateway. Alamat gateway itu sendiri akan terus menjawab seburuk apa pun penerusannya.

Gateway menjawab dari tumpukannya sendiri

Paket yang dialamatkan ke gateway dikirim ke jalur masukan lokalnya, tempat kernel memutuskan apakah soket yang mendengarkan menerimanya. Paket yang dialamatkan ke host di belakang gateway justru dikirim ke jalur penerusan, tempat serangkaian pemeriksaan yang berbeda berlaku. Penerusan dapat dinonaktifkan sepenuhnya, atau diaktifkan oleh kernel lalu ditolak oleh aturan filter yang tidak pernah menyebut terowongan. Tidak satu pun dari itu memengaruhi balasan gateway sendiri, itulah sebabnya gejalanya begitu andal menyesatkan.

Halaman administrasi yang dicapai melalui terowongan juga termasuk kategori pertama. Itu bukti tentang terowongan, bukan tentang jaringan di belakangnya.

Ikuti alur hingga batas pertama yang menjatuhkannya

Mulailah dari klien dan pastikan rute serta alamat sumber yang akan dipakai alur. Lalu amati gateway untuk kedatangan alur yang persis itu, dan lagi untuk alur yang sama saat meninggalkan menuju LAN. Jika tidak pernah datang, masalahnya di sisi klien atau pada prefiks terowongan yang diizinkan. Jika datang dan tidak pernah pergi, masalahnya pada penerusan atau filter jalur maju, dan tangkapan sudah mengatakan yang mana.

Menjalankan pengujian yang sama dari gateway menyembunyikan separuh yang menarik, karena paket yang berasal dari gateway memiliki sumber dan persyaratan kembali yang berbeda. Gunakan alur klien, dengan alamat sumbernya sendiri, pada setiap langkah. Tangkapan yang diambil pada antarmuka yang salah menghasilkan omong kosong yang percaya diri.

Rute balik dan firewall host gagal secara terpisah

Setelah paket mencapai host, tiga hal lagi harus terpenuhi. Layanan harus mendengarkan pada alamat tujuan paket dikirim, firewall host harus menerimanya, dan balasan harus memiliki rute kembali menuju kumpulan klien. Yang terakhir sering gagal, karena rute default host menunjuk ke router yang tidak pernah mendengar tentang rentang terowongan. Hasilnya adalah koneksi yang terbentuk dari sudut pandang host dan mati diam-diam ke arah lain.

Ujilah jalur balik dengan sengaja: kirim dari klien dan amati kembalinya. Tangkapan satu arah menyelesaikan dalam hitungan detik apa yang tidak akan diselesaikan oleh satu jam spekulasi.

Pastikan setiap lompatan dengan alamat sumber klien

Jalankan pemeriksaan secara berurutan dan simpan setiap keluaran, karena nilainya ada pada perbandingan, bukan pada satu baris tertentu. Perintah di bawah ini mematok alamat sumber, menunjukkan rute yang dipilih, dan menangkap kedua sisi penerusan. Ganti host LAN dan antarmuka terowongan Anda sendiri.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Kueri rute menunjukkan apakah klien bahkan akan mengirim paket itu ke terowongan, dan ping menunjukkan apakah ada yang kembali dari host. Membandingkan kedua tangkapan memisahkan kedatangan dari keluaran, karena bingkai pada antarmuka terowongan tanpa padanan pada antarmuka LAN adalah keputusan penerusan, bukan kegagalan layanan. Ketika kedua tangkapan menunjukkan permintaan dan hanya satu yang menunjukkan balasan, rute balik adalah tersangka yang tersisa.

Catat alamat mana yang menjawab dan tujuan yang diteruskan mana yang gagal. Kalimat itu membuat laporan dapat ditindaklanjuti alih-alih klaim bahwa server tidak terjangkau.