Sakelar pengaman pf macOS untuk OpenVPN: aturan yang menutup

Di macOS, sakelar pengaman hanya sebaik kebijakan filter paket di belakangnya, dan pf adalah bagian yang menegakkan kebijakan itu. Kebijakan harus melakukan dua hal yang berlawanan sekaligus: membiarkan klien mencapai servernya agar terowongan bisa ada, dan menghentikan semua yang lain keluar langsung. Sebagian besar kumpulan aturan yang diterbitkan berhasil pada yang kedua dan lupa yang pertama, sehingga mesin kehilangan konektivitas alih-alih mendapat perlindungan. Versi yang berhasil menyebut titik akhir, resolver, dan terowongan, dan tidak lebih.

Apa yang bisa diputuskan filter paket, dan apa yang tidak

pf melihat antarmuka, alamat, nomor protokol, dan port, lalu berhenti di situ. Ia tidak pernah tahu proses mana yang membuka soket, jadi izin yang ditulis untuk satu program menjadi izin bagi setiap program yang bisa mencapai port yang sama. Begitulah pengecualian UDP yang longgar mengubah sakelar pengaman kembali menjadi jaringan biasa. Pemblokiran sadar-aplikasi milik klien atau ekstensi sistem, bukan berkas ini.

Filter juga tidak membuat rute. Saat klien putus, rute default mungkin masih menunjuk ke terowongan mati, dan pf mengubahnya menjadi paket terblokir alih-alih kembali diam-diam ke Wi-Fi. Blokiran adalah hasil yang dimaksud, bukan kerusakan yang harus diakali.

Urutan lebih sering menentukan hasil daripada teks aturannya. Tanpa quick, pf terus mengevaluasi setelah kecocokan dan aturan terakhir yang cocok menang, jadi lintasan lebar di dekat bawah mengalahkan pengecualian hati-hati di atasnya. Menandai lintasan dengan quick menjadikan kecocokan pertama final, yang biasanya dimaksud penulis kebijakan.

Baca dulu fakta antarmuka dan titik akhir

Antarmuka nirkabel tidak bernomor sama di setiap Mac, dan perangkat terowongan mendapat nomor yang bisa berubah antar boot. Aturan yang menyebut perangkat tidak ada gagal saat parsing, yang berisik dan mudah ditangkap, sedangkan aturan yang menyebut perangkat yang ada tetapi salah parsing dengan bersih dan mengizinkan lalu lintas yang ingin Anda hentikan.

Kumpulkan fakta saat klien terhubung, karena perangkat terowongan hanya ada saat itu. Anda perlu antarmuka yang memegang rute default, perangkat yang dibuat klien, serta alamat dan port server yang dihubunginya. Nilai terakhir itulah yang paling sering dihilangkan kumpulan aturan, dan menghilangkannya sebabnya kumpulan yang disalin memblokir terowongannya sendiri.

route -n get default
ifconfig -l
scutil --nc list

Perintah pertama menyebut antarmuka yang menang saat ini, yang kedua mendaftar setiap perangkat yang dikenal kernel, dan yang ketiga menunjukkan konfigurasi VPN yang bisa dijalankan sistem. Catat jawaban itu, lalu baca alamat dan port server dari konfigurasi klien sendiri.

Tulis kumpulan aturan di sekitar jalur terowongan

Berkas di bawah menolak secara default dan mengizinkan kembali lima hal: loopback, perangkat terowongan, jalur klien ke servernya, resolver yang dipakai sebelum terowongan ada, dan dua pertukaran yang menjaga tautan nirkabel tetap berguna. Nama antarmuka dan alamat server berasal dari mesin Anda, jadi gantilah nilai yang sudah Anda pastikan. Nomor terowongan juga tidak akan cocok dengan milik Anda.

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

