UFW membuang server DNS VPN begitu terowongan aktif

Nama berhenti diresolusi tepat saat VPN terhubung, sementara ping ke alamat publik masih menjawab dan status firewall tidak menunjukkan apa pun yang tampak salah. Tidak ada yang berubah dalam kebijakan; yang berubah adalah munculnya antarmuka baru, dan penolakan bawaan menutupinya sejak paket pertama. UFW memutuskan berdasarkan arah dan antarmuka, jadi aturan yang ditulis untuk tautan nirkabel tidak mengatakan apa pun tentang lalu lintas yang keluar dari terowongan. Perbaikannya adalah segenggam aturan sempit yang diterapkan dalam urutan tertentu.

Gejalanya baru muncul setelah terowongan aktif

Kebijakan penolakan bawaan melakukan persis apa yang diperintahkan: apa pun tanpa aturan yang cocok ditolak, di setiap antarmuka yang ada. Terowongan belum ada saat aturan ditulis, jadi tidak satu pun dari aturan itu dapat mencocokkannya, dan penolakan yang selalu ada kini berlaku untuk resolusi nama. Lalu lintas langsung ke alamat literal masih bisa berfungsi bila izin yang lebih luas mencakupnya, dan itulah sebabnya ping ke resolver publik berhasil sementara pencarian nama gagal. Celahnya adalah aturan untuk antarmuka yang belum pernah dilihat kebijakan.

Itu juga menjelaskan mengapa kegagalan berbalik dengan bersih: turunkan terowongan dan nama teresolusi lagi, karena kueri kembali ke antarmuka yang memiliki aturan. Kebijakan yang hanya gagal saat terowongan aktif bukan masalah DNS, dan menyetel resolver itu sendiri paling banyak membuang waktu di sini. Baca daftar antarmuka sebelum membaca konfigurasi resolver.

Tiga arah, tiga kumpulan aturan berbeda

Satu sesi menyentuh aturan di lebih dari satu arah, dan terowongan menambahkan antarmuka kedua ke hampir semuanya. Mengurutkan lalu lintas berdasarkan arah dan antarmuka lebih dulu membuat sisanya mekanis, karena setiap baris di bawah membutuhkan aturannya sendiri di tempatnya sendiri. Contohnya memakai tun0 dan kumpulan 10.8.0.0/24, jadi ganti nama dan rentang dengan yang ada di keluaran klien sendiri.

Dua baris sering tertukar karena keduanya menyebut terowongan. Aturan untuk resolver mengizinkan lalu lintas yang dikirim klien ke terowongan, sedangkan aturan untuk SSH mengizinkan lalu lintas yang diterima server darinya; keduanya hidup di mesin berbeda dan gagal secara mandiri. Baris yang paling sering terlupa adalah yang kedua, karena klien sama sekali tidak dapat membangun terowongan sampai lalu lintasnya ke alamat publik server diizinkan. Bekerjalah dari atas ke bawah dan setiap kegagalan punya satu kemungkinan penyebab.

Resolver yang didorong butuh aturannya sendiri

Apakah terowongan membawa DNS bergantung pada apa yang dikirim server. Server yang mendorong opsi resolver memasang alamat privat di konfigurasi klien, dan alamat itu hanya bisa dirutekan melalui terowongan. Jika server tidak mendorong apa pun, klien mempertahankan resolver yang sudah dimilikinya dan aturan di bawah tidak punya apa pun untuk diizinkan. Periksa status yang didorong dan hasil kueri saat ini sebelum menulis apa pun:

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

Keluaran status menyebut resolver yang dipakai dan tautan tempat ia terikat, dan pencarian rute di baliknya menunjukkan antarmuka mana yang akan membawa kueri ke alamat itu. Ketika resolver berada di tautan lain, masalahnya lebih awal daripada firewall dan tidak ada aturan yang akan membantu. Ketika keduanya sepakat soal terowongan, dibutuhkan dua aturan, karena UDP membawa sebagian besar kueri dan TCP mengambil alih saat jawaban terpotong. Catat kedua nilai, karena itulah yang akan disebut aturan:

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 jalur luar sebelum jalur dalam

Klien harus mencapai alamat publik server sebelum terowongan ada, jadi aturannya duduk di tautan fisik dan harus ada lebih dulu. Kebijakan yang mengizinkan resolver tetapi melupakan server membuat klien sama sekali tidak bisa membangun terowongan, dan gejala itu biasanya dituduhkan ke kill switch. Lalu izinkan layanan yang benar-benar Anda inginkan melalui terowongan, satu aturan sempit setiap kali, alih-alih membuka antarmuka sepenuhnya. Aturan sempit itulah alasan penolakan bisa tetap 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'

Urutan penting saat menguji, karena aturan pertama itulah yang membuat terowongan bisa naik sama sekali. Tambahkan, sambungkan, dan pastikan terowongan aktif sebelum menambahkan aturan layanan, karena melakukan keduanya sekaligus berarti kegagalan tidak memberi tahu Anda separuh mana yang salah. Ganti alamat dokumentasi di atas dengan titik akhir yang dikonfigurasi untuk klien.

Selesaikan sisi klien dengan memutuskan sambungan secara sengaja. Penolakan seharusnya tetap menolak lalu lintas yang sengaja Anda kecualikan, karena resolver yang menjawab saat terowongan aktif hanya menutupi separuh kebijakan yang menolak saat ragu.

Klien yang terhubung belum tentu diterima

Server punya arahnya sendiri untuk dipertimbangkan, dan klien yang menyelesaikan jabat tangan tetap tidak dapat mencapai apa pun yang berjalan di server sampai server menerimanya. Aturan pendengar publik hanya membuat terowongan bisa eksis; aturan itu tidak memasukkan lalu lintas terowongan. Di server itu dua aturan plus satu pemeriksaan bahwa layanan benar-benar mendengarkan:

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'

Kumpulan dalam aturan harus sama dengan rentang yang dialokasikan server, dan nomor terowongan harus cocok dengan yang dibuat server, karena aturan untuk antarmuka lain tidak bisa dibedakan dari tidak ada aturan. limit sengaja dipakai untuk port administratif, karena membatasi koneksi berulang alih-alih menerimanya tanpa batas. Pemeriksaan pendengar memisahkan port tertutup dari paket yang dibuang, yang tampak identik dari sisi klien. Aturan bernomor juga bukan gambaran utuh: aturan before UFW dan baris nftables yang ditulis tangan cocok lebih dulu dan masih bisa menolak paket yang tampaknya diizinkan daftar.