Mengapa Tunnel VPN Kedua Merusak yang Pertama?

Memasang klien VPN kedua untuk menjangkau satu jaringan pelanggan adalah cara biasa ini dimulai, dan tunnel pertama menjadi gelap sementara kedua klien melaporkan sukses. Setiap klien memasang rute default, yang kedua lebih spesifik, dan kernel kini mengikutinya untuk semuanya kecuali koneksi luar tunnel pertama sendiri. Tidak ada yang crash dan tidak ada profil yang salah. Satu rute menggantikan yang lain, dan solusinya adalah memutuskan tunnel mana yang harus memiliki default.

Gejalanya: klien kedua menang diam-diam

OpenVPN: opsi redirect-gateway def1 tidak menimpa 0.0.0.0/0. Ia menambahkan 0.0.0.0/1 dan 128.0.0.0/1: bersama-sama keduanya mencakup setiap alamat IPv4, dan setiap prefiks mengalahkan default biasa dalam hal panjang. Default asli tetap di tabel dan berhenti dipakai untuk lalu lintas biasa, dan rute host ke server VPN mencegah tunnel menangkap paket luarnya sendiri. Kedua klien melakukan ini, dan yang kedua sekadar memasang pasangannya belakangan.

Itulah sebabnya tunnel pertama tampak mati, bukan terputus. Antarmukanya naik, kanal kontrolnya hidup, dan tidak ada lalu lintas aplikasi yang mencapainya lagi. Keluhan sebaliknya punya push yang sama-sama hilang: ponsel yang terhubung tetapi tidak mengirim apa pun biasanya berbicara dengan server yang tidak pernah mengumumkan redirect-gateway, jadi perangkat menyimpan default-nya sendiri dan hanya menjangkau pool.

Ambil cuplikan routing sebelum dan sesudah klien kedua terhubung. Dua setengah rute yang muncul di tabel adalah seluruh perubahannya, dan keduanya menjelaskan kedua keluhan. Tidak ada hal lain di tabel yang perlu bergeser agar gejalanya muncul. Itulah juga sebabnya menghapus klien kedua langsung memulihkan yang pertama.

Baca tunnel mana yang benar-benar menang

Jangan menyimpulkan pemenangnya dari urutan klien dimulai atau dari ikon di baki sistem. Tanyakan kepada kernel rute mana yang akan dipakai untuk tujuan di luar kedua jaringan privat, dan baca antarmuka yang dikembalikan.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Dua yang pertama adalah jawaban Linux dan dua yang terakhir padanan Windows. Jalankan keduanya saat kedua tunnel naik, lalu putuskan satu dan jalankan lagi. Perbedaan antara kedua keluaran adalah fakta yang Anda butuhkan sebelum memilih solusi, dan itu memakan waktu lebih singkat daripada membaca log salah satu klien.

Catat hasilnya, termasuk nama antarmuka dan prefiks yang cocok. Tiket yang mengatakan VPN kedua merusak yang pertama adalah deskripsi gejala, bukan pernyataan routing yang bisa ditindaklanjuti siapa pun. Pencarian mengubahnya menjadi fakta yang bisa direproduksi insinyur berikutnya dengan satu perintah.

Windows: cegah satu profil memiliki default

Windows menyimpan profil tersimpan, dan klien bawaan memungkinkan satu bergantung pada yang lain sehingga yang pertama naik otomatis saat yang kedua dial. Profil yang terhubung paling akhir cenderung mempertahankan default, jadi pemilik praktisnya adalah dial terakhir, bukan yang pertama. Beri setiap profil rute push-nya sendiri dan aktifkan split tunneling untuk profil yang tidak seharusnya memiliki default.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling mengubahnya: hanya prefiks yang didorong server yang masuk ke tabel, sehingga default tetap pada tunnel pertama. Desainnya tetap gagal jika kedua server mendorong rute default, karena saat itu koneksi terakhir menang dan tidak ada pengaturan sisi klien yang mengubahnya. Perbaiki push sisi server atau terima satu pemilik.

Profil yang dipicu aplikasi adalah fitur lain dan layak diketahui: profil Windows dapat mulai saat berkas eksekusi bernama diluncurkan, dengan filter lalu lintas yang menentukan apa yang dibawanya. Itu pengaturan profil, bukan aturan firewall, dan memecahkan masalah yang berbeda dari konflik rute default.

Linux: jauhkan tunnel kedua dari tabel utama

Menjalankan dua instans openvpn --config di satu mesin menempatkan kedua klien di tabel yang sama, dan tiga opsi memisahkannya dengan isolasi yang meningkat. Yang paling ringan adalah menghentikan klien kedua mengedit tabel sama sekali, memakai route-nopull dengan rute eksplisit, atau skrip route-up yang hanya memasang apa yang Anda maksud. Lalu tunnel kedua membawa persis prefiks yang Anda sebutkan dan tidak yang lain. Lalu Anda memutuskan prefiks mana ke mana alih-alih menemukannya belakangan.

Policy routing adalah opsi tengah. Sebuah aturan memilih tabel terpisah untuk satu alamat sumber atau tanda firewall, dan tabel itu membawa rute tunnel kedua. Penyaringan jalur balik adalah jebakannya di sini, karena balasan yang tiba di antarmuka berbeda dari yang akan dipilih tabel akan dibuang, jadi periksa setelan rp_filter sebelum menyimpulkan tunnel rusak.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Namespace jaringan adalah opsi terberat dan terbersih. Jalankan klien kedua di dalam ip netns, beri ia pasangan veth, dan masuk ke namespace itu untuk memakainya. Gangguan hilang karena setiap namespace memiliki tabelnya sendiri alih-alih berbagi satu, yang sepadan dengan penyiapan ekstra saat kedua tunnel harus tetap hidup ber minggu-minggu.

Per aplikasi, dan penyambungan sebagai masalah terpisah

Kadang hanya satu program yang seharusnya memakai tunnel kedua. Di Linux, policy routing per pengguna, cgroup, atau port mencapai hasil itu, dan satu tujuan dapat disematkan ke antarmuka tanpa menyentuh default sama sekali. Aplikasi yang menyematkan soketnya ke satu antarmuka tidak pernah berkonsultasi dengan tabel routing, jadi peluncur dapat terus memakai adaptor fisik sampai sebuah alamat dipilih di setelannya sendiri.

Penyambungan adalah operasi berbeda dari menjalankan dua tunnel berdampingan. Menyambung A di atas B berarti alamat server dalam harus dapat dijangkau dari dalam tunnel luar. Klien luar juga tidak boleh mengira paket terenkripsi klien dalam sebagai kebocoran. Satu klien di dalam mesin virtual adalah versi kasar tetapi andal; keduanya di satu host membutuhkan pekerjaan routing di atas plus jalur luar menuju server dalam yang tidak pernah masuk ke tunnel dalam.

Tuliskan pemilik default, daftar prefiks yang dibawa setiap tunnel, dan jalur DNS. Ketiga fakta itu mengubah insiden berikutnya menjadi pencarian alih-alih penyelidikan.