DNS endpoint AWS Client VPN: mengapa menyematkan IP yang sudah diresolusi gagal

Pekan lalu dig +short memberi Anda satu alamat untuk nama endpoint di profil AWS Client VPN Anda, dan terowongan terhubung. Pekan ini profil yang sama tertahan di 'Connecting' di laptop Anda sementara salinan kolega yang tidak tersentuh masih berfungsi. Tidak ada yang diblokir dan sertifikat tidak kedaluwarsa. Seseorang mengganti nama host endpoint dengan alamat hasil resolusi itu, dan layanan tidak lagi menjawab di sana. Nama yang diekspor adalah bagian yang dibangun untuk bertahan dari perubahan itu.

Nama di profil Anda mungkin bukan nama yang ditanyakan

Profil yang diekspor dari Client VPN umumnya membawa remote-random-hostname. Dengan opsi itu aktif, klien membangun label sekali pakai, menggabungkannya dengan nama endpoint memakai titik, dan meresolusi nama gabungan. Catatan wildcard di zona endpoint menjawab label apa pun, itulah sebabnya awalan yang dibuat-buat tetap teresolusi dan mengapa triknya tidak terlihat saat Anda mencoba mereproduksi kueri secara manual.

Jadi saat Anda menempelkan nama endpoint ke terminal dan mendapat jawaban, Anda telah meresolusi nama yang berbeda dari yang dipakai klien saat terhubung. Ketidakcocokan itu bukan cacat yang harus diperbaiki di profil. Label dibuat ulang dengan sengaja: opsi itu mencegah cache menyimpan jawaban lama, dan tidak pernah mengidentifikasi mesin atau sesi Anda.

Saya pernah menemui kasus kompatibilitas ketika klien sama sekali mengabaikan opsi itu. AWS mendokumentasikan jalan keluarnya: pertahankan nama endpoint yang sebenarnya dan tambahkan string acak plus titik di depannya, memperlakukannya sebagai pola penamaan, bukan nilai untuk ditempel. Menerapkannya pada klien lama masuk akal; melakukan hardcode string berawalan sebagai endpoint tidak.

Mengapa jawaban yang disimpan tidak bisa tetap benar

Alamat endpoint Client VPN dikelola AWS dan berubah seiring waktu, yang dinyatakan tegas oleh dokumentasi praktik terbaik. Jawaban yang ditangkap hanyalah snapshot satu resolusi. Profil yang melakukan hardcode akan menjadi profil yang membidik host yang sudah dinonaktifkan begitu layanan berpindah, dan kegagalannya jarang terlihat seperti DNS: Anda mendapat timeout koneksi atau handshake yang macet, sehingga orang mengejar routing dan sertifikat.

Jawaban yang sama di /etc/hosts mewarisi kedaluwarsa yang sama dengan masalah tambahan. Entri hosts bertahan dari reboot, ekspor ulang, dan perbaikan 'instal ulang klien', jadi kegagalan kembali setiap kali alamat berpindah. Saya pernah melihat satu entri tidak berbahaya selama berminggu-minggu, lalu melumpuhkan setiap mesin yang membawanya sementara instalasi baru terhubung normal. Pemisahan itu, satu kelompok gagal dan kelompok lain baik-baik saja di akun yang sama, adalah petunjuk termurah yang akan Anda dapatkan.

Batasi cakupan pengacakan dengan benar. Itu terjadi per percobaan koneksi. Terowongan yang sudah terbentuk tidak meresolusi ulang endpoint-nya, tidak berganti server di tengah sesi, dan permintaan aplikasi individual tidak masing-masing memilih host VPN baru. Hanya percobaan berikutnya yang meresolusi lagi, itulah sebabnya sesi yang berfungsi sepanjang sore tidak mengatakan apa pun tentang besok pagi.

Apa yang diperiksa layanan saat terowongan naik

Client VPN mensyaratkan alamat yang Anda tuju cocok dengan alamat yang diresolusi untuk nama DNS endpoint. Satu syarat itu menjelaskan beberapa kegagalan yang tampak tidak berhubungan: catatan DNS khusus yang menunjuk ke tempat lain, frontend khusus yang meneruskan ke alamat endpoint yang sebenarnya, dan profil yang ditulis ulang ke alamat mentah. AWS mendokumentasikan susunan catatan khusus plus penerusan sebagai kegagalan dengan klien bawaan AWS yang baru. Pemeriksaannya sempit; itu bukan putusan bahwa setiap alias dilarang.

