☰

OpenVPN クライアントから OpenVPN サーバーの背後にある LAN への送信接続は、サーバー カーネルによって転送されますか?

tag-icon • tag-icon iptables openvpn kernel forwarding tun
OpenVPN クライアントから OpenVPN サーバーの背後にある LAN への送信接続は、サーバー カーネルによって転送されますか?

ちょっと理解できない奇妙な動作が見られました。そこで、下の図に示すように OpenVPN 接続を設定しました。(TUN とクライアント間の設定です)。このシナリオでは、ping のルートについて考えます。 私のOpenVPN接続

 from client: 192.168.200.102 to LAN: 10.198.0.16

一般的に、このpingが成功することは驚くべきことではありませんが、私の理解では、サーバーのiptables設定を次のように変更した場合、

-P FORWARD DROP

そしてさらに

 net.ipv4.ip_forward = 0.

上記の設定では、トラフィックは宛先に到達しないはずです。トラフィックは成功しますが、LAN インターフェイスに到達することはありません。問題は、LAN インターフェイス eth0 10.198.0.16 に到着するトラフィックを確認できないことです (tcpdump データ ネットワーク パケット アナライザーを実行しても)。さらに、LAN IP が tun インターフェイスにバインドされているかのように、tun インターフェイスがトラフィックに自己応答しているように見えます。以下を参照してください。

sudo tcpdump -i tun0 tcpdump: 16:34:21.391381 IP 192.168.200.102 > 10.198.0.16: ICMP echo request, id 14, seq 1885, length 64 16:34:21.391514 IP 10.198.0.16 > 192.168.200.102: ICMP echo reply, id 14, seq 1885, length 64

ここで何が起こっているのでしょうか？私が理解している限りでは、クライアントからのリクエストはサーバーのtunインターフェースに送られ、最終的には転送済みカーネルによって eth0 に送信されていますよね? 通常は、次または を実行することで表示されますsudo tcpdump -i tun0かsudo tcpdump -i eth0?

私がこのことにこだわる理由は、クライアントがサーバー上の LAN にアクセスできないようにするルールを実装する方法がなければ、セキュリティ上のリスクになると考えているからです。ここで私が見逃しているものは何でしょうか。パケットを eth0 インターフェイスに転送する OpenVPN プロセスがあるのでしょうか (クライアント間の構成を意図しているとおり)。

私の問題をより良く解決できるように、以下に診断結果を添付しました。

サーバーの場合

  1. ip addr

    `1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
    valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b8:27:eb:5c:a6:e6 brd ff:ff:ff:ff:ff:ff
    inet 10.198.0.16/24 brd 10.198.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe5c:a6e6/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:09:f3:b3 brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.200.1/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::87cd:fedd:92fc:cde/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

`

  1. ip route

    default via 10.198.0.1 dev eth0 proto static 
10.198.0.0/24 dev eth0 proto kernel scope link src 10.198.0.16 
192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.1 
192.168.178.0/24 via 192.168.200.1 dev tun0 scope link

  2. server openvpn.conf

    tls-server
mode server
dev tun
local 10.198.0.16
proto tcp-server
port 1234
user openvpn
group openvpn
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey
dh /etc/openvpn/dh2048.pem
ifconfig-pool 192.168.200.2 192.168.200.103 255.255.255.0
client-config-dir /etc/openvpn/ccd
ifconfig 192.168.200.1 255.255.255.0
keepalive 10 120
comp-lzo
client-to-client
push "topology subnet"
topology "subnet"
log /var/log/openvpn.log

クライアント向け

  1. ip addr

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 38:af:d7:a0:52:ec brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:28:f8:8d:1c:6f brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.79/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 859868sec preferred_lft 859868sec
    inet6 2a0a:a540:d54:0:bd79:eb10:5e26:548a/64 scope global temporary dynamic 
       valid_lft 7190sec preferred_lft 3590sec
    inet6 2a0a:a540:d54:0:6086:b044:dff:2694/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7190sec preferred_lft 3590sec
    inet6 fe80::ad5c:6e18:87fa:dff4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 192.168.200.102/24 brd 192.168.200.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::5dfc:6b3a:3c4d:e9a4/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

  2. ip route

     default via 192.168.178.1 dev wlp2s0 proto dhcp metric 600 
 169.254.0.0/16 dev wlp2s0 scope link metric 1000 
 10.198.0.0/24 via 192.168.200.1 dev tun0 
 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.102

 192.168.178.0/24 dev wlp2s0 proto kernel scope link src 192.168.178.79 metric 600

  3. client openvpn.conf

     dev tun
 client
 nobind
 remote 11.22.33.44
 proto tcp
 port 1234
 ca /etc/openvpn/cacert.pem
 cert /etc/openvpn/user_cert.pem
 key /etc/openvpn/user
 comp-lzo
 verb 3
 keepalive 10 120
 log /var/log/openvpn.log

  4. ccd for client

    iroute 192.168.178.0 255.255.255.0

