DNS di AWS Client VPN: guna resolver VPC, bukan subnet

Endpoint berada dalam 10.0.8.0/24, jadi resolver mesti 10.0.8.2. Itulah hujah yang paling kerap saya dengar, dan ia salah dua kali. Route 53 Resolver menjawab pada julat IPv4 utama VPC tambah dua, yang bagi VPC 10.0.0.0/16 ialah 10.0.0.2, tidak kira subnet mana yang digunakan oleh endpoint. Kesalahan kedua lebih senyap: meletakkan alamat yang betul dalam endpoint tidak bermakna sistem pengendalian klien pernah bertanya apa-apa kepadanya. Kedua-dua kesalahan menghasilkan gejala yang sama: penyelesaian nama berfungsi pada sesetengah klien dan gagal pada yang lain.

Mitos bermula dengan perkaitan subnet

Perkaitan adalah tentang di mana antara muka rangkaian elastik bagi sambungan klien berada, bukan tentang alamat resolver mana yang wujud. Subnet endpoint memberi klien alamat dalam VPC, dan setiap satunya tidak membawa resolver sendiri.

Sebaik anda memisahkan kedua-dua idea itu, aritmetik tidak lagi misteri dan penyelesaian masalah berpindah kepada klien, tempat kebanyakan kes ini sebenarnya berakhir.

Kira alamat daripada julat utama VPC

Ambil CIDR IPv4 utama VPC dan tambah dua pada alamat rangkaian. 10.0.0.0/16 memberi 10.0.0.2, 172.31.0.0/16 memberi 172.31.0.2, dan VPC dengan julat sekunder mengekalkan resolver pada julat utama. Subnet 10.0.8.0/24 di dalam VPC itu tidak mengalihkannya. Tulis alamat di sebelah ID VPC sebelum anda menyentuh endpoint, kerana nombor itu sifat VPC dan bukan sifat sambungan.

VPC juga menjawab pada alamat link-local 169.254.169.253. Alamat itu boleh dicapai dari dalam VPC, tetapi ia bukan destinasi berhalakan umum bagi komputer riba di hujung lain terowong.

Jadi ada dua alamat resolver yang sah, dan tiada satu pun daripadanya ialah subnet tambah dua.

Apa yang tetapan endpoint lakukan dan apa yang tidak

Endpoint Client VPN mempunyai medan pelayan DNS, dan di tempat konsol menawarkan pilihan resolver VPC ia mengisi idea yang sama. Menetapkannya mengubah apa yang diserahkan perkhidmatan kepada klien semasa penyediaan sambungan. Ia tidak mengubah apa yang dilakukan klien OpenVPN tidak terurus dengan nilai itu, kerana klien masih perlu menerapkannya pada sistem pengendalian. Dari jurang itulah datang «berfungsi pada Mac saya tetapi tidak pada mesin Linux».

Pada Linux integrasi resolver dimiliki pengurus sambungan dan bukan pengguna. Menyunting /etc/resolv.conf dengan tangan membuktikan alamat itu berfungsi untuk satu sesi lalu hilang semasa sambung semula — sebab itu banyak kes yang telah dibaiki kembali semula keesokan paginya.

Periksa resolver aktif pada klien selepas bersambung, bukan halaman konfigurasi endpoint.

Split tunneling boleh mengalahkan resolver yang betul

Dengan split tunneling hanya laluan yang ditolak ke dalam terowong digunakan. Jika alamat resolver tidak diliputi laluan, pertanyaan keluar melalui antara muka setempat dan dijawab oleh penghala rumah anda. Alamat dalam endpoint masih betul dan carian masih gagal. Tambah laluan untuk resolver, kemudian uji lagi.

Julat setempat yang bertindih memberi hasil yang sama dengan cara lebih menyakitkan: pertanyaan dijawab, cuma oleh pelayan yang salah.

Jangan buka kumpulan keselamatan untuk alamat Amazon DNS

Naluri apabila carian tamat masa ialah menambah peraturan yang membenarkan UDP 53 ke alamat resolver. AWS mendokumenkan bahawa kumpulan keselamatan dan ACL rangkaian tidak menapis trafik Amazon DNS seperti ia menapis trafik ke instans DNS tersuai. Membuka peraturan itu tidak mengubah apa-apa bagi resolver VPC dan meluaskan sempadan tanpa sebab. Resolver yang anda jalankan sendiri ialah kes lain dan memang memerlukan peraturannya sendiri.

Jika kedua-duanya muncul dalam reka bentuk anda, periksa ke mana klien sebenarnya menghala sebelum menyunting mana-mana peraturan.

Sahkan laluan, kemudian ukur sesuatu yang lain

Selesaikan nama awam, selesaikan nama peribadi yang didaftarkan dalam zon hos peribadi yang dikaitkan dengan VPC, dan baca resolver aktif klien antara keduanya. Urutan itu memisahkan «alamat resolver salah» daripada «zon tidak dikaitkan» dan daripada «klien mengabaikan tetapan». Setiap satu ada pembaikan berbeza, dan tiada satu pun masalah daya pemprosesan.

Carian yang berjaya tidak berkata apa-apa tentang kelajuan pemindahan berterusan, jadi pisahkan kedua-dua perbualan itu semasa melapor.