Mac OS X'te pf.conf kullanarak OpenVPN bağlantısı etkin olmadığı sürece giden trafiği önleyin


19

OpenVPN bağlantım pf.conf kullanarak etkin olmadığı sürece harici ağlara yapılan tüm bağlantıları reddedebildim. Ancak, dizüstü bilgisayarın kapağını açıp açarak veya Wi-Fi'yi kapatıp açarak bağlantı kesilirse Wi-Fi bağlantısını kaybederim.

  • Mac OS 10.8.1 kullanıyorum.
  • Web'e Wi-Fi (genel Wi-Fi dahil olmak üzere çeşitli konumlardan) ile bağlanıyorum.
  • OpenVPN bağlantısı Viscosity ile kurulur.

Aşağıdaki paket filtre kuralları ayarlanmış /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

Paket filtre hizmetini ile başlatır sudo pfctl -eve yeni kuralları yüklerim sudo pfctl -f /etc/pf.conf.

Ayrıca paket filtresini sistem başlangıcında başlatılacak şekilde okumak /System/Library/LaunchDaemons/com.apple.pfctl.plistiçin satırı düzenledim ve değiştirdim .<string>-f</string><string>-ef</string>

Her şey ilk başta işe yarıyor gibi görünüyor: uygulamalar yalnızca OpenVPN bağlantısı etkinse web'e bağlanabilir, bu nedenle güvenli olmayan bir bağlantı üzerinden asla veri sızdırmazım.

Ancak, dizüstü bilgisayar kapağımı kapatıp yeniden açarsam veya Wi-Fi'yi kapatıp tekrar açarsam, Wi-Fi bağlantısı kesilir ve durum çubuğundaki Wi-Fi simgesinde bir ünlem işareti görürüm. Kablosuz simgesine tıklandığında "Uyarı: İnternet bağlantısı yok" mesajı gösterilir:

İnternet bağlantısı mesajı yok

Bağlantıyı yeniden kazanmak için, "Uyarı: İnternet bağlantısı yok" mesajı kaybolmadan ve VPN bağlantısını tekrar açabilmek için Wi-Fi bağlantısını bazen beş veya altı kez yeniden kesmem gerekiyor. Diğer zamanlarda, Wi-Fi uyarısı kendi isteğiyle kaybolur, ünlem işareti temizlenir ve tekrar bağlanabiliyorum. Her iki durumda da, tekrar bağlantı kurmak beş dakika veya daha uzun sürebilir, bu da sinir bozucu olabilir.

Hattın kaldırılması block allsorunu çözer (ancak güvenli olmayan bağlantılara izin verir), bu yüzden Apple'ın bir Wi-Fi bağlantısını yeniden kazanmak ve onaylamak için engellediği bir hizmet var gibi görünüyor. Denedim:

  • pass on $wifi proto icmp allPf.conf dosyasına ekleyerek icmp'yi etkinleştirme
  • Ekleyerek DNS çözümlemesini etkinleştirme pass on $wifi proto udp from $wifi to any port 53
  • Günlüğü (değiştirerek paketlerini bloke daha fazla bilgi edinmek için çalışılıyor block alliçin block log allyapıyor çünkü), ancak günlük OS X altında kapalı görünüyor sudo tcpdump -n -e -ttt -i pflog0günlük sonuçlarını görmek için ": pflog0: tcpdump Böyle bir aygıt yok".

Bunların hiçbiri bir Wi-Fi bağlantısının daha hızlı yeniden kurulmasına yardımcı olmaz.

Wi-Fi bağlantısını yeniden kazanmak için hangi hizmetin mevcut olması gerektiğini belirlemek için başka ne yapabilirim veya Wi-Fi yeniden bağlantılarını daha güvenilir hale getirmek için pf.conf dosyasına hangi kuralı eklemeliyim?


1
bu, daha sonra gelenler için uygun olabilir: sparklabs.com/support/preventing_network_and_dns_traffic_leaks
ptim

Yanıtlar:


14

Little Snitch kullanarak ağ bağlantılarını izleyerek Apple'ın Wi-Fi bağlantısının kullanılabilir olup olmadığını kontrol etmek için arka planda mDNSResponder uygulamasını kullandığını gördüm. mDNSResponder, bağlantıyı kontrol etmek ve ana bilgisayar adlarını IP'lere çözümlemek için ad sunucularına UDP paketleri gönderir.

Daha önce Wi-Fi üzerinden tüm UDP paketlerine izin vermek için sahip olduğum UDP kuralını değiştirmek mDNSResponder'ın bağlanmasına izin verir, bu da Wi-Fi'nin bağlantı kesildikten sonra ilk kez yeniden bağlandığı anlamına gelir. Gelecekte başkalarına yardımcı olması durumunda, Apple'ın Mountain Lion için varsayılan kurallarını içeren son pf.conf'um şöyle görünür:

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

Bu, verilerin ne yazık ki ntpd (zaman senkronizasyonu için) ve mDNSResponder gibi UDP protokolünü kullanan az sayıda uygulama tarafından Wi-Fi üzerinden sızdırılabileceği anlamına geliyor. Ancak bu, uygulamaların çoğunun kullandığı TCP üzerinden verilerin korumasız seyahat etmesine izin vermekten daha iyi görünüyor. Herhangi birinin bu kurulumda iyileştirmesi için herhangi bir önerisi varsa, yorum veya başka yanıtlar kabul edilir.


