Nama titik akhir VPN versus nama layanan privat: dua pemilik

Dua nama bisa menggambarkan cabang yang sama dan menjawab pertanyaan yang sangat berbeda. vpn.branch.example memberi tahu rekan jarak jauh di mana menemukan titik akhir VPN, dan itu harus diresolusi sebelum ada terowongan apa pun. inventory.branch.example memberi tahu pengguna yang berwenang di mana aplikasi privat berada, dan itu baru penting setelah terowongan aktif. Merawat salah satunya tidak melakukan apa pun untuk yang lain.

Beri nama kedua catatan sebelum Anda men-debug salah satunya

Tulis keduanya beserta pemiliknya. Untuk titik akhir, catat siapa yang memperbarui alamat publik dan bagaimana klien VPN menyegarkan jawabannya. Untuk layanan, catat siapa yang memiliki alamat privat, zona mana yang menyimpan catatan itu, dan resolver mana yang seharusnya menjawabnya.

Daftar singkat itu mencegah kesalahan diagnosis paling umum di bidang ini: memulai ulang terowongan cabang yang berfungsi untuk memperbaiki catatan yang sepenuhnya hidup di dalamnya. Terowongan adalah transportasi bagi nama layanan; ia bukan otoritasnya.

Ketika perubahan diusulkan, tanyakan catatan mana dari keduanya yang tersentuh. Jika tidak ada yang bisa menjawab, perubahan itu belum siap dijadwalkan.

Titik akhir harus diresolusi sebelum ada terowongan apa pun

Misalkan koneksi internet cabang menerima alamat publik baru. Pembaru titik akhir menerbitkan alamat baru, dan implementasi VPN jarak jauh harus dapat membaca jawaban yang berubah. Resolver mana pun yang menyediakan jawaban itu harus dapat dijangkau tanpa terowongan, atau klien mengejar nama yang hanya bisa diresolusi setelah terhubung ke hal yang tidak dapat ditemukannya.

Ketergantungan bootstrap itu layak dinyatakan terang-terangan, karena mudah tercipta tanpa sengaja ketika semua resolver internal berada di belakang VPN. Pertahankan jalur pra-terowongan untuk pencarian titik akhir, dan konfirmasi perilaku penyambungan ulang klien alih-alih menganggap jawaban baru langsung diambil.

DNS dinamis juga memiliki batas yang tidak bisa dilewati pembaruan catatan. Memperbarui catatan tidak membuka port firewall, tidak membuat pemetaan NAT, dan tidak membuktikan identitas rekan. Alamat yang diterbitkan dengan port tertutup menghasilkan klien yang beresolusi benar dan tetap tidak bisa terhubung ke apa pun.

Terakhir, klien yang berjalan dapat terus memakai titik akhir yang di-cache hingga tersambung ulang. Pisahkan penerbitan, cache, dan kebijakan penyambungan ulang dalam catatan Anda, agar rekan yang usang tidak dikira pembaru yang rusak.

Nama layanan menggambarkan di mana aplikasi berada

Sekarang misalkan terowongan tetap sehat tetapi server inventaris berpindah dari 172.26.14.20 ke 172.26.14.35. Catatan titik akhir publik tidak terpengaruh, sedangkan catatan layanan privat harus berubah. Memakai alamat yang dicadangkan untuk layanan itu, atau penetapan statis, membuat ini lebih jarang; jalur pembaruan yang berwenang menangani saat hal itu memang disengaja.

Dua mekanisme pembaruan tercampur di sini. RFC 2136 mendefinisikan protokol untuk menambah dan menghapus catatan DNS dalam suatu zona, sedangkan penyedia DNS dinamis komersial dapat mengekspos API HTTP yang sama sekali berbeda untuk tujuan lain. Memakai salah satunya tidak berarti yang lain ada di lingkungan Anda. Periksa mekanisme mana yang benar-benar diterima zona Anda sebelum menulis pembaru terhadapnya.

Jawaban privat yang benar hanyalah syarat pertama. Agar pemanggil jarak jauh dapat memakainya, klien membutuhkan resolver yang membawa zona privat, kebijakan yang mengizinkan kueri ke resolver itu, dan penerusan untuk alamat yang kembali. Nama yang beresolusi ke alamat yang tidak dapat dijangkau klien menghasilkan waktu tunggu yang tampak seperti kesalahan server.

Uji kedua jalur secara terpisah

Periksa titik akhir dari luar terowongan dan layanan dari dalamnya, lalu simpan hasilnya sebagai dua fakta yang independen:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Jika kueri pertama gagal, masalahnya ada pada penerbitan publik atau jalur resolusi pra-terowongan, dan tidak ada perubahan internal yang akan membantu. Jika yang kedua mengembalikan alamat tetapi yang ketiga tidak menunjukkan rute melalui terowongan, lapisan DNS baik-baik saja dan kebijakan penerusan tidak.

Jalankan pasangan itu setelah setiap perubahan alamat, dan catat catatan mana yang berpindah. Serah terima yang hanya mengatakan «DNS sudah diperbarui» membuat insinyur berikutnya menebak siklus hidup mana dari kedua itu yang benar-benar berjalan.