Cegah lalu lintas keluar kecuali koneksi OpenVPN aktif menggunakan pf.conf pada Mac OS X


19

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 -edan memuat aturan baru dengan sudo pfctl -f /etc/pf.conf.

Saya juga telah mengedit /System/Library/LaunchDaemons/com.apple.pfctl.plistdan 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":

Tidak ada pesan 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 allmenyelesaikan 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 allke 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 allke block log all), tetapi logging tampaknya dinonaktifkan di OS X, karena melakukan sudo tcpdump -n -e -ttt -i pflog0melihat 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?


1
ini mungkin relevan bagi mereka yang datang setelah: sparklabs.com/support/preventing_network_and_dns_traffic_leaks
ptim

Jawaban:


14

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:

#
# com.apple anchor point
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"as
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

#
# Allow connection via Viscosity only
#
wifi=en1 #change this to en0 on MacBook Airs and other Macs without ethernet ports
vpn=tun0
vpn2=tap0

block all

set skip on lo          # allow local traffic

pass on p2p0            #allow AirDrop
pass on p2p1            #allow AirDrop
pass on p2p2            #allow AirDrop
pass quick proto tcp to any port 631    #allow AirPrint

pass on $wifi proto udp # allow only UDP packets over unprotected Wi-Fi
pass on $vpn            # allow everything else through the VPN (tun interface)
pass on $vpn2           # allow everything else through the VPN (tap interface)

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.


Ini adalah sesuatu yang saya tertarik dengan santai, melihat hasil Anda telah mengilhami saya untuk pulang dan mencobanya! Terima kasih!
jakev

@SixSlayer Tampaknya bekerja dengan cukup baik! Saya memiliki Viscosity yang diatur untuk autoconnect saat startup dan koneksi yang terjatuh, yang membuat semuanya menjadi sangat lancar. Hal utama yang perlu diperhatikan adalah pf.conf dan com.apple.pfctl.plist bisa diatur ulang ke default setelah pembaruan OS, tampaknya, jadi ada baiknya menyimpan cadangan keduanya.
Nick

IMHO, hal UDP agak mengecewakan. Saya bukan orang jaringan tetapi ini agak membantu saya belajar, dan saya memiliki ketertarikan dengan memiliki kontrol atas detail semacam ini. Saya akan meluangkan waktu mencari pekerjaan di sekitar, tetapi jika ada yang mengalahkan saya untuk itu, sama saja.
jakev

ini luar biasa - persis apa yang saya cari. Terima kasih!
keo

Pernahkah Anda berhasil membuat banyak koneksi OpenVPN terbuka pada saat yang sama, dan merutekannya secara paralel? (untuk menambah dan menambah bandwidth)
keo

11

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 UDPnomor port 5353.

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.0untuk any. The DHCPREQUESTpaket komputer pertama mengirimkan, memiliki alamat sumber 0.0.0.0karena 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, yaitu pass 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


1

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)

lan=en0
wifi=en1
vpn=tun0
block all
set skip on lo
pass on $lan proto { udp,tcp } to 8.8.8.8
pass on $lan proto tcp to vpn.btguard.com port 1194
pass on $vpn

1

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):

$ killswitch -i
Interface  MAC address         IP
en1        bc:57:36:d1:82:ba   192.168.1.7
ppp0                           10.10.1.3

public IP address: 93.117.82.123

Melewati ip server -ip:

# --------------------------------------------------------------
# Sat, 19 Nov 2016 12:37:24 +0100
# sudo pfctl -Fa -f ~/.killswitch.pf.conf -e
# --------------------------------------------------------------
int_en1 = "en1"
vpn_ppp0 = "ppp0"
vpn_ip = "93.117.82.123"
set block-policy drop
set ruleset-optimization basic
set skip on lo0
block all
pass on $int_en1 proto udp to 224.0.0.251 port 5353
pass on $int_en1 proto udp from any port 67 to any port 68
pass on $int_en1 inet proto icmp all icmp-type 8 code 0
pass on $int_en1 proto {tcp, udp} from any to $vpn_ip
pass on $vpn_ppp0 all

Jauh dari sempurna tetapi pekerjaan sedang berlangsung info lebih lanjut / kode dapat ditemukan di sini: https://github.com/vpn-kill-switch/killswitch


0

- Sebagai tambahan -

Anda mungkin ingin menambahkan baris ini:

pass on $wifi inet6 proto udp from any to FF02:0000:0000:0000:0000:0000:0000:00FB port 5353

untuk memungkinkan mDNS beroperasi pada ipv6

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.