DNS titik akhir AWS Client VPN: mengapa menyematkan IP yang telah diselesaikan gagal

Minggu lepas dig +short memberikan satu alamat untuk nama titik akhir dalam profil AWS Client VPN anda, dan terowong itu bersambung. Minggu ini profil yang sama kekal di 'Connecting' pada komputer riba anda manakala salinan rakan sekerja yang tidak disentuh masih berfungsi. Tiada apa yang disekat dan sijil tidak tamat tempoh. Seseorang telah menggantikan nama hos titik akhir dengan alamat yang diselesaikan itu, dan perkhidmatan tidak lagi menjawab di sana. Nama yang dieksport ialah bahagian yang dibina untuk bertahan dengan perubahan itu.

Nama dalam profil anda mungkin bukan nama yang ditanya

Profil yang dieksport daripada Client VPN biasanya membawa remote-random-hostname. Dengan pilihan itu dihidupkan, klien membina label sekali guna, menyambungkannya dengan nama titik akhir menggunakan titik, dan menyelesaikan nama gabungan itu. Rekod wildcard dalam zon titik akhir menjawab mana-mana label, sebab itulah awalan yang direka masih diselesaikan dan sebab itulah helah ini kekal tidak kelihatan apabila anda cuba menghasilkan semula pertanyaan secara manual.

Jadi apabila anda menampal nama titik akhir ke terminal dan mendapat jawapan, anda telah menyelesaikan nama yang berbeza daripada yang digunakan oleh klien semasa menyambung. Ketidakpadanan itu bukan kecacatan yang perlu diperbaiki dalam profil. Label itu dijana semula dengan sengaja: pilihan itu menghalang cache daripada menyimpan jawapan lapuk, dan ia tidak pernah mengenal pasti mesin atau sesi anda.

Saya pernah menemui kes keserasian di mana klien mengabaikan pilihan itu sepenuhnya. AWS mendokumenkan jalan penyelesaiannya: kekalkan nama titik akhir yang sebenar dan tambah rentetan rawak serta titik di hadapannya, menganggapnya sebagai corak penamaan dan bukan nilai untuk ditampal. Menggunakannya pada klien lama adalah wajar; mengodkan rentetan berawalan itu sebagai titik akhir secara keras tidak wajar.

Mengapa jawapan yang disimpan tidak boleh kekal betul

Alamat titik akhir Client VPN diuruskan oleh AWS dan berubah dari semasa ke semasa, yang dinyatakan dengan jelas oleh dokumentasi amalan terbaik. Jawapan yang ditangkap hanyalah syot kilat bagi satu penyelesaian. Profil yang mengodkannya secara keras menjadi profil yang menuju hos yang telah dinyahaktifkan sebaik sahaja perkhidmatan berpindah, dan kegagalan itu jarang kelihatan seperti DNS: anda mendapat tamat masa sambungan atau handshake yang tersekat, jadi orang mengejar penghalaan dan sijil.

Jawapan yang sama dalam /etc/hosts mewarisi tamat tempoh yang sama dengan masalah tambahan. Entri hosts bertahan selepas but semula, eksport semula dan pembaikan 'pasang semula klien', jadi kegagalan kembali setiap kali alamat berpindah. Saya pernah melihat satu entri tidak berbahaya selama berminggu-minggu, kemudian melumpuhkan setiap mesin yang membawanya manakala pemasangan baharu bersambung seperti biasa. Perpecahan itu, satu kumpulan gagal dan satu lagi baik pada akaun yang sama, ialah petunjuk paling murah yang akan anda peroleh.

Hadkan skop pengacakan dengan betul. Ia berlaku bagi setiap percubaan sambungan. Terowong yang telah terbentuk tidak menyelesaikan semula titik akhirnya, tidak menukar pelayan di tengah-tengah sesi, dan permintaan aplikasi individu tidak masing-masing memilih hos VPN baharu. Hanya percubaan seterusnya menyelesaikan semula, sebab itulah sesi yang berfungsi sepanjang petang tidak memberitahu apa-apa tentang esok pagi.

Apa yang diperiksa perkhidmatan apabila terowong naik

Client VPN menghendaki alamat yang anda sambungi sepadan dengan alamat yang diselesaikan untuk nama DNS titik akhir. Satu keperluan itu menjelaskan beberapa kegagalan yang kelihatan tidak berkaitan: rekod DNS tersuai yang menunjuk ke tempat lain, frontend tersuai yang memajukan ke alamat titik akhir sebenar, dan profil yang ditulis semula ke alamat mentah. AWS mendokumenkan susunan rekod tersuai serta pemajuan sebagai kegagalan dengan klien kendalian AWS yang terkini. Semakannya sempit; ia bukan keputusan bahawa setiap alias dilarang.

