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

Endpoint berada di 10.0.8.0/24, jadi resolver harus 10.0.8.2. Itu alasan yang paling sering saya dengar, dan salah dua kali. Route 53 Resolver menjawab pada rentang IPv4 utama VPC plus dua, yang untuk VPC 10.0.0.0/16 adalah 10.0.0.2, berapa pun subnet yang dipakai endpoint. Kesalahan kedua lebih sunyi: menaruh alamat yang benar di endpoint bukan berarti sistem operasi klien pernah menanyakannya. Kedua kesalahan menghasilkan gejala yang sama: resolusi nama berhasil pada sebagian klien dan gagal pada klien lain.

Mitos dimulai dari asosiasi subnet

Asosiasi adalah soal di mana antarmuka jaringan elastis untuk koneksi klien berada, bukan soal alamat resolver mana yang ada. Subnet endpoint memberi klien alamat di dalam VPC, dan masing-masing tidak membawa resolver sendiri.

Begitu Anda memisahkan kedua gagasan itu, aritmetikanya tidak lagi misterius dan pemecahan masalah berpindah ke klien, tempat sebagian besar kasus ini sebenarnya berakhir.

Hitung alamat dari rentang utama VPC

Ambil CIDR IPv4 utama VPC dan tambahkan dua ke alamat jaringan. 10.0.0.0/16 memberi 10.0.0.2, 172.31.0.0/16 memberi 172.31.0.2, dan VPC dengan rentang sekunder menyimpan resolver pada rentang utama. Subnet 10.0.8.0/24 di dalam VPC itu tidak memindahkannya. Tuliskan alamat di samping ID VPC sebelum Anda menyentuh endpoint, karena angka itu properti VPC, bukan koneksi.

VPC juga menjawab pada alamat link-local 169.254.169.253. Alamat itu bisa dijangkau dari dalam VPC, tetapi bukan tujuan terutekan umum bagi laptop di ujung lain terowongan.

Jadi ada dua alamat resolver yang valid, dan tidak satu pun merupakan subnet plus dua.

Apa yang dilakukan setelan endpoint dan apa yang tidak

Endpoint Client VPN memiliki kolom server DNS, dan di tempat konsol menawarkan opsi resolver VPC, ia mengisi gagasan yang sama. Mengaturnya mengubah apa yang diserahkan layanan kepada klien saat penyiapan koneksi. Itu tidak mengubah apa yang dilakukan klien OpenVPN tak terkelola dengan nilai tersebut, karena klien tetap harus menerapkannya ke sistem operasi. Dari celah itulah muncul «berhasil di Mac saya tetapi tidak di mesin Linux».

Di Linux integrasi resolver dimiliki manajer koneksi dan bukan pengguna. Menyunting /etc/resolv.conf dengan tangan membuktikan alamat itu bekerja untuk satu sesi lalu hilang saat menyambung ulang — itulah sebabnya begitu banyak kasus yang sudah diperbaiki kembali lagi esok pagi.

Periksa resolver aktif di klien setelah terhubung, bukan halaman konfigurasi endpoint.

Split tunneling bisa mengalahkan resolver yang benar

Dengan split tunneling hanya rute yang didorong ke terowongan yang dipakai. Jika alamat resolver tidak tercakup rute, kueri keluar lewat antarmuka lokal dan dijawab router rumah Anda. Alamat di endpoint tetap benar dan pencarian tetap gagal. Tambahkan rute untuk resolver, lalu uji lagi.

Rentang lokal yang tumpang tindih memberi hasil sama dengan cara lebih menjengkelkan: kueri dijawab, hanya oleh server yang salah.

Jangan buka security group untuk alamat Amazon DNS

Naluri saat pencarian habis waktu adalah menambahkan aturan yang mengizinkan UDP 53 ke alamat resolver. AWS mendokumentasikan bahwa security group dan ACL jaringan tidak menyaring lalu lintas Amazon DNS seperti mereka menyaring lalu lintas ke instans DNS khusus. Membuka aturan itu tidak mengubah apa pun bagi resolver VPC dan memperlebar batas tanpa alasan. Resolver yang Anda jalankan sendiri adalah kasus lain dan memang perlu aturannya sendiri.

Jika keduanya muncul dalam desain Anda, periksa ke mana klien sebenarnya mengarah sebelum menyunting aturan apa pun.

Verifikasi jalurnya, lalu ukur hal lain

Selesaikan nama publik, selesaikan nama privat yang terdaftar di zona terkelola privat yang terkait dengan VPC, lalu baca resolver aktif klien di antara keduanya. Urutan itu memisahkan «alamat resolver salah» dari «zona tidak terkait» dan dari «klien mengabaikan setelan». Masing-masing punya perbaikan berbeda, dan tidak satu pun merupakan masalah throughput.

Pencarian yang berhasil tidak mengatakan apa pun tentang kecepatan transfer berkelanjutan, jadi pisahkan kedua percakapan itu saat melapor.