Itu juga bukan aturan umum tentang protokol VPN. remote numerik sepenuhnya sah di penerapan OpenVPN biasa, dan banyak yang berjalan begitu. Batasannya berasal dari susunan terkelola, bukan dari protokol di bawahnya.

Itulah yang membuat pelonggaran verifikasi sertifikat menjadi refleks yang salah. Jika profil gagal setelah pergantian alamat, menonaktifkan verifikasi server memindahkan kesalahan alih-alih memperbaiki resolusi atau syarat kecocokan alamat, dan meninggalkan klien yang akan memercayai apa pun. Pertahankan CA yang diekspor, verifikasi server, dan pengaturan autentikasi timbal balik persis seperti saat datang.

Daftar izin, egress, dan DNS privat adalah tiga masalah terpisah

Aturan firewall yang harus mengizinkan tujuan sebelum laptop terhubung berkaitan dengan listener luar. Berikan nama endpoint, transport, dan port yang dikonfigurasi kepada pemilik jaringan, lalu tanyakan apakah kendali mereka dapat mengikuti perilaku DNS layanan. Aturan yang menyimpan satu alamat tertangkap adalah snapshot dengan kedaluwarsa yang tidak tertulis. Jika kendali hanya menerima tujuan yang tidak berubah, selesaikan celah itu sebelum peluncuran alih-alih diam-diam melakukan hardcode jawaban.

Mitra yang membutuhkan alamat sumber tetap untuk permintaan setelah terowongan naik punya syarat lain: egress. Apa yang dilihat situs web bergantung pada rute aplikasi dan kebijakan split-tunnel, bukan pada alamat yang dituju klien. Lalu lintas split-tunnel mungkin tidak pernah menyentuh AWS sama sekali.

DNS privat di dalam terowongan adalah lapisan ketiga. Resolver yang diberikan ke klien menjawab nama internal setelah koneksi; ia tidak dapat meresolusi endpoint publik sebelum terowongan ada. Kegagalan resolusi endpoint dan kegagalan resolusi aplikasi internal terjadi pada tahap berbeda, dan mencampurnya mengirim Anda ke log yang salah.

Keluarga alamat termasuk dalam daftar yang sama. Jawaban IPv4 tidak mengatakan apa pun tentang jalur yang diizinkan untuk endpoint IPv6 atau dual-stack, jadi snapshot yang diambil pada satu keluarga bukan bukti untuk yang lain.

Periksa koneksi tanpa menyematkan apa pun

Mulailah dari profil sebagaimana diekspor dan baca apa yang sebenarnya diminta:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Lalu bandingkan tiga hal: nama endpoint yang dipegang profil, alamat yang dilaporkan klien untuk percobaan baru, dan ke apa nama itu teresolusi sekarang. Nama yang teresolusi hanya membuktikan catatan itu menjawab; transport dan autentikasi terpisah, dan endpoint tidak perlu menjawab ping. Log klien sendiri adalah satu-satunya sumber untuk butir tengah, jadi tangkap saat percobaan, bukan sesudahnya.

Alamat yang menjawab hari ini adalah bukti tentang hari ini; nama adalah hal yang layanan jaga tetap valid. Catat pengamatan itu, kirim ke pemilik endpoint, dan biarkan profil menunjuk ke nama.

Dua kebiasaan yang harus ditinggalkan: menonaktifkan pemeriksaan sertifikat untuk melewati handshake yang macet, dan menumpuk label di depan nama endpoint berharap salah satunya menempel. Label teresolusi lewat catatan wildcard atau masalahnya di tempat lain. Jika profil yang dikonfigurasi dengan benar tetap gagal, kirim kueri persis dan peristiwa koneksi, bukan nama host yang lebih panjang.

Sebelum menutupnya: profil masih membawa nama endpoint yang diekspor, tidak ada berkas hosts yang menyematkan alamat, remote di log klien cocok dengan resolusi saat ini, dan aturan firewall menyebut endpoint, bukan alamat. Itu juga keadaan yang harus diserahkan ke orang berikutnya.