Daftar izin endpoint VPN: Penyegaran DNS yang Anda lupakan

Mengetik vpn.example.com ke dalam pengecualian firewall terasa seperti berlangganan DNS. Yang biasanya terjadi adalah penerjemahan saat dimuat, setelah itu aturan menyimpan alamat dan tidak ada yang menyegarkannya. Dua komponen kini berbagi tugas: resolver yang menjawab dan firewall yang menyimpan. Sebagian besar gangguan endpoint dimulai di tempat penyerahan itu tidak pernah dirancang.

Nama host dalam aturan bukan langganan langsung

Beberapa alat menyelesaikan nama saat konfigurasi dimuat; yang lain menyimpan nama host dan menyelesaikannya ulang sesuai jadwal sendiri; yang lain lagi hanya menerima alamat. Konfigurasi yang terlihat jarang menyatakan yang mana. Contoh dokumentasi biasanya mengasumsikan kasus waktu muat, itulah sebabnya perbedaan ini mengejutkan orang saat migrasi. Baca perilaku implementasinya sebelum menganggap perubahan alamat akan diperhatikan, karena daftar izin yang sudah usang terlihat persis seperti yang berfungsi sampai endpoint berpindah.

Aturan yang menyebut host yang benar tetap bisa mengizinkan alamat yang salah. Celah itulah mitosnya, bukan kesalahan ejaan.

TTL cache bukan pengatur waktu firewall Anda

Catatan DNS membawa waktu hidup, dan resolver menyimpan jawaban di cache selama periode itu. Spesifikasi DNS mendefinisikan perilaku cache itu, tetapi mengatur data DNS, bukan penyimpanan alamat terpisah milik firewall. TTL pendek tidak menciptakan pekerjaan penyegaran di tempat yang tidak ada. Cache juga terjadi di lebih dari satu lapisan, jadi jawaban yang dilihat terminal mungkin bukan yang dilihat firewall.

Ajukan tiga pertanyaan kepada produk sebenarnya: kapan ia menyelesaikan, di mana ia menyimpan hasilnya, dan apa yang memicu pembaruan. Jika jawabannya hanya saat boot, sesi berumur panjang bisa hidup lebih lama daripada alamat yang menerimanya.

dig +short vpn.example.com
resolvectl query vpn.example.com

Rancang penyegaran dan kegagalan sebagai satu kebijakan

Pengecualian yang dipelihara memerlukan jawaban eksplisit: apa yang memicu penyegaran sebelum klien memilih alamat baru, bagaimana set yang diizinkan berubah tanpa membuka jendela sementara yang lebar, dan kapan entri usang dihapus. Tulis jawaban itu di samping aturan.

Pilih perilaku kegagalan dengan sengaja. Mempertahankan alamat lama dapat menyelamatkan sesi dan meninggalkan izin usang; membersihkan set dapat menghambat pemulihan. Keduanya tidak boleh menjadi hasil kebetulan dari pencarian yang gagal. Tulis perilaku yang dipilih ke runbook agar operator berikutnya tidak berimprovisasi di bawah tekanan.

Jaga juga DNS bootstrap tetap sempit. Pengecualian resolver publik tanpa syarat adalah jalur DNS langsung untuk semua yang cocok, bukan hanya untuk nama endpoint.

Buktikan perubahan endpoint, bukan koneksi pertama

Gunakan manajer yang didukung klien jika sudah mengoordinasikan resolusi dan pemblokiran. Pada host PF yang dikelola situs, pertahankan kepemilikan dan rencana pemulihan situs alih-alih menyalin sintaks tabel nama host dari platform lain dengan perilaku siklus hidup berbeda.

Dengan uji yang disetujui dan tidak berbahaya, bandingkan alamat yang dipilih klien dengan set izin aktif sebelum dan sesudah perubahan terkendali. Cakup pencarian gagal, penghapusan entri yang tidak lagi valid, dan, jika didukung, keluarga alamat berbeda. Tunnel yang dimaksud harus pulih sementara lalu lintas langsung yang tidak terkait tetap dalam kebijakan. Koneksi pertama yang berhasil hanya membuktikan bahwa terjemahan awal kebetulan benar.