☰

OpenBSD 5.5でOpenVPNを介したLANルーティング

tag-icon • tag-icon routing openbsd openvpn pf
OpenBSD 5.5でOpenVPNを介したLANルーティング

LANがインターネットにトンネリングできるようにOpenVPNゲートウェイを設定しています。ゲートウェイは、PCエンジン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/24VPNにアクセスするためにベースアドレスを使用することです。ローカルネットワークを上の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 ホストから ping8.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

これは基本的に次のように機能します。ローカルネットワークからトラフィックを転送し、宛先はすべてのアドレスtun0（特にIPv4）にあり、レポートフラグを指定し、synNATackを使用してアウトバウンドNATを実行しますtun0。角かっこは、インターフェイスがアドレスを変更するとルールが自動的に更新されることを(tun0)示します。pfVPNが複数のピアをサポートしてフェイルオーバーを実行している場合、これが発生する可能性があるため、ルールセットを手動で再ロードする必要はありません。

数時間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設定をしています。

関連情報