web-dev-qa-db-ja.com

OpenBSD5.5のOpenVPNを介したLANのルーティング

トンネルを介したインターネットへのLANアクセスを許可するようにOpenVPNゲートウェイを構成しています。ゲートウェイは、PCエンジンAPUプラットフォームでOpenBSD5.5-stableAMD64を実行しています。

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

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

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

次の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

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

たとえば、任意のLANホストから8.8.8.8とgoogle.comにpingを実行できますが、最初の応答は常に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

これはほぼ確実にpf.confのNATの問題ですが、何度も構成を試みた後、トラフィックを渡す正しい方法を見つけるのに苦労しています。

DD-WRTとiptablesを使用していたとき、これが私の構成でした。

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

ただし、これをpfに「移植」する方法はわかりません。任意の提案をいただければ幸いです！

routingopenbsdopenvpnpf
2
ssh2ksh

これは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上の任意のアドレス宛てのローカルネットワークからのトラフィックを渡し、synフラグとackフラグのみを確認し、アウトバウンドNAT tun0を使用します。 (tun0)を囲む括弧は、インターフェースがアドレスを変更したときにルールを自動的に更新するようにpfに指示します。これは、VPNが複数のピアをサポートしていてフェイルオーバーする場合に発生する可能性があるため、ルールセットを手動で再ロードする必要がなくなります。

OpenBSD PF Filtering ページのある時点で、ルールを改良するのに役立ちました。

# /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構成に取り組んでいます。

0
ssh2ksh