Mac OS Xでpf.confを使用してOpenVPN接続がアクティブでない限り、発信トラフィックを防止する

OpenVPN接続がpf.confを使用してアクティブでない限り、外部ネットワークへのすべての接続を拒否することができました。ただし、ラップトップのふたを閉じたり開いたり、Wi-Fiのオンとオフを切り替えたりして接続が切断されると、Wi-Fi接続が失われます。

• Mac OS 10.8.1を使用しています。
• Wi-Fi経由でWebに接続します（パブリックWi-Fiを含むさまざまな場所から）。
• OpenVPN接続は、Viscosityでセットアップされます。

次のパケットフィルタールールを設定しています /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

でパケットフィルタサービスを開始しsudo pfctl -e、で新しいルールをロードしsudo pfctl -f /etc/pf.confます。

また、システムの起動時にパケットフィルターが起動するように/System/Library/LaunchDaemons/com.apple.pfctl.plist、行<string>-f</string>を編集して変更しました<string>-ef</string>。

これは最初はすべてうまくいくようです。アプリケーションはOpenVPN接続がアクティブな場合にのみWebに接続できるため、安全でない接続を介してデータを漏洩することはありません。

しかし、ラップトップのふたを閉じて再度開くか、Wi-Fiをオフにして再びオンにすると、Wi-Fi接続が失われ、ステータスバーのWi-Fiアイコンに感嘆符が表示されます。Wi-Fiアイコンをクリックすると、「アラート：インターネット接続なし」メッセージが表示されます。

接続を回復するには、「アラート：インターネット接続がありません」というメッセージが消えて、VPN接続を再度開くことができるようになる前に、Wi-Fiを切断して再接続する必要があります。また、Wi-Fiアラートが自動的に消え、感嘆符が消えて、再び接続できるようになります。いずれにせよ、再び接続するのに5分以上かかることがあり、イライラする可能性があります。

回線block allを削除することで問題は解決しますが（安全でない接続は許可されます）、Wi-Fi接続を回復して確認するためにAppleが必要とするサービスをブロックしているようです。私が試してみました：

• pass on $wifi proto icmp allpf.confに追加してicmpを有効にする
• 追加してDNS解決を有効にする pass on $wifi proto udp from $wifi to any port 53
• ブロックされたパケットをログに記録して（に変更するblock allことでblock log all）sudo tcpdump -n -e -ttt -i pflog0詳細を調べようとしますが、OS Xではログを無効にしたようです。

これはいずれも、Wi-Fi接続の再確立に役立ちません。

Wi-Fi接続を回復するためにどのサービスが必要か、またはWi-Fi再接続の信頼性を高めるためにpf.confにどのルールを追加する必要があるかを判断するために、他に何ができますか？

Little Snitchを使用してネットワーク接続を監視することにより、AppleはバックグラウンドでmDNSResponderアプリを使用してWi-Fi接続が利用可能かどうかを確認しました。mDNSResponderは、UDPパケットをネームサーバーに送信して接続を確認し、ホスト名をIPに解決します。

以前にWi-Fi経由ですべての UDPパケットを許可するように設定していたUDPルールを変更すると、mDNSResponderが接続できるようになります。つまり、Wi-Fiは切断後に初めて再接続します。将来的に他の人を助ける場合、AppleのMountain Lionのデフォルトルールを含む私の最終的なpf.confは次のようになります。

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

これは、残念ながら、ntpd（時刻同期用）やmDNSResponderなど、UDPプロトコルを使用する少数のアプリケーションによってWi-Fiを介してデータが漏洩する可能性があることを意味します。しかし、これは、データがTCPを介して保護されずに移動できるようにすることよりも優れているようです。この設定を改善するための提案があれば、コメントや追加の回答を歓迎します。

すべての UDP を許可する必要はありません。mDNSの「m」は「マルチキャスト」を意味し、「リンクローカルマルチキャストアドレス」と呼ばれる特定のマルチキャスト宛先IPアドレスとUDPポート番号を使用し5353ます。

これは、上記のソリューションでは、VPNをバイパスするために、世界中の37億のルーティング可能なIPアドレスすべてに対する65535 UDPポートすべてへのトラフィックを不必要に許可していることを意味します。UDPを使用するアプリケーションの数に驚かれることでしょう。そのため、VPNがダウンしたときに発信トラフィックを防ぐという元のアイデアの目的を大幅に破っています。

代わりにこのルールを使用しない理由：

pass on $wifi proto udp to 224.0.0.251 port 5353

ファイアウォールの設定に関する非常に重要な経験則-ファイアウォールを介して例外を作成する場合は、可能な限り最も具体的なルールを常に使用してください。特異性は、利便性と使いやすさを犠牲にする場合があります。つまり、通過させる必要のある他のリンクローカルプロトコルがあり、さらに別のルールを追加する必要がある場合があります。

上記のルールを入れ替えて、元のwifiの問題が再発することがわかった場合、PFがDHCPをブロックしている可能性があります。DHCPは、ネットワークデバイスのIPアドレスを自動構成するために使用されるプロトコルです。（ホームネットワークでは、通常、ブロードバンドルーターがDHCPサーバーになります）。DHCPを許可する必要があるルールは次のとおりです。

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

*注：あなたが代用する必要があるかもしれない0.0.0.0ためany。DHCPREQUESTお使いのコンピュータは、最初の送信パケットは、送信元アドレスを持つ0.0.0.0その段階で、コンピューターがまだIPアドレスを持っていないため。
正直に言うと、私はの使用にもっと傾くでしょうany。別のオプションは、ソース仕様をリッピングすることです。つまりpass on $wifi proto udp to 255.255.255.255 port 67、ルールのソースポート部分が失われることを意味し、可能な限り具体的であることが常に最も安全なオプションです。

お役に立てば幸いです。便利なリンクを次に示します。

mDNS：http : //en.wikipedia.org/wiki/Multicast_DNS#Packet_structure

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

これにより、大きな飛躍を図り、pf.confを使用するのに十分な背景情報が得られました。VPN接続が切断された後に再接続するために10.8で使用するものは次のとおりです。

（私はイーサネットのみを使用していますが、$ wifiの$ lanを変更でき、動作するはずです）

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

「簡単な」方法でPFルールを作成する目的で、現在の（vpn）インターフェイスを含む既存のアクティブなインターフェイスを特定し、この小さなkillswitchプログラムを使用できます。

まだ進行中ですが、ファイアウォールルールを適切に作成するために、外部IPとアクティブなインターフェイスを識別するための良い出発点になる可能性があります。

-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

サーバーIPを渡す-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

完璧とはほど遠いですが、作業は進行中です。詳細情報/コードについては、https：//github.com/vpn-kill-switch/killswitchをご覧ください。

-追加として-

次の行を追加できます。

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

mDNSがipv6で動作できるようにする