Siapa yang harus memiliki rute dan DNS saat openfortivpn terhubung?

Empat tahap bertumpuk satu sama lain dalam sesi openfortivpn yang berfungsi. Klien mengautentikasi ke gateway dan memulai koneksi TLS, lalu menjalankan PPP di dalam koneksi itu, kemudian menerima alamat dan informasi DNS, dan akhirnya menerapkan rute host serta pengaturan resolver. Setiap tahap dapat hidup sementara tahap berikutnya tidak, dan itulah sebabnya “terhubung” menjadi kata yang begitu licin di utas dukungan.

Keputusan yang menghilangkan sebagian besar kebingungan adalah siapa yang memiliki tahap terakhir. Entah klien VPN menerapkan sendiri perubahan host, atau komponen lain yang melakukannya, dan mencampur keduanya setengah jalan adalah cara rute dan berkas resolver akhirnya menggambarkan sesi yang berbeda.

Empat tahap yang tampak seperti satu koneksi

Tahap pertama adalah penerimaan. domain autentikasi bernama atau kode sekali pakai, dan menerima parameter yang dibutuhkannya untuk melanjutkan. Ketika klien mencetak bahwa ia terhubung ke gateway, itu berarti transport TLS menyala. Itu tidak berarti PPP sudah bernegosiasi, dan jelas tidak berarti aplikasi internal dapat dijangkau.

Tahap kedua adalah tautan PPP. Klien memulai proses PPP terhadap perangkat terowongan, dan kedua sisi bernegosiasi opsi tautan dan alamat. Baru setelah itu host tahu alamat lokal dan jarak jauh mana yang dipakai sesi, dan baru saat itulah rute yang menunjuk ke terowongan masuk akal.

Tahap ketiga adalah menerapkan informasi itu ke host, dan di sinilah kepemilikan penting. Klien dapat menambahkan rute dan menulis ulang konfigurasi resolver, atau dapat diperintahkan mundur dan menyerahkan keduanya kepada apa pun yang mengelola jaringan di mesin itu. README proyek menggambarkan semuanya sebagai tanggung jawab terpisah alih-alih satu perilaku otomatis.

Siapa yang menyunting tabel perutean

Secara bawaan klien adalah pemiliknya. Ia menambahkan rute menuju gateway melalui antarmuka fisik, rute untuk rekan terowongan, dan rute untuk jaringan yang boleh digunakan sesi, lalu menghapusnya saat proses keluar. Bawaan itu nyaman di laptop dengan satu manajer jaringan dan tanpa perangkat lunak VPN lain.

Pilih penyerahan hanya ketika hal lain benar-benar memiliki perutean. Integrasi manajer jaringan, ruang nama jaringan kontainer, atau agen perutean seluruh situs mungkin sudah tahu cara memasang dan membersihkan prefiks yang sama. Melewatkan opsi no-routes lalu mencegah dua penulis berebut tabel yang sama, yang merupakan perlombaan yang muncul sebagai hilangnya satu subnet secara berkala alih-alih kegagalan bersih.

Tumpang tindih adalah alasan kedua untuk menyerahkan. Jika rute yang didorong menyertakan prefiks yang sudah dipakai jaringan lokal, klien tidak dapat menyelesaikan konflik untuk Anda. Seseorang harus memutuskan apakah prefiks itu dapat dijangkau melalui terowongan, melalui tautan fisik, atau melalui rute yang lebih spesifik, dan keputusan itu milik siapa pun yang memiliki topologi.

Pembersihan adalah yang ketiga. Klien yang crash sebelum menghapus rutenya meninggalkan lubang hitam yang hidup lebih lama dari sesi, dan koneksi berikutnya dapat menambahkan duplikat di atasnya. Siapa pun yang memiliki perutean juga memiliki verifikasi bahwa entri lama sudah hilang. Jadikan pemeriksaan itu bagian dari jalur start, bukan langkah pembersihan opsional.

Siapa yang memiliki DNS dan berkas resolver

DNS adalah keputusan yang sama dengan tepi yang lebih tajam. Klien dapat menerima server DNS yang dilaporkan gateway atau rekan PPP dan menuliskannya ke konfigurasi resolver host. Di mesin sederhana itulah yang Anda inginkan, karena nama internal kemudian hanya diselesaikan selama terowongan menyala.

Di host Linux modern resolver dapat dikelola oleh stub lokal, dan menulis ulang berkas resolver di belakang stub itu menghasilkan konfigurasi yang tampak benar dan berperilaku tidak konsisten. Jika host sudah menjalankan manajer resolver, biarkan itu memiliki DNS dan beri ia server terowongan melalui antarmuka yang didukungnya. Opsi no-dns klien adalah pilihan yang tepat di sana, bukan akal-akalan.

DNS terpisah adalah pertanyaan berbeda dari siapa yang menulis berkas. Mengirim setiap kueri melalui terowongan itu sederhana dan lambat; mengirim hanya zona internal melaluinya memerlukan konfigurasi per domain yang tidak disediakan sebagian besar klien sederhana. Putuskan perilaku mana yang dibutuhkan host sebelum mengaktifkan perubahan resolver klien. Pilihan yang salah di sini tampak seperti gangguan resolusi nama bahkan ketika terowongannya sendiri baik.

Hak istimewa, kesiapan, dan penyerahan

Membuat perangkat terowongan dan menyunting rute host atau status resolver memerlukan otoritas jaringan yang ditinggikan. Kesalahan umum adalah menyimpulkan bahwa karena itu semuanya harus berjalan sebagai root, termasuk peramban atau aplikasi yang menggunakan terowongan. Jaga bagian istimewa tetap kecil: klien dan berkas konfigurasinya, dimiliki administrator, sementara aplikasi pengguna mempertahankan akun normalnya.

Kesiapan harus didefinisikan per konsumen. Supervisor dapat menganggap layanan mulai ketika proses klien berjalan dan perangkat terowongan ada. Pekerjaan cadangan harus menganggap VPN dapat digunakan hanya ketika titik akhir penyimpanannya menjawab melalui terowongan. Itu pemeriksaan yang berbeda, dan memakai yang lebih lemah untuk tujuan yang lebih kuat menghasilkan pekerjaan yang mulai terlalu awal dan gagal secara berkala. Tuliskan definisi yang dipilih, karena supervisor dan pekerjaan yang tidak setuju tentang kesiapan adalah tiket dukungan yang menunggu terjadi.

Uji kontrak dengan empat pengamatan: fase gateway selesai, PPP memberikan alamat, rute yang dimaksud ada, dan permintaan ke host internal berhasil. Lalu hentikan klien dan pastikan setiap hal itu dihapus atau dipulihkan. Jika host masih menyelesaikan nama internal atau masih memegang rute setelah terowongan ditutup, penyerahan kepemilikan belum lengkap.