答え1

もちろん、VPN とネットワークの残りの部分との間のトラフィックは を経由しますtun0。このトラフィックについては、FORWARD通常どおりチェーンが参照され、誰がどこに接続できるかを制御できます。ip_forwardが有効になっていない場合、トラフィックは転送されません。

が使用されていない場合client-to-client、クライアント間のトラフィックは同じパスを使用します。tun0つまり、インターフェイスからサーバー OS に表示され、OS ルーティング テーブルを使用して適切にルーティングされ、ファイアウォールを通過します。唯一の違いは、宛先が の背後にあると判断されtun0、パケットが を経由して出力されることです。

OpenVPN プロセスはユーザー空間にあり、tun0 はカーネル空間にあるため、あまり効率的ではなく、パケットごとに少なくとも 2 つのコンテキスト変更が発生します。

ただし、 を使用するとclient-to-client、クライアント間のパケットは に表示されずtun0、サーバーのファイアウォールFORWARDチェーンは参照されず、ip_forward制御はパケットの転送に影響を与えません。 OpenVPN プロセス自体は、ホスティング OS から独立した独自のルーティング テーブルを持つルーターになります。 これは、status管理インターフェイスのコマンドで確認するか、ステータス ファイルにダンプすることができます。 この「ルーター」内のルートは、ディレクティブ (「内部ルート」の略だと思います) で制御できます。これは、クライアントのファイルまたはスクリプトによって生成された動的構成iprouteでのみ有効です。client-config-dir

最も簡単な方法は、VPN を特別なものとして考えないことです。トンネルが確立されたら、VPN のことを忘れてください。VPN は、各コンピューター (サーバーとクライアント) の通常のインターフェイスの 1 つにすぎず、すべてのインターフェイスが通常のシンプルなルーターに接続されているだけです。通常のルーティングとファイアウォールについて考えてください。

やっと気づいたのですが、VPNサーバー自体他のインターフェースに割り当てられているにもかかわらず、このパケットは転送されませんいずれにせよ、その宛先はサーバー自体であるため、 はip_forwardこのパケットの処理方法に影響を与えず、INPUTファイアウォール チェーンを通過し、応答は通過しますOUTPUT(つまり、FORWARDシステム自体宛てでない場合のようなチェーンではありません)。パケットは からシステムに入りtun0(そこで表示されます)、eth0送信されないため では表示されません。ローカルで処理されます。応答についても同様です。

ルーティング関連のコードにとって、アドレスがシステム上のどこに割り当てらるか (どのインターフェースか)、またはアクセスするためにシステムのどのアドレスを使用するかは重要ではありません。重要なのは、それがシステムに属しているかどうかです。

関連するセキュリティ上の問題は、サービスを何らかのインターフェースに割り当てられた IP アドレスにバインドすると、他のインターフェースを介したこのサービスへのアクセスが遮断されると考える人がいることです。これは間違っています。他のインターフェースの背後にある他のシステムが、サービスがバインドされているIPへのルートを持っている場合、ことができるようになりますサービスにアクセスできません。これはサービスを保護する正しい方法ではありません。正しい方法は、適切なファイアウォールの設定です。

関連するもう1つの問題は、一部の人がping -I <local-address> <address-to-ping>または を使ってping -I <interface> <address-to-ping>、どのインターフェースのpingを送信するかを直接選択していると考えていることです。これも間違いです。この方法では、どのインターフェースのpingを送信するかしか選択できません。送信元アドレスping はありますが、送信するインターフェイスはありません。インターフェイスは、パケットの宛先アドレスのみに基づいてルーティング テーブルに厳密に従ってルーティング コードによって選択されます (VRF または RPDB の設定は行われていないと想定していますが、これは高度な内容であり、設定した人はいずれにしてもこの機能について知っています)。

関連情報