Saya sudah bisa menolak semua koneksi ke jaringan eksternal kecuali koneksi OpenVPN saya aktif menggunakan pf.conf. Namun, saya kehilangan konektivitas Wi-Fi jika koneksi terputus dengan menutup dan membuka tutup laptop atau mematikan dan menghidupkan Wi-Fi lagi.
- Saya menggunakan Mac OS 10.8.1.
- Saya terhubung ke Web melalui Wi-Fi (dari berbagai lokasi, termasuk Wi-Fi publik).
- Koneksi OpenVPN diatur dengan Viscosity.
Saya memiliki aturan packet filter berikut yang diatur dalam /etc/pf.conf
# Deny all packets unless they pass through the OpenVPN connection
wifi=en1
vpn=tun0
block all
set skip on lo
pass on $wifi proto udp to [OpenVPN server IP address] port 443
pass on $vpn
Saya memulai layanan filter paket dengan sudo pfctl -e
dan memuat aturan baru dengan sudo pfctl -f /etc/pf.conf
.
Saya juga telah mengedit /System/Library/LaunchDaemons/com.apple.pfctl.plist
dan mengubah baris <string>-f</string>
untuk dibaca <string>-ef</string>
sehingga filter paket diluncurkan saat startup sistem.
Ini semua tampaknya bekerja dengan baik pada awalnya: aplikasi hanya dapat terhubung ke web jika koneksi OpenVPN aktif, jadi saya tidak pernah membocorkan data melalui koneksi yang tidak aman.
Tetapi, jika saya menutup dan membuka kembali tutup laptop saya atau mematikan Wi-Fi dan menghidupkan lagi, koneksi Wi-Fi hilang, dan saya melihat tanda seru pada ikon Wi-Fi di bilah status. Mengklik ikon Wi-Fi menunjukkan pesan "Peringatan: Tidak Ada Koneksi Internet":
Untuk mendapatkan kembali koneksi, saya harus memutuskan dan menghubungkan kembali Wi-Fi, kadang-kadang lima atau enam kali, sebelum pesan "Peringatan: Tidak ada koneksi Internet" menghilang dan saya dapat membuka koneksi VPN lagi. Di waktu lain, peringatan Wi-Fi menghilang dengan sendirinya, tanda seru hilang, dan saya dapat terhubung lagi. Apa pun itu, perlu waktu lima menit atau lebih untuk mendapatkan koneksi lagi, yang bisa membuat frustasi.
Menghapus garis block all
menyelesaikan masalah (tetapi memungkinkan koneksi tidak aman), jadi sepertinya ada layanan yang saya blokir yang Apple perlukan untuk mendapatkan kembali dan mengkonfirmasi koneksi Wi-Fi. Saya telah mencoba:
- Mengaktifkan icmp dengan menambahkan
pass on $wifi proto icmp all
ke pf.conf - Mengaktifkan resolusi DNS dengan menambahkan
pass on $wifi proto udp from $wifi to any port 53
- Mencoba mempelajari lebih lanjut dengan mencatat paket yang diblokir (dengan mengubah
block all
keblock log all
), tetapi logging tampaknya dinonaktifkan di OS X, karena melakukansudo tcpdump -n -e -ttt -i pflog0
melihat hasil log di "tcpdump: pflog0: Tidak ada perangkat seperti itu ada".
Tak satu pun dari ini membantu membangun kembali koneksi Wi-Fi lebih cepat.
Apa lagi yang bisa saya lakukan untuk menentukan layanan apa yang perlu tersedia untuk mendapatkan kembali konektivitas Wi-Fi, atau aturan apa yang harus saya tambahkan ke pf.conf untuk membuat koneksi ulang Wi-Fi lebih dapat diandalkan?
Jawaban:
Dengan memantau koneksi jaringan menggunakan Little Snitch, saya telah menemukan bahwa Apple menggunakan aplikasi mDNSResponder di latar belakang untuk memeriksa apakah koneksi Wi-Fi tersedia. mDNSResponder mengirimkan paket UDP ke server nama untuk memeriksa konektivitas dan menyelesaikan nama host ke IP.
Mengubah aturan UDP yang sebelumnya saya izinkan untuk mengizinkan semua paket UDP melalui Wi-Fi memungkinkan mDNSResponder untuk terhubung, yang berarti Wi-Fi sekarang menghubungkan kembali pertama kali setelah pemutusan. Jika itu membantu orang lain di masa depan, pf.conf terakhir saya termasuk aturan default Apple untuk Mountain Lion terlihat seperti ini:
Ini berarti bahwa data sekarang dapat dibocorkan melalui Wi-Fi oleh sejumlah kecil aplikasi yang menggunakan protokol UDP, sayangnya, seperti ntpd (untuk sinkronisasi waktu) dan mDNSResponder. Tetapi ini tampaknya masih lebih baik daripada memungkinkan data untuk bepergian tanpa perlindungan melalui TCP, yang merupakan apa yang sebagian besar aplikasi gunakan. Jika ada yang punya saran untuk ditingkatkan pada pengaturan ini, komentar atau jawaban lebih lanjut dipersilakan.
sumber
Anda tidak perlu mengizinkan semua UDP. 'M' dalam mDNS berarti 'multicast', dan menggunakan alamat IP tujuan multicast tertentu yang disebut "tautan alamat multicast lokal", dan
UDP
nomor port5353
.Ini berarti dalam solusi Anda di atas, Anda tidak perlu membolehkan lalu lintas ke semua 65535 port UDP ke semua 3,7 Miliar alamat IP yang dapat dirutekan di dunia untuk memotong VPN Anda. Anda akan terkejut betapa banyak aplikasi menggunakan UDP, sehingga Anda secara signifikan mengalahkan tujuan ide asli Anda untuk mencegah lalu lintas keluar ketika VPN turun.
Mengapa tidak menggunakan aturan ini sebagai gantinya:
pass on $wifi proto udp to 224.0.0.251 port 5353
Aturan praktis yang sangat penting dengan konfigurasi firewall - saat membuat pengecualian melalui firewall Anda, selalu coba gunakan aturan yang paling spesifik. Kekhususan kadang-kadang datang dengan mengorbankan kenyamanan & kemudahan penggunaan, yaitu Anda mungkin kemudian menemukan ada beberapa protokol tautan-lokal lain yang perlu dilewati, dan menambahkan aturan khusus lainnya.
Jika Anda bertukar dalam aturan di atas dan menemukan bahwa masalah wifi asli kembali, maka PF Anda mungkin memblokir DHCP, protokol yang digunakan untuk mengonfigurasi otomatis alamat IP perangkat jaringan Anda. (dalam jaringan rumah, biasanya router broadband Anda akan menjadi server DHCP Anda). Aturan yang Anda perlukan untuk mengizinkan DHCP adalah:
pass on $wifi proto udp from 0.0.0.0 port 68 to 255.255.255.255 port 67
* Catatan: Anda mungkin perlu untuk menggantikan
0.0.0.0
untukany
. TheDHCPREQUEST
paket komputer pertama mengirimkan, memiliki alamat sumber0.0.0.0
karena pada tahap itu, komputer Anda tidak memiliki alamat IP belum.Sejujurnya, saya akan lebih condong ke arah menggunakan
any
. Opsi lain adalah menghapus spesifikasi sumber apa pun, yaitupass on $wifi proto udp to 255.255.255.255 port 67
, tetapi itu berarti kita kehilangan bagian port-sumber dari aturan, dan menjadi sespesifik mungkin selalu merupakan opsi yang paling aman.Semoga itu bisa membantu. Berikut ini beberapa tautan bermanfaat:
mDNS: http://en.wikipedia.org/wiki/Multicast_DNS#Packet_structure
DHSP: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery
sumber
Ini memberi saya informasi latar belakang yang cukup untuk membuat lompatan besar dan menggunakan pf.conf. Inilah yang saya gunakan pada 10.8 untuk membuatnya terhubung kembali setelah koneksi VPN turun:
(Saya hanya menggunakan ethernet tetapi Anda dapat mengubah $ lan untuk $ wifi dan seharusnya berfungsi)
sumber
Dengan tujuan untuk membuat aturan PF dengan cara "mudah", mengidentifikasi antarmuka aktif yang ada termasuk antarmuka saat ini (vpn), program killswitch kecil ini dapat digunakan,
Masih dalam proses tetapi bisa menjadi awal yang baik untuk mengidentifikasi IP eksternal, dan antarmuka yang aktif untuk membuat aturan firewall dengan benar.
contoh atau keluaran menggunakan opsi
-i
(info):Melewati ip server
-ip
:Jauh dari sempurna tetapi pekerjaan sedang berlangsung info lebih lanjut / kode dapat ditemukan di sini: https://github.com/vpn-kill-switch/killswitch
sumber
- Sebagai tambahan -
Anda mungkin ingin menambahkan baris ini:
untuk memungkinkan mDNS beroperasi pada ipv6
sumber