Nama DNS privat atau sekadar IP? Putuskan sebelum membagikannya

Dua pertanyaan bercampur ketika sebuah layanan privat dibuka untuk pengguna jarak jauh. Yang pertama adalah nama apa yang harus dipakai klien; yang kedua adalah sumber mana yang harus diterima layanan. Jawab keduanya dalam urutan itu, karena nama yang benar di balik aturan akses yang salah tetap gagal, dan aturan yang benar di balik nama yang tidak ter-resolve tidak pernah diuji sama sekali.

Syarat pertama: jalur resolver mana yang dimiliki klien?

Nama privat hanya berfungsi jika resolver klien dapat menjawabnya. Artinya, klien jarak jauh yang sah harus menjangkau server DNS yang memegang zona, baik melalui terowongan maupun melalui resolver yang sudah dijalankan organisasi untuk pengguna jarak jauh. Terowongan adalah transportasi, bukan direktori. Ia memberi klien jalur ke resolver, dan tidak memberi tahu klien zona mana yang harus ditanyakan.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Resolver publik tidak akan mempelajari zona privat karena laptop tersambung ke VPN.

Sufiksnya layak mendapat perhatian yang sama. Gunakan subdomain dari domain yang dikendalikan organisasi, agar kepemilikan dan perencanaan sertifikat tetap eksplisit. Hindari .local: spesifikasi multicast DNS mengikat sufiks itu ke resolusi link-local, dan terowongan yang dirutekan tidak mereproduksi perilaku itu untuk Anda.

Syarat kedua: sumber mana yang diterima layanan?

Aturan penerimaan ditulis terhadap alamat, jadi pertanyaan yang berguna adalah alamat mana yang dilihat layanan setelah perutean dan penerjemahan. Untuk layanan contoh di 10.20.30.40, klien kantor datang dari 10.20.30.0/24 dan klien jarak jauh dari kumpulan terpisah seperti 10.99.0.0/24.

Jika gateway menerjemahkan kumpulan jarak jauh, layanan melihat penerjemah, dan aturan yang ditulis untuk 10.99.0.0/24 tidak akan cocok.

Bacalah ini dari sisi layanan, bukan dari sisi klien. Log pendengar atau tangkapan paket di host layanan menunjukkan sumber yang benar-benar tiba; alamat klien sendiri hanyalah dugaan tentang apa yang bertahan melewati jalur.

Syarat ketiga: apakah nama terikat pada layanan atau pada host?

Nama yang menunjuk ke alamat satu mesin mengikat setiap klien ke mesin itu. Nama yang menunjuk ke penyeimbang beban atau alamat layanan yang stabil bertahan saat host di belakangnya diganti. Pilih dengan sadar, karena mengubahnya nanti berarti mengubah markah setiap klien dan subjek setiap sertifikat.

Untuk satu layanan internal, catatan langsung biasanya baik dan lebih mudah dipikirkan.

Untuk apa pun yang akan diganti, dibangun ulang, atau diskalakan, ujung depan yang stabil layak mendapat konfigurasi tambahan. Ujinya sederhana: jika Anda dapat mengganti backend tanpa memberi tahu pengguna, nama terikat pada layanan; jika tidak, nama terikat pada host.

Uji kedua keputusan secara terpisah

Resolve dulu, lalu hubungkan. Uji resolusi yang mengembalikan alamat yang diharapkan membuktikan jalur nama dan tidak mengatakan apa pun tentang penerimaan. Uji koneksi membuktikan jalur dan aturan sekaligus, jadi jalankan hanya setelah resolusi berhasil.

curl -sv --max-time 5 https://files.corp.example/health

Lalu uji satu sumber terlarang sekali, dan catat hasilnya.

Simpan kedua catatan secara terpisah dalam dokumentasi Anda: nama dan zonanya, sumber yang diterima, dan pemilik aturan. Ketika yang satu berubah, yang lain tidak harus ikut.

Di mana keputusan biasanya salah

Kegagalan umum adalah layanan yang dipublikasikan dengan nama yang hanya ter-resolve di jaringan kantor, dengan aturan penerimaan yang hanya menerima rentang kantor. Pengguna jarak jauh lalu melaporkan layanan rusak yang sebenarnya adalah dua kelalaian terpisah. Kegagalan umum kedua adalah kebalikannya: aturan penerimaan luas yang ditambahkan untuk menghilangkan masalah nama membuat layanan dapat dijangkau dari sumber yang tidak diniatkan siapa pun. Keduanya kelalaian konfigurasi, dan dari kursi pengguna keduanya tampak sama.

Tidak satu pun kesalahan itu terlihat dari satu uji yang berhasil. Itulah sebabnya kedua keputusan layak mendapat catatan terpisah dan uji terpisah, bahkan ketika orang yang sama mengambil keduanya.

Tuliskan keduanya sebelum layanan berjalan, karena perubahan berikutnya akan lebih mudah dipikirkan. Catatannya singkat: satu baris untuk nama dan zonanya, satu baris untuk sumber yang diterima dan pemilik aturan.