Dua Klien VPN di Satu Desktop: Apa yang Bertabrakan dan Apa yang Berhasil

Klien kedua Anda terhubung, sumber daya klien pertama berhenti di-resolve, dan tiketnya bilang VPN kerja merusak yang pribadi. Tidak ada yang rusak dalam arti kegagalan: kedua klien melakukan apa yang memang dirancang, dan mesin hanya punya satu tabel routing. Tabrakan terjadi pada empat sumber daya yang masing-masing klien anggap miliknya. Selesaikan berurutan, dan perbaikannya biasanya menjadi pilihan desain, bukan perbaikan.

Langkah 1: temukan klien mana yang memiliki egress

Baca keputusan egress saat ini sebelum mengubah apa pun. Pencarian rute untuk alamat publik memberi tahu antarmuka dan hop berikutnya yang akan dipakai paket sekarang, dan itulah jawaban siapa yang menang. Bandingkan dengan nama antarmuka yang dibuat klien, yang biasanya membawa nama produk atau protokol. Jika pencarian menunjuk ke tunnel yang tidak Anda duga, Anda sudah menemukan tabrakannya.

ip route get 1.1.1.1
ip route show default
route print

Sebagian klien sama sekali tidak mengganti rute default; mereka menambahkan dua bagian, satu untuk paruh bawah ruang alamat dan satu untuk paruh atas, yang bersama-sama mencakup semuanya. Ini membuat rute default asli tetap terlihat dan membuat perbaikan manual terlihat benar padahal lalu lintas masih keluar lewat tunnel. Baca metrik dan panjang prefiks, bukan hanya keberadaan entri default.

Berhenti jika kedua klien mengklaim prefiks yang sama dengan metrik yang sama. Kernel akan memilih satu, dan yang lain akan tampak terhubung sambil tidak membawa apa pun.

Langkah 2: periksa resolver dan prefiks yang tumpang tindih

DNS adalah tabrakan kedua, dan gejalanya khas: nama gagal sementara alamat berfungsi. Setiap klien mendorong resolver-nya sendiri, dan penulis terakhir menang untuk kueri berikutnya. Tanyakan ke layanan resolver apa yang dipakainya per tautan, bukan membaca halaman pengaturan klien.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Lalu bandingkan prefiks privat yang dipakai kedua jaringan. Jika kedua sisi mengalokasikan dari rentang yang sama, tidak ada pengaturan di sisi klien yang bisa memperbaikinya, karena mesin tidak bisa membedakan tujuan 10.0.0.0/8 mana milik tunnel mana. Salah satu sisi harus dinomori ulang atau diterjemahkan, dan itu percakapan dengan pemilik jaringan, bukan perubahan konfigurasi. Tumpang tindih adalah satu-satunya tabrakan yang jawaban jujurnya adalah desainnya harus berubah.

Berhenti di sini jika prefiksnya tumpang tindih. Semua yang berikutnya dalam daftar ini mengasumsikan keduanya tidak tumpang tindih.

Langkah 3: pilih pola pemisahan yang bertahan

Pola yang andal menghindari menjalankan dua klien terhadap tabel routing yang sama. Satu klien dengan kebijakan split-tunnel yang menjangkau kedua jaringan privat adalah yang paling sederhana, asalkan tujuannya tidak tumpang tindih dan pemilik kebijakan setuju. Mesin virtual atau ruang nama jaringan adalah langkah berikutnya, karena masing-masing mendapat tabel dan resolver sendiri.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Ruang nama memberi pemisahan yang sama seperti mesin virtual tanpa sistem operasi kedua, tetapi punya sisi kasar: perangkat tunnel harus dipindahkan ke dalamnya, dan aplikasi harus dijalankan di dalamnya. Perangkat fisik terpisah sering menjadi opsi paling tidak mengejutkan untuk VPN pribadi di samping klien kerja yang dikelola. Menumpuk satu tunnel di dalam tunnel lain bukan pola pemisahan; titik akhir dalam harus tetap terjangkau lewat tunnel luar, dan susunan itu menambah masalah MTU serta latensi.

Pilih satu pola dan tulis alasannya. Mencampur ruang nama untuk satu aplikasi dengan split tunnel untuk sisanya menciptakan kembali tabrakan asli dalam bentuk yang lebih sulit di-debug.

Langkah 4: verifikasi kedua jaringan dari sesi yang sama

Uji satu sumber daya di setiap jaringan privat dari lingkungan tempat aplikasi benar-benar berjalan, bukan dari shell Anda jika aplikasi berjalan di dalam ruang nama. Periksa antarmuka egress, alamat hasil resolve, dan kode respons sekaligus, karena keberhasilan di salah satu dari tiga bisa menyembunyikan kegagalan di yang lain. Ulangi setelah reboot, karena urutan klien mulai menentukan siapa yang menang. Urutan itulah yang orang lupa catat.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Catat versi klien, antarmuka, status resolver, dan prefiks untuk setiap jaringan. Ketika klien diperbarui dan mengubah perilaku rutenya, catatan itu adalah pembeda antara perbaikan lima menit dan pembangunan ulang. Orang berikutnya tidak akan berbagi ingatan Anda tentang tunnel mana yang naik lebih dulu.

Daftar ini lengkap ketika Anda bisa menyebut antarmuka yang memiliki rute default, resolver yang dipakai setiap nama, pola yang memisahkan tunnel kedua, dan hasil satu permintaan per jaringan setelah reboot. Apa pun yang kurang dari itu adalah konfigurasi yang kebetulan berfungsi hari ini.