UFW menggugurkan pelayan DNS VPN sebaik terowong naik

Nama berhenti diselesaikan pada saat VPN menyambung, manakala ping ke alamat awam masih menjawab dan status firewall tidak menunjukkan apa-apa yang kelihatan salah. Tiada apa yang berubah dalam dasar; yang berubah ialah antara muka baharu muncul, dan penafian lalai meliputinya dari paket pertama. UFW memutuskan mengikut arah dan antara muka, jadi peraturan yang ditulis untuk pautan wayarles tidak berkata apa-apa tentang trafik yang keluar dari terowong. Pembaikan ialah segenggam peraturan sempit yang digunakan dalam susunan tertentu.

Gejala hanya muncul selepas terowong naik

Dasar penafian lalai melakukan tepat apa yang diperintahkan: apa-apa tanpa peraturan yang sepadan ditolak, pada setiap antara muka yang wujud. Terowong tidak wujud semasa peraturan ditulis, jadi tiada satu pun daripadanya boleh menangkapnya, dan penafian yang sentiasa ada kini terpakai kepada penyelesaian nama. Trafik langsung ke alamat literal masih boleh berfungsi apabila kebenaran yang lebih luas meliputinya, dan itulah sebabnya ping ke penyelesai awam berjaya manakala carian nama gagal. Jurangnya ialah peraturan untuk antara muka yang tidak pernah dilihat oleh dasar itu.

Itu juga menjelaskan mengapa kegagalan berbalik dengan bersih: turunkan terowong dan nama diselesaikan semula, kerana pertanyaan kembali ke antara muka yang mempunyai peraturan. Dasar yang gagal hanya semasa terowong naik bukan masalah DNS, dan menala penyelesai itu sendiri paling banyak membuang masa di sini. Baca senarai antara muka sebelum membaca konfigurasi penyelesai.

Tiga arah, tiga set peraturan berbeza

Satu sesi menyentuh peraturan dalam lebih daripada satu arah, dan terowong menambah antara muka kedua pada hampir kesemuanya. Mengisih trafik mengikut arah dan antara muka dahulu menjadikan selebihnya mekanikal, kerana setiap baris di bawah memerlukan peraturannya sendiri di tempatnya sendiri. Contoh menggunakan tun0 dan kolam 10.8.0.0/24, jadi gantikan nama dan julat dengan yang daripada output klien sendiri.

Dua baris sering dikelirukan kerana kedua-duanya menyebut terowong. Peraturan untuk penyelesai membenarkan trafik yang dihantar klien ke dalam terowong, manakala peraturan untuk SSH membenarkan trafik yang diterima pelayan daripadanya; kedua-duanya hidup pada mesin berbeza dan gagal secara bebas. Baris yang paling kerap dilupakan ialah yang kedua, kerana klien tidak boleh membina terowong sama sekali sehingga trafiknya ke alamat awam pelayan dibenarkan. Bekerja dari atas ke bawah dan setiap kegagalan mempunyai satu punca yang mungkin.

Penyelesai yang ditolak memerlukan peraturannya sendiri

Sama ada terowong membawa DNS bergantung pada apa yang dihantar oleh pelayan. Pelayan yang menolak pilihan penyelesai memasang alamat peribadi dalam konfigurasi klien, dan alamat itu hanya boleh dihalakan melalui terowong. Jika pelayan tidak menolak apa-apa, klien mengekalkan penyelesai yang sedia ada dan peraturan di bawah tidak mempunyai apa-apa untuk dibenarkan. Semak keadaan yang ditolak dan hasil pertanyaan semasa sebelum menulis apa-apa:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Output status menamakan penyelesai yang digunakan dan pautan yang terikat dengannya, dan carian laluan di belakangnya menunjukkan antara muka mana yang akan membawa pertanyaan ke alamat itu. Apabila penyelesai berada pada pautan lain, masalahnya lebih awal daripada firewall dan tiada peraturan akan membantu. Apabila kedua-duanya bersetuju tentang terowong, dua peraturan diperlukan, kerana UDP membawa kebanyakan pertanyaan dan TCP mengambil alih apabila jawapan dipotong. Catat kedua-dua nilai, kerana itulah yang akan dinamakan oleh peraturan:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Buka laluan luar sebelum laluan dalam

Klien mesti mencapai alamat awam pelayan sebelum terowong wujud, jadi peraturan untuknya terletak pada pautan fizikal dan mesti berada di tempatnya dahulu. Dasar yang membenarkan penyelesai tetapi melupakan pelayan meninggalkan klien sama sekali tidak mampu membina terowong, dan gejala itu biasanya dilemparkan kepada kill switch. Kemudian benarkan perkhidmatan yang benar-benar anda mahu melalui terowong, satu peraturan sempit pada satu masa, bukannya membuka antara muka sepenuhnya. Peraturan sempit itulah sebabnya penafian boleh kekal di tempatnya.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Susunan penting semasa menguji, kerana peraturan pertama itulah yang membolehkan terowong naik sama sekali. Tambahkan, sambung, dan pastikan terowong naik sebelum menambah peraturan perkhidmatan, kerana melakukan kedua-duanya sekali gus bermakna kegagalan tidak memberitahu anda separuh mana yang salah. Gantikan alamat dokumentasi di atas dengan titik akhir yang dikonfigurasikan untuk klien.

Selesaikan bahagian klien dengan memutuskan sambungan secara sengaja. Penafian sepatutnya masih menolak trafik yang anda sengaja kecualikan, kerana penyelesai yang menjawab semasa terowong naik hanya meliputi separuh daripada dasar yang menafikan apabila ragu.

Klien yang menyambung belum diterima

Pelayan mempunyai arahnya sendiri untuk dipertimbangkan, dan klien yang menyelesaikan jabat tangan masih tidak dapat mencapai apa-apa yang berjalan pada pelayan sehingga pelayan menerimanya. Peraturan pendengar awam hanya membenarkan terowong wujud; ia tidak membenarkan trafik terowong masuk. Pada pelayan itu dua peraturan tambah satu pemeriksaan bahawa perkhidmatan benar-benar mendengar:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Kolam dalam peraturan mesti sama dengan julat yang diperuntukkan oleh pelayan, dan nombor terowong mesti sepadan dengan yang dicipta oleh pelayan, kerana peraturan untuk antara muka lain tidak dapat dibezakan daripada tiada peraturan. limit adalah sengaja untuk port pentadbiran, kerana ia mengehadkan sambungan berulang bukannya menerimanya tanpa had. Pemeriksaan pendengar memisahkan port tertutup daripada paket yang digugurkan, yang kelihatan sama dari sisi klien. Peraturan bernombor juga bukan gambaran keseluruhan: peraturan before UFW dan mana-mana baris nftables yang ditulis tangan sepadan lebih awal dan masih boleh menolak paket yang kelihatan dibenarkan oleh senarai.