VM Vagrant menghilang saat VPN terhubung: rute siapa yang rusak

Mesin itu menjawab semenit lalu, VPN terhubung, dan kini alamat yang sama kehabisan waktu. Tiga kesalahan menghasilkan gejala itu, dan ketiganya berada di mesin berbeda. Host bisa kehilangan rute ke jaringan privat, rentang NAT tamu bisa bertabrakan dengan rentang yang kini diumumkan terowongan, atau terowongan penuh bisa mengambil alih semua rute di host. Cari tahu mana yang terjadi sebelum mengubah konfigurasi apa pun, karena setiap perbaikan berada di tempat lain.

Amati rutenya, bukan mesinnya

Lihat keputusan perutean host untuk alamat tamu selama terowongan aktif. Rute yang masih menunjuk ke adaptor khusus host bukan masalahnya. Rute yang kini menunjuk ke adaptor VPN adalah masalahnya, dan klien yang mengubahnya, bukan Anda. Adaptor yang tetap memegang alamatnya memberi tahu bahwa antarmuka bertahan, fakta yang berbeda dari bertahannya jalur.

Sesi SSH yang putus tepat pada saat koneksi adalah perilaku yang wajar. Klien mendaur ulang adaptor dan memasang rute, jadi koneksi mati beberapa detik. Kesalahannya adalah koneksi yang tidak pernah kembali, bukan yang hanya berkedip.

Rekam tabel sebelum terowongan dan sekali lagi sesudahnya, lalu bandingkan kedua keluaran itu. Selisihnya adalah diagnosis, dan kebetulan juga bukti yang akan diminta pemilik jaringan.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Baca tabel host sebelum dan sesudah

Di Linux preferensi antar rute yang tumpang tindih berasal dari panjang prefiks dan metrik, jadi rute VPN yang lebih spesifik menang meskipun salah. Di Windows metrik antarmuka memutuskan seri, dan adaptor terowongan biasanya datang dengan metrik lebih rendah daripada yang virtual. Pada kedua kasus gejalanya identik: paket keluar lewat adaptor terowongan dan hilang.

Cetak adaptor dan metriknya di samping rute untuk prefiks tamu. Pasangan keluaran itu menjawab pertanyaan kepemilikan dalam satu lihatan.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Jika rute berubah tetapi metrik adaptor tidak, klien memasang rute pesaing. Jika metriknya berubah, klien menyusun ulang adaptor. Keduanya bisa diperbaiki, dan diperbaiki di tempat berbeda.

Ketika rentang NAT tamu adalah tabrakannya

VirtualBox NAT memakai 10.0.2.0/24 secara bawaan, dan terowongan yang mendorong rentang yang sama membuat tamu mengirim lalu lintas itu ke gateway NAT-nya alih-alih ke tujuan sebenarnya. Paket tidak pernah meninggalkan host, jadi tidak ada log firewall di sisi seberang yang akan menampilkannya. Docker Machine punya kelas konflik yang sama pada rencana khusus host-nya, dan mengubah rencana itu bisa menuntut pembuatan ulang mesin beserta sertifikatnya.

Pilih penggantinya dengan mendaftar apa yang sudah diumumkan terowongan, lalu apa yang dipakai jaringan kantor, lalu apa yang diklaim setiap adaptor virtual di host ini. Tumpang tindihlah yang merusak perutean, dan kemiripan tidak relevan. Satu rentang bisa berada sepenuhnya di dalam rentang lain sementara sekilas tidak mirip sama sekali.

Tetapkan rentang baru saat mesin dibuat, atau ubah lalu muat ulang, kemudian uji lagi koneksi yang gagal dari tamu. Tabel milik tamu sendiri adalah tampilan yang penting.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Pulihkan jalurnya tanpa berkelahi dengan klien

Setiap platform menawarkan cara mengembalikan prefiks khusus host ke depan. Di macOS rute statis ke antarmuka khusus host bertahan sampai koneksi berikutnya. Di Windows metrik antarmuka yang lebih rendah pada adaptor virtual membuatnya tetap diutamakan. Di Linux operasi penggantian mencakup satu prefiks. Ketiganya jalan pintas, karena klien yang menegaskan ulang rutenya akan membatalkannya.

Skripkan pemeriksaannya alih-alih menghubungkan ulang secara buta saat boot. Skrip kecil yang mencetak rute prefiks tamu setelah setiap koneksi mengubah misteri menjadi satu baris log.

Jika profilnya terowongan penuh, minta pemilik jaringan memberi terowongan terpisah atau pengecualian yang terdokumentasi. Menambahkan rute yang melewati kebijakan keamanan secara diam-diam bukan perbaikan, melainkan masalah kedua yang datang kemudian bersama auditor.

Periksa perbaikan di kedua sisi

Verifikasi tiga jalur setelah perubahan: host ke tamu, tamu ke host korporat, dan tamu ke internet. Perbaikan yang memulihkan salah satunya dan merusak yang lain adalah perubahan konfigurasi yang menyamar sebagai reparasi. Rekam keluaran yang sama seperti yang Anda kumpulkan sebelum perubahan agar perbandingannya setara.

Catat antarmuka, metrik, dan rute yang berubah, beserta waktunya, supaya kejadian berikutnya menjadi pencarian, bukan pembangunan ulang. Catatan itu lebih bernilai daripada utas tiket yang panjang.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Ketika host menjangkau tamu lagi dan tamu menjangkau LAN, Anda telah memulihkan jalur yang Anda mulai. Ketika hanya satu yang berfungsi, kesalahan sisanya ada di wilayah pemilik lain, dan selisihnya memberi tahu wilayah mana itu.