☰

OpenBSD 5.5 上の OpenVPN 経由で LAN をルーティングする

tag-icon • tag-icon routing openbsd openvpn pf
OpenBSD 5.5 上の OpenVPN 経由で LAN をルーティングする

トンネル経由でインターネットへの LAN アクセスを許可する OpenVPN ゲートウェイを設定しています。ゲートウェイは、PC Engines APU プラットフォームで OpenBSD 5.5-stable amd64 を実行しています。

LAN にはre1、、re2およびral0インターフェイスが含まれます。また、vether0ローカル192.168.2.0/24ネットワークをホストする も含まれます。これらのインターフェイスは、 を介してbridge0共通のゲートウェイ、サブネット、および DHCP を提供するために、でリンクされますdhcpd。

VPN が確立され、tun0開かれます。ゲートウェイ自体は VPN に問題なくアクセスできます。

問題は、デフォルトでは、ホストがネイティブ192.168.2.0/24アドレスを使用して VPN にアクセスすることです。 でローカル ネットワークを VPN ネットワークに変換するには、NAT が必要です10.0.1.0/24。

以下の構成を試しましたpf.conf:

# pf.conf -- 10.0.1.10 is my tun0 gateway
set skip on lo
block return
pass in quick on { vether0 re1 re2 ral0 } from 192.168.2.0/24 to !10.0.0.0/8 nat-to 10.0.1.10
pass

以下のルールでも同様の結果が得られました:

# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any

tun0これにより、LAN トラフィックは送信元アドレス で通過でき10.0.1.10、戻りトラフィックはそれぞれのホストに返されます。新しい問題は、戻りトラフィックがまだ正しくルーティングされていないように見えることです。

たとえば、任意の LAN ホストから8.8.8.8およびに ping を実行できますgoogle.comが、最初の応答は必ずtun0と 戻りインターフェイスの間でドロップされます。dig、nslookup、traceroute、などのツールpingは一般に動作が遅く、必要以上に時間がかかります。一部のトラフィックはまだ通過しているものの、ブラウザやその他のアプリケーションは使用できません。

tcpdump損失を証明する:

# 192.168.2.103 is a LAN host
# 74.125.131.139 is google.com

# on ral0
20:59:35.668251 192.168.2.103 > 74.125.131.139: icmp: echo request <-- no reply
20:59:40.651184 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:40.736748 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:41.656101 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:41.741251 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:42.661071 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:42.802410 74.125.131.139 > 192.168.2.103: icmp: echo reply

# on tun0
20:59:35.668359 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:35.764052 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- here's the missing reply, it didn't get to ral0
20:59:40.651221 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:40.736721 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- but the of the replies rest did
20:59:41.656138 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:41.741226 74.125.131.139 > 10.0.1.10: icmp: echo reply
20:59:42.661107 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:42.802372 74.125.131.139 > 10.0.1.10: icmp: echo reply

これはほぼ間違いなく NAT の問題であることはわかっていますpf.confが、設定を何度も試しても、トラフィックを渡す正しい方法を見つけるのに苦労しています。

DD-WRT と を使用していたときのiptables構成は次のとおりでした。

iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept

ただし、これを に「移植」する方法がよくわかりませんpf。 ご提案があれば、ぜひお聞かせください。

答え1

これは問題でしたpf.conf。OpenBSD PF NATこのページでは、トラフィックがインターフェースを正しく通過できるようにする次のルールに導かれましたtun0。

# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin

これは基本的に、 上の任意のアドレス宛てのローカル ネットワークからのトラフィック (具体的には IPv4) を通過させ、およびフラグtun0のみを確認し、 を使用してアウトバウンド NAT を実行します。 を囲む括弧は、インターフェイスのアドレスが変更されたときにルールを自動的に更新するように指示します。 これは、VPN が複数のピアをサポートしていてフェイルオーバーする場合に発生する可能性があり、その場合、ルールセットを手動で再ロードする必要がなくなります。synacktun0(tun0)pf

しばらくしてOpenBSD PF フィルタリングこのページはルールを改良するのに役立ちました:

# /etc/pf.conf
pass out on $vpn_if inet proto { $protos } from $lan_net to any flags S/SA modulate state nat-to ($vpn_if) round-robin
pass in  on $vpn_if inet proto { $protos } from $vpn_gw  to any flags S/SA modulate state

このmodulate stateフラグによりpf​​、より強力な初期シーケンス番号を置き換えることができるため、ネットワーク上の一部のオペレーティング システムを保護するのに役立ちます。

ゲートウェイは現在正常に動作しており、より複雑なpf.conf構成に取り組んでいます。

関連情報