StrongSwan mengirim alamat DNS yang tidak bisa dijangkau Mac

Semua berjalan sampai seseorang membuka MacBook. Tunnel terbentuk, host internal menjawab berdasarkan alamat, dan resolusi nama mati. Di iPhone profil yang sama berperilaku sama, sementara klien Windows dan Linux baik-baik saja. Biasanya atribut DNS yang dikirim adalah penyebabnya: server membagikan alamat antarmuka publiknya sendiri, dan klien IKEv2 Apple tidak mengirim kueri ke sana melalui tunnel. Pindahkan resolver ke dalam pool dan gejalanya hilang tanpa menyentuh klien.

Gejala menunjuk ke alamat yang dikirim

Ketika hanya beberapa platform gagal, tunnel dan kredensial hampir pasti benar, karena keduanya dibagi. Yang berbeda adalah bagaimana setiap klien menerapkan muatan konfigurasi yang diterimanya, termasuk server DNS internal. Klien yang menerima alamat tetapi merutekan kueri di sekitar tunnel berakhir dengan resolver yang bisa dilihat dan tidak bisa dipakai.

Alamat publik adalah pilihan biasa karena itulah satu-satunya yang sudah diketahui administrator. Alamat itu juga satu-satunya yang dijamin berada di luar prefiks tunnel itu sendiri, dan sifat itulah yang merusak klien Apple.

Lihat nilainya sebelum mengubah apa pun. Jika resolver yang dikirim adalah alamat WAN server, Anda sudah menemukan bentuk masalahnya dan bisa melewati sisa dugaan. Bandingkan juga dengan prefiks pool, karena alamat di dalam pool tetapi di luar rentang sewa persis seperti bentuk perbaikannya. Dua menit dengan konfigurasi lebih baik daripada seharian menangkap paket di klien.

Potong resolver dari rentang sewa

Beri tunnel rencana alamat di mana resolver menjadi anggota subnet pool itu sendiri, lalu reservasikan alamat itu agar tidak pernah disewakan ke klien mana pun. Dalam contoh ini pool adalah 10.180.7.0/24, server memegang 10.180.7.1, dan sewa dimulai pada 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefiks pool dan resolver berbagi subnet, sehingga rute yang sudah membawa lalu lintas tunnel juga membawa kueri. Sifat tunggal itulah yang membuat perbaikan dapat dipindahkan antar klien. Dalam konfigurasi swanctl dua fakta yang sama muncul sebagai definisi pool dan pengaturan DNS pada koneksi, bukan dalam sintaksis ipsec.conf.

Server tidak memerlukan antarmuka fisik baru untuk ini. Menambahkan 10.180.7.1 ke antarmuka loopback sudah cukup bagi resolver untuk mengikat dan menjawab, karena klien mencapainya melalui rute pool yang sudah ada. Jauhkan alamat itu dari rentang sewa agar tidak ada klien yang mengambilnya secara tidak sengaja. Jika pool dikelola oleh layanan DHCP atau RADIUS eksternal, reservasikan alamat di sana juga, atau klien pertama yang bertanya akan mengambilnya.

Ikat resolver dan tutup port 53

Menetapkan alamat tidak sama dengan mendengarkan padanya. Resolver yang hanya mendengarkan di alamat LAN akan menolak atau mengabaikan kueri yang dikirim ke alamat pool, dan klien melihat waktu habis yang tampak seperti kegagalan perutean.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Fragmen unbound itu menerima kueri dari pool tunnel dan menolak semua yang lain, yang merupakan kebijakan yang diinginkan sebagian besar resolver korporat. Jika instans yang sama juga menjawab klien LAN, tambahkan prefiks LAN secara eksplisit alih-alih memperluas pendengar ke semua sumber.

Aturan firewall kemudian harus sesuai dengan kontrol akses resolver itu sendiri. Terima port 53 dari pool, dan buang di tempat lain, tetapi periksa dulu urutan rantainya.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Aturan terima yang lebih awal dan lebih luas membuat dua baris terakhir itu sekadar hiasan, dan resolver tetap dapat dijangkau dari internet. Baca kumpulan aturan yang efektif dengan penghitungnya alih-alih memercayai urutan yang Anda maksudkan. Kebijakan alternatif, mengirim alamat publik dan mengizinkan kueri dari sumber mana pun, berfungsi untuk banyak klien, tetapi menaruh resolver di internet dan membutuhkan pembatasan laju serta pemantauannya sendiri.

Verifikasi apa yang sebenarnya diterima klien

Periksa pandangan server dulu, lalu klien, karena keduanya berbeda secara informatif. Daftar pool menunjukkan alamat mana yang disewakan, dan daftar asosiasi keamanan menunjukkan apakah koneksi menyala dengan identitas yang diharapkan.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Kueri langsung membuktikan resolver menjawab di alamat pool dari host yang dapat mencapainya. Itu tidak membuktikan Mac memilih server tersebut. Di macOS, scutil --dns mencantumkan resolver per layanan terlingkup dan lebih informatif daripada panel ringkasan; di Windows, Get-DnsClientServerAddress menunjukkan apakah adaptor tunnel menerima nilai yang dikirim.

Jika klien menampilkan alamat pool dan kueri masih habis waktu, rute tunnel atau rantai firewall yang bersalah. Klien yang tidak melaporkan resolver apa pun berarti muatan konfigurasi tidak pernah tiba, jadi lihat bagaimana platform itu menerapkan pengaturan yang dikirim, bukan jaringannya. Catat mana dari dua kasus itu yang Anda amati sebelum mengubah hal lain. Kedua kegagalan itu terlihat identik di tiket dukungan dan mengarah ke perbaikan yang berlawanan.