Baris DHCP ada karena Mac meminta alamat sebelum memilikinya, jadi permintaan keluar dari port 68 menuju port 67 tanpa alamat sumber yang berguna. Baris multicast memungkinkan sistem menilai apakah tautan nirkabel layak dipakai, dan menghapusnya menghasilkan mesin yang melaporkan tidak ada koneksi di jaringan yang berfungsi. Baris titik akhir adalah yang memungkinkan OpenVPN mencapai servernya sama sekali; tanpanya block all menjatuhkan jabat tangan luar dan terowongan tidak pernah naik. Baris resolver lebih sempit daripada izin DNS umum, karena menyebut satu alamat dan satu port alih-alih setiap kueri yang dilakukan mesin.

Pengecualian titik akhir dan resolver itu adalah dua yang harus ada; semua yang lain tetap terblokir. Jika klien menghubungi alamat literal, hapus baris resolver dan pertahankan baris titik akhir. Jika alamat server berubah, perbarui baris itu sebelum koneksi berikutnya, atau isi tabel pf dari kait klien sendiri dan cocokkan tabel itu sebagai gantinya.

Turunkan terowongan, lalu boot ulang

Parsing sebelum memuat, karena kesalahan sintaks murah dalam uji kering dan mahal dalam sesi jarak jauh. Lalu muat berkasnya, aktifkan filter jika sebelumnya mati, dan baca kembali apa yang benar-benar berlaku. Membaca kembali bukan seremoni: jangkar lain bisa menambah aturan yang tidak Anda tulis, jadi bandingkan kumpulan yang tercetak dengan berkas Anda.

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

Dengan aturan termuat, turunkan terowongan dan coba muat halaman. Lalu lintas biasa harus berhenti, dan harus tetap berhenti setelah mesin tidur dan bangun, karena transisi itulah tempat keadaan basi merayap kembali. Sambungkan ulang dan pastikan lalu lintas pulih tanpa menyentuh kumpulan aturan. Jika peramban masih bekerja dengan terowongan mati, ada aturan yang lebih lebar dari dugaan Anda, dan pembacaan kembali biasanya menyebutnya.

Boot ulang adalah bagian yang orang lewatkan. macOS membaca /etc/pf.conf saat boot, tetapi membaca berkas tidak sama dengan mengaktifkan filter, jadi kumpulan aturan yang berfungsi sekarang bisa nonaktif setelah restart. Jalankan sudo pfctl -s info sesudahnya dan pastikan baris status melaporkan filter aktif.

Jaga jalur keluar dan restart tetap jujur

Kumpulan aturan yang memblokir semuanya juga bisa mengunci Anda dari mesin yang Anda kelola dari jarak jauh. Sunting dari sesi lokal bila bisa, simpan berkas sebelumnya di samping yang baru, dan ketahui cara mengembalikannya sebelum Anda membutuhkannya. Perintah di bawah menonaktifkan filter dan memuat ulang salinan yang Anda simpan, dan itulah urutan untuk dijalankan dari konsol, bukan lewat terowongan yang baru Anda potong. Pengembalian lima detik mengalahkan aturan pintar setiap kali.

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

Ketahanan menuntut daemon peluncur yang menjalankan pfctl -e dan memuat berkas Anda saat boot. Perlakukan seperti pekerjaan berhak istimewa lain: jalur absolut, log yang bisa dibaca kemudian, dan uji pada mesin yang bisa Anda capai secara fisik. Daemon yang gagal diam-diam meninggalkan mesin tanpa perlindungan dan tampak normal.

Dokumentasikan celahnya, mulai dari klien VPN kedua yang membuat perangkat terowongannya sendiri. Aturan Anda menyebut satu antarmuka terowongan, jadi yang kedua tetap terblokir atau tertangkap aturan lebar yang ditambahkan kemudian. Antarmuka tethering dan hotspot hanya muncul kadang-kadang dan layak mendapat catatan yang sama. Tak satu pun celah itu menjadi alasan melewati kebijakan; itulah syarat di mana ia masih berlaku.