Betulkan DNS tetamu libvirt yang disekat oleh firewall VPN berasaskan tanda

Tetamu pada rangkaian libvirt lalai menyelesaikan nama dengan sempurna sehingga antara muka WireGuard naik, dan kemudian setiap carian tersekat di tempat yang sama. dnsmasq masih mendengar pada 192.168.122.1:53, tetamu masih mempunyai alamat itu sebagai penyelesainya, dan pertanyaan itu masih tiba. Yang berubah ialah pertanyaan huluan hos itu sendiri, atau balasan kepadanya, kini digugurkan oleh peraturan yang dinilai sebelum mana-mana rantaian penapis yang anda sangka perlu diubah. Jalan keluarnya ialah tanda yang dikenakan cukup awal, pada sambungan yang diwarisi oleh balasan.

Tetamu kehilangan DNS sebaik terowong naik

Sahkan bentuknya sebelum mengubah apa-apa. Turunkan terowong, jalankan dig @192.168.122.1 example.com dari tetamu, dan lihat ia menjawab. Naikkan terowong, ulangi, dan lihat ia tamat masa. Pasangan keputusan itu menyingkirkan rangkaian libvirt yang rosak, alamat penyelesai yang salah, dan dnsmasq yang mati dalam satu langkah.

Kemudian lihat bahagian hos. Jika dnsmasq mencatat pertanyaan dan penghantaran huluannya, paket itu tiba dan kegagalan berada pada egress. Jika dnsmasq tidak mencatat apa-apa, pertanyaan tetamu digugurkan pada ingress dan pengecualian itu sepatutnya berada pada cangkuk yang berbeza daripada yang ditanda oleh artikel ini.

Mengapa peraturan accept dalam rantaian kemudian tidak pernah tercetus

Firewall VPN berasaskan tanda membuat keputusan dengan melihat tanda paket atau tanda sambungan, bukan alamat sumber anda. Apa-apa yang tiba pada antara muka fizikal tanpa tanda yang dijangka akan ditolak, dan penolakan itu berlaku dalam set peraturan yang memiliki ujian tanda. ip saddr 192.168.122.0/24 accept baris yang ditambah pada mana-mana rantaian kemudian tidak pernah dirujuk untuk paket itu, sebab itulah peraturan yang jelas kelihatan betul tetapi tidak mengubah apa-apa.

Melebarkannya sehingga sesuatu berfungsi ialah perangkap kedua. Menerima seluruh subnet libvirt dalam laluan input hos membuka setiap perkhidmatan hos kepada tetamu, sedangkan keperluan sebenar hanyalah satu port.

Mekanisme yang membolehkan pengecualian sempit ialah penjejakan sambungan. Apabila anda menetapkan ct mark pada paket, nilainya disimpan pada entri conntrack dan bukan pada paket semata-mata, jadi setiap paket dalam sambungan itu membawanya selepas itu, termasuk balasan dari hos kembali kepada tetamu. Itulah muslihat keseluruhannya: tandakan permintaan sekali, dan laluan pulang sudah ditanda.

Tandakan pertanyaan sebelum jadual VPN melihatnya

Letakkan pengecualian dalam jadualnya sendiri supaya pembaca kemudian dapat menemuinya tanpa menghurai peraturan 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 adalah negatif, yang meletakkan rantaian ini di hadapan rantaian penapis biasa yang dipasang pakej VPN pada keutamaan sifar. Urutan cangkuk itulah yang menjadikan peraturan berkesan; peraturan yang sama dalam rantaian yang tersusun selepas rantaian VPN hanyalah hiasan.

Nombor tanda itu sendiri tidak mudah alih. Ambil nilai yang diterima peraturan VPN yang dipasang untuk trafiknya sendiri, bacanya daripada set peraturan langsung, dan gunakan nilai itu. Tanda yang salah menghasilkan peraturan yang dimuatkan dengan bersih, sepadan dengan setiap pertanyaan, dan tidak menerima apa-apa.

Kekalkan lubang itu selebar port 53

Seperti yang ditulis, ini membenarkan DNS dari subnet libvirt ke hos melalui TCP atau UDP port 53 dan tidak lain. Ia tidak membenarkan tetamu mencapai internet di luar terowong, dan ia tidak membenarkan hos membuka sambungan ke arah tetamu. Jika tetamu memerlukan perkhidmatan hos lain kemudian, tambah peraturan berasingan yang menamakan port destinasi itu dan bukan melonggarkan peraturan ini.

Bersikap jujur tentang apa yang anda tukar. Tetamu yang boleh mencapai penyelesai juga boleh menyalurkan data sewenang-wenangnya melalui pertanyaan DNS, dan pengecualian ini ialah jurang yang disengajakan dalam sempadan VPN dan bukan pernyataan bahawa rangkaian tempatan dipercayai. Menghadkan sumber kepada 192.168.122.0/24 menjauhkan jurang itu daripada setiap subnet tempatan yang lain, dan mengira pertanyaan terhadap sumber itu murah jika ancaman itu penting bagi anda.

Pastikan ia bertahan selepas but semula dan buktikan kedua-dua bahagian

Peraturan yang ditaip pada gesaan shell hilang pada but seterusnya, dan peraturan yang dimuatkan selepas antara muka VPN sudah melepasi trafik kalah perlumbaan pada sambungan pertama. Letakkan jadual itu dalam konfigurasi nftables berterusan hos, atau dalam unit yang tersusun sebelum perkhidmatan VPN, dan periksa urutannya dan bukan menganggapnya.

Pengesahan memerlukan tiga jawapan berasingan. Sahkan rantaian dimuatkan dan tersusun dahulu, sahkan entri conntrack menunjukkan tanda dalam kedua-dua arah, dan sahkan carian tetamu memulangkan alamat. Kemudian sahkan separuh lagi: trafik web tetamu biasa ke hos awam masih gagal semasa terowong turun atau menyekat. Jika DNS berfungsi dan segala-galanya bocor, peraturan anda lebih luas daripada yang di atas.

Jika carian masih gagal selepas tanda itu dipasang, tahan keinginan untuk melebarkan sumber. Periksa ke mana dnsmasq menghantar, sama ada penyelesai tetamu menunjuk ke 192.168.122.1 atau ke alamat awam yang seseorang taip, dan sama ada pertanyaan itu sampai ke hos langsung. Penandaan menerima paket itu dan tidak lain, jadi huluan yang buruk atau rangkaian maya yang rosak kekal rosak tidak kira berapa banyak peraturan yang anda tambah.