Memperbaiki DNS tamu libvirt yang diblokir firewall VPN berbasis tanda

Tamu di jaringan libvirt bawaan menyelesaikan nama dengan sempurna sampai antarmuka WireGuard naik, lalu setiap pencarian macet di tempat yang sama. dnsmasq masih mendengarkan di 192.168.122.1:53, tamu masih memakai alamat itu sebagai resolver, dan kueri masih datang. Yang berubah adalah kueri upstream milik host sendiri, atau balasannya, kini dibuang oleh aturan yang dievaluasi sebelum rantai filter mana pun yang mungkin ingin Anda edit. Jalan keluarnya adalah tanda yang diterapkan cukup awal, pada koneksi yang diwarisi balasannya.

Tamu kehilangan DNS begitu tunnel naik

Pastikan bentuknya sebelum mengubah apa pun. Turunkan tunnel, jalankan dig @192.168.122.1 example.com dari tamu, dan lihat ia menjawab. Naikkan tunnel, ulangi, dan lihat ia kehabisan waktu. Sepasang hasil itu menyingkirkan jaringan libvirt yang rusak, alamat resolver yang salah, dan dnsmasq yang mati dalam satu langkah.

Lalu lihat sisi host. Jika dnsmasq mencatat kueri dan penerusan upstream-nya, paket tiba dan kegagalan ada di egress. Jika dnsmasq tidak mencatat apa pun, kueri tamu dibuang di ingress dan pengecualiannya milik hook lain daripada yang ditandai artikel ini.

Mengapa aturan accept di rantai berikutnya tidak pernah menyala

Firewall VPN berbasis tanda memutuskan dengan melihat tanda paket atau tanda koneksi, bukan alamat sumber Anda. Apa pun yang tiba di antarmuka fisik tanpa tanda yang diharapkan akan ditolak, dan penolakan itu terjadi di kumpulan aturan yang memiliki uji tanda. Baris ip saddr 192.168.122.0/24 accept yang ditambahkan ke rantai berikutnya tidak pernah dikonsultasikan untuk paket itu, itulah sebabnya aturan yang tampak jelas terlihat benar dan tidak mengubah apa pun.

Memperlebarnya sampai ada yang berfungsi adalah jebakan kedua. Menerima seluruh subnet libvirt di jalur masukan host membuka setiap layanan host bagi tamu, padahal kebutuhan sebenarnya hanya satu port.

Mekanisme yang memungkinkan pengecualian sempit adalah pelacakan koneksi. Saat Anda menyetel ct mark pada paket, nilainya disimpan di entri conntrack, bukan hanya pada paket, sehingga setiap paket dalam koneksi itu membawanya setelahnya, termasuk balasan dari host kembali ke tamu. Itulah seluruh triknya: tandai permintaan sekali, dan jalur kembali sudah ditandai.

Tandai kueri sebelum tabel VPN melihatnya

Taruh pengecualian di tabelnya sendiri agar pembaca berikutnya dapat menemukannya tanpa mengurai aturan VPN:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle bersifat negatif, yang menempatkan rantai ini di depan rantai filter biasa yang dipasang paket VPN pada prioritas nol. Urutan hook lah yang membuat aturan efektif; aturan yang sama di rantai yang diurutkan setelah rantai VPN hanyalah hiasan.

Nomor tanda itu sendiri tidak portabel. Ambil nilai yang diterima aturan VPN terpasang untuk lalu lintasnya sendiri, baca dari kumpulan aturan hidup, dan gunakan itu. Tanda yang salah menghasilkan aturan yang termuat bersih, cocok dengan setiap kueri, dan tidak mengizinkan apa pun.

Jaga lubang selebar port 53

Sebagaimana tertulis, ini mengizinkan DNS dari subnet libvirt ke host melalui TCP atau UDP port 53 dan tidak lebih. Ini tidak membiarkan tamu menjangkau internet di luar tunnel, dan tidak membiarkan host membuka koneksi ke tamu. Jika tamu membutuhkan layanan host lain nanti, tambahkan aturan terpisah yang menyebut port tujuan itu alih-alih melonggarkan yang ini.

Bersikap jujur tentang apa yang Anda tukarkan. Tamu yang dapat menjangkau resolver juga dapat menerowong data sembarang melalui kueri DNS, dan pengecualian ini adalah celah yang disengaja di batas VPN, bukan pernyataan bahwa jaringan lokal tepercaya. Membatasi sumber ke 192.168.122.0/24 menjauhkan celah itu dari setiap subnet lokal lain, dan menghitung kueri terhadap sumber itu murah jika ancaman itu penting bagi Anda.

Buat agar bertahan setelah reboot dan buktikan kedua belah pihak

Aturan yang diketik di prompt shell hilang pada boot berikutnya, dan aturan yang dimuat setelah antarmuka VPN sudah melewatkan lalu lintas akan kalah balapan pada koneksi pertama. Taruh tabel di konfigurasi nftables persisten host, atau di unit yang diurutkan sebelum layanan VPN, dan periksa urutannya alih-alih menganggapnya.

Verifikasi membutuhkan tiga jawaban terpisah. Pastikan rantai termuat dan diurutkan pertama, pastikan entri conntrack menunjukkan tanda di kedua arah, dan pastikan pencarian tamu mengembalikan alamat. Lalu pastikan separuh lainnya: lalu lintas web biasa tamu ke host publik tetap gagal saat tunnel turun atau memblokir. Jika DNS berfungsi dan semua yang lain bocor, aturan Anda lebih luas daripada yang di atas.

Jika pencarian masih gagal setelah tanda terpasang, tahan dorongan untuk memperlebar sumber. Periksa ke mana dnsmasq meneruskan, apakah resolver tamu menunjuk ke 192.168.122.1 atau ke alamat publik yang diketik seseorang, dan apakah kueri benar-benar sampai ke host. Penandaan mengizinkan paket dan tidak lebih, jadi upstream buruk atau jaringan virtual yang rusak tetap rusak berapa pun aturan yang Anda tambahkan.