pf.confを使ってOpenVPN接続がアクティブになっていない限り、外部ネットワークへの接続をすべて拒否することができました。しかし、ラップトップの蓋を閉じたり開けたり、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接続がアクティブな場合にのみウェブに接続できるので、安全ではない接続でデータを漏らすことはありません
しかし、ノートパソコンの蓋を閉めて開き直したり、Wi-Fiの電源を入れ直したりすると、Wi-Fi接続が切れてしまい、ステータスバーのWi-Fiアイコンに感嘆符が表示されてしまいます。Wi-Fiアイコンをクリックすると「Alert: No Internet connection」というメッセージが表示されます
接続を回復させるためには、Wi-Fiを切断して再接続しなければならず、時々5～6回ほど、「アラート：インターネット接続がありません」というメッセージが消えて、再びVPN接続ができるようになる前に、Wi-Fiを切断して再接続しなければなりません。また、Wi-Fiのアラートが勝手に消え、感嘆符が消えて、再び接続できるようになることもあります。いずれにしても、再び接続できるようになるまでに5分以上かかることもあり、イライラすることもあります
block allの行を削除すると問題が解決する（ただし、安全でない接続を許可する）ので、私がブロックしているサービスがあるようで、AppleがWi-Fi接続を回復して確認するために必要なサービスがあるようです。試してみました
- pf.confに
pass on $wifi proto icmp allを追加してicmpを有効にする pass on $wifi proto udp from $wifi to any port 53を追加してDNS解決を有効にする- ブロックされたパケットをログに記録して(
block allをblock log allに変更して)さらに学習しようとしていますが、OS Xではログを見るためにsudo tcpdump -n -e -ttt -i pflog0を行うと “tcpdump: pflog0: No such device exists “という結果になるため、ログは無効になっているようです
いずれも、Wi-Fi接続をより速く再確立するのに役立つものではありません
Wi-Fi接続を回復するために利用可能なサービスが必要なのか、あるいはWi-Fi再接続をより信頼性の高いものにするためにpf.confにどのようなルールを追加すればよいのかを判断するには、他に何をすればよいのでしょうか？
19 None 2012-09-01
Little Snitchを使ってネットワーク接続を監視することで、AppleがバックグラウンドでmDNSResponderアプリを使ってWi-Fi接続が可能かどうかをチェックしていることがわかりました
以前、Wi-Fi 上のすべての UDP パケットを許可するようにしていた UDP ルールを変更すると、mDNSResponder が接続できるようになりました。将来的に他の人の参考になるかもしれませんが、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 を使ってデータを無防備に転送するよりはマシだと思われます。この設定を改善するための提案があれば、コメントや詳しい回答をお待ちしています
14 Nick 2012-09-01
すべてのUDPを許可する必要はありません。mDNSの「m」は「マルチキャスト」を意味し、「リンクローカルマルチキャストアドレス」と呼ばれる特定のマルチキャスト先IPアドレスと、UDPポート番号5353を使用します
これは、上記のソリューションでは、世界中の37億個のルーティング可能なIPアドレスへの65535個のUDPポートへのトラフィックを不必要に許可して、VPNを迂回させていることを意味しています。UDP を使用しているアプリケーションがどれだけ多いかに驚くでしょう
代わりにこのルールを使ってみてはいかがでしょうか
pass on $wifi proto udp to 224.0.0.251 port 5353
ファイアウォールの設定で非常に重要な経験則 – ファイアウォールを介して例外を設定する際には、常に可能な限り具体的なルールを使用するようにしてください。具体的にすることは、便利さや使いやすさを犠牲にしてしまうことがあります。つまり、他のリンクローカルプロトコルを通す必要があることに気付き、さらに別の具体的なルールを追加してしまうかもしれません
上記のルールを入れ替えて、元の wifi の問題が戻ってくるのを見つけたら、あなたの PF は DHCP をブロックしているかもしれません。(ホームネットワークでは、一般的にブロードバンドルータが 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.mDNS.mDNS.mDNS.mDNS.mDNS.http://en.wikipedia.org/wiki/Multicast_DNS#Packet_structure
DHSP: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery
11 smashingly 2014-07-28
これは、私に大きな飛躍をして pf.conf を使用するための十分な背景情報を与えてくれました。以下は私の10.8でVPN接続が落ちた後に再接続させるために使っているものです
(私はイーサネットしか使っていませんが、$lanを$wifiに変えればうまくいくはずです)
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 Cedric 2013-02-11
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
1 nbari 2016-11-19
— おまけに
この行を追加した方がいいかもしれません
pass on $wifi inet6 proto udp from any to FF02:0000:0000:0000:0000:0000:0000:00FB port 5353
を使用して、mDNS が ipv6 で動作するようにします
0 user263367 2015-08-27