Ia juga bukan peraturan umum tentang protokol VPN. remote berangka adalah sah sepenuhnya dalam penggunaan OpenVPN biasa, dan banyak yang berjalan begitu. Kekangan itu datang daripada susunan terurus, bukan daripada protokol di bawahnya.

Itulah yang menjadikan pelonggaran pengesahan sijil sebagai refleks yang salah. Jika profil gagal selepas pertukaran alamat, mematikan pengesahan pelayan memindahkan ralat itu dan bukannya membaiki penyelesaian atau keperluan padanan alamat, dan meninggalkan klien yang akan mempercayai apa sahaja. Kekalkan CA yang dieksport, pengesahan pelayan dan tetapan pengesahan bersama tepat seperti ketika ia datang.

Senarai kebenaran, egress dan DNS peribadi ialah tiga masalah berasingan

Peraturan firewall yang mesti membenarkan destinasi sebelum komputer riba bersambung berkaitan dengan pendengar luar. Berikan kepada pemilik rangkaian nama titik akhir, pengangkutan dan port yang dikonfigurasikan, kemudian tanyakan sama ada kawalan mereka boleh mengikuti tingkah laku DNS perkhidmatan. Peraturan yang menyimpan satu alamat yang ditangkap ialah syot kilat dengan tamat tempoh yang tidak tertulis. Jika kawalan hanya menerima destinasi yang tidak berubah, selesaikan jurang itu sebelum pelancaran dan bukannya mengodkan jawapan secara senyap.

Rakan kongsi yang memerlukan alamat sumber tetap untuk permintaan selepas terowong dinaikkan mempunyai keperluan lain: egress. Apa yang dilihat oleh laman web bergantung pada laluan aplikasi dan dasar terowong terpisah, bukan pada alamat yang disambungi oleh klien. Trafik terowong terpisah mungkin tidak menyentuh AWS sama sekali.

DNS peribadi di dalam terowong ialah lapisan ketiga. Penyelesai yang diberikan kepada klien menjawab nama dalaman selepas sambungan; ia tidak boleh menyelesaikan titik akhir awam sebelum terowong wujud. Kegagalan penyelesaian titik akhir dan kegagalan penyelesaian aplikasi dalaman berlaku pada peringkat berbeza, dan mencampurkannya membawa anda ke log yang salah.

Keluarga alamat tergolong dalam senarai yang sama. Jawapan IPv4 tidak memberitahu apa-apa tentang laluan yang dibenarkan bagi titik akhir IPv6 atau dwi-tindanan, jadi syot kilat yang diambil dalam satu keluarga bukan bukti untuk yang lain.

Periksa sambungan tanpa menyematkan apa-apa

Mulakan dengan profil seperti yang dieksport 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)'

Kemudian bandingkan tiga perkara: nama titik akhir yang dipegang profil, alamat yang dilaporkan klien untuk percubaan baharu, dan ke mana nama itu diselesaikan sekarang. Nama yang diselesaikan hanya membuktikan rekod itu menjawab; pengangkutan dan pengesahan adalah berasingan, dan titik akhir tidak perlu menjawab ping. Log klien sendiri ialah satu-satunya sumber untuk perkara tengah, jadi tangkapnya semasa percubaan dan bukan selepasnya.

Alamat yang menjawab hari ini ialah bukti tentang hari ini; nama itulah yang perkhidmatan kekalkan sah. Catat pemerhatian itu, hantarkannya kepada pemilik titik akhir, dan biarkan profil menunjuk ke nama itu.

Dua tabiat yang patut ditinggalkan: mematikan semakan sijil untuk melepasi handshake yang tersekat, dan menyusun label di hadapan nama titik akhir dengan harapan satu akan melekat. Label diselesaikan melalui rekod wildcard atau masalahnya di tempat lain. Jika profil yang dikonfigurasikan dengan betul masih gagal, hantar pertanyaan yang tepat dan peristiwa sambungan, bukan nama hos yang lebih panjang.

Sebelum menutupnya: profil masih membawa nama titik akhir yang dieksport, tiada fail hosts menyematkan alamat, remote dalam log klien sepadan dengan penyelesaian semasa, dan peraturan firewall menamakan titik akhir dan bukannya alamat. Itulah juga keadaan yang perlu diserahkan kepada orang seterusnya.