Bu, ilgilendiğim bir şey, sonuçlarınızı görmek eve gitmem ve denemem için bana ilham verdi! Teşekkürler!
jakev

@SixSlayer Oldukça iyi çalışıyor gibi görünüyor! Başlangıçta ve kesilen bağlantılarda otomatik bağlantı kurmak için Viscosity ayarladım, bu da her şeyi oldukça sorunsuz hale getiriyor. Dikkat edilmesi gereken en önemli şey, pf.conf ve com.apple.pfctl.plist'in görünüşe göre OS güncellemelerinden sonra varsayılana sıfırlanmasıdır, bu nedenle her ikisinin de yedeğini almaya değer.
Nick

IMHO UDP olayı bir çeşit serseri. Ben bir ağ adamı değilim ama bu tür bir şey öğrenmeme yardımcı oluyor ve bu tür detaylar üzerinde kontrol sahibi olmak beni büyülüyor. Etrafta bir iş aramak için biraz zaman harcayacağım, ama eğer birisi beni de yenerse, aynı şekilde.
jakev

Bu harika - tam olarak ne aradığını. Teşekkür ederim!
keo

Aynı anda birçok OpenVPN bağlantısının açılmasını ve paralel olarak yönlendirilmesini belki de sağladınız mı? (bant genişliği kazanmak ve eklemek için)
keo

11

Tüm UDP'ye izin vermenize gerek yoktur . MDNS'deki 'm', 'çok noktaya yayın' anlamına gelir ve "bağlantı yerel çok noktaya yayın adresi" adı verilen belirli bir çok noktaya yayın hedef IP adresi ve bir UDPbağlantı noktası numarası kullanır 5353.

Bu, yukarıdaki çözümünüzde, dünyadaki tüm 3.735 Milyar yönlendirilebilir IP adresine 65535 UDP bağlantı noktasından gelen trafiğin VPN'nizi atlaması için gereksiz yere izin verdiğiniz anlamına gelir. Kaç uygulamanın UDP kullandığına şaşıracaksınız, bu nedenle VPN kapalıyken giden trafiği önlemek için orijinal fikrinizin amacını önemli ölçüde yeniyorsunuz.

Neden bu kuralı kullanmıyorsunuz?

pass on $wifi proto udp to 224.0.0.251 port 5353

Güvenlik duvarı yapılandırmasıyla çok önemli bir kural - güvenlik duvarınızdan istisnalar yaparken daima mümkün olan en belirli kuralı kullanmaya çalışın. Özgüllük bazen kolaylık ve kullanım kolaylığı pahasına gelir, yani daha sonra izin verilmesi gereken başka bir yerel bağlantı protokolü bulabilir ve yine başka bir kural ekleyebilirsiniz.

Yukarıdaki kuralda değişiklik yapar ve orijinal wifi sorununun geri döndüğünü fark ederseniz, PF'niz ağ cihazlarınızın IP adreslerini otomatik olarak yapılandırmak için kullanılan protokol olan DHCP'yi engelliyor olabilir. (bir ev ağında, genellikle geniş bant yönlendiriciniz DHCP sunucunuz olur). DHCP'ye izin vermeniz gereken kural:

pass on $wifi proto udp from 0.0.0.0 port 68 to 255.255.255.255 port 67

* Not: yerine gerekebilir 0.0.0.0için any. DHCPREQUESTBilgisayarınızın önce gönderilen paketin, bir kaynak adresine sahip 0.0.0.0o aşamada, bilgisayarınız henüz bir IP adresi yok çünkü.
Dürüst olmak gerekirse, kullanmaya daha fazla eğilirdim any. Başka bir seçenek, herhangi bir kaynak belirtimini parçalamaktır, yani pass on $wifi proto udp to 255.255.255.255 port 67, kuralın kaynak bağlantı noktası bölümünü kaybettiğimiz anlamına gelir ve mümkün olduğunca spesifik olmak her zaman en güvenli seçenektir.

Umarım yardımcı olur. İşte bazı yararlı bağlantılar:

mDNS: http://en.wikipedia.org/wiki/Multicast_DNS#Packet_sttruc

DHSP: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery


1

Bu bana büyük sıçrama yapmak ve pf.conf kullanmak için yeterli arka plan bilgisi verdi. VPN bağlantısı kesildikten sonra yeniden bağlanmak için 10.8'imde kullandığım şey:

(Ben sadece ethernet kullanın ama $ wifi $ lan değiştirebilirsiniz ve çalışması gerekir)

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

PF kurallarını "kolay" bir şekilde oluşturmak amacıyla, bu küçük killswitch programının kullanılabileceği mevcut (vpn) arayüzler de dahil olmak üzere mevcut aktif arayüzleri tanımlamak ,

Hala devam ediyor, ancak güvenlik duvarı kurallarını düzgün bir şekilde oluşturmak için harici IP'yi ve aktif arayüzleri tanımlamak için iyi bir başlangıç ​​olabilir.

-i(info) seçeneğini kullanarak örnek veya çıktı :

$ 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

Sunucu ipini geçirme -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

Mükemmel olmaktan uzak ama çalışmalar devam ediyor daha fazla bilgi / kod burada bulunabilir: https://github.com/vpn-kill-switch/killswitch


0

- Ek olarak -

Bu satırı eklemek isteyebilirsiniz:

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

mDNS'nin ipv6'da çalışmasına izin vermek için

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.