web-dev-qa-db-ja.com

ブリッジネットワーク上のクライアント自体からパブリックIPを介してNATされた仮想化（LXC）サーバーにアクセスするにはどうすればよいですか？

セットアップ

    ____________________________             ____________________________ 
    | Host                     |             | Client                   |
    | Public IP:   66.66.66.66 |             |                          |
    | Internal IP: 10.0.3.1    | <---------> | Internal IP: 10.0.3.192  |
    ----------------------------             ----------------------------
  • パブリックIPを持つホスト（= 66.66.66.66）
  • 投稿の残りの部分でクライアントと呼ばれるLinuxコンテナ（LXC）は、Webサーバーが実行されているvethネットワークオプションで始まりました。
  • ホストでは、ファイアウォールがufwで構成され、それぞれのポートが開かれてクライアントに転送されます。これは機能します。

/etc/ufw/before.rulesでのiptablesポート転送：

# nat Table rules
*nat
:PREROUTING ACCEPT [0:0]

-A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.3.192:80
-A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.3.192:443
# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

ホスト上の/etc/network/interfaces：

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 66.66.66.66
    netmask 255.255.255.0
    network 66.66.66.0
    broadcast 66.66.66.255
    gateway 66.66.66.1
    # dns-* options are implemented by the resolvconf package, if installed
    dns-nameservers 8.8.8.8

/etc/network/interfacesクライアント：

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.3.192
    netmask 255.255.255.0
    gateway 10.0.3.1
    broadcast 10.0.3.255

クライアントからのポートスキャン

Starting Nmap 5.21 ( http://nmap.org ) at 2014-04-18 18:46 CEST
Nmap scan report for 66.66.66.66
Host is up (0.00011s latency).
PORT    STATE  SERVICE
80/tcp  closed http
443/tcp closed https

「外部」からのポートスキャン

Starting Nmap 6.40 ( http://nmap.org ) at 2014-04-18 19:54 CEST
Nmap scan report for 66.66.66.66
Host is up (0.41s latency).
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 Host up) scanned in 1.28 seconds

iptables構成：

$ iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:10.0.3.192:80
DNAT       tcp  --  anywhere             anywhere             tcp dpt:https to:10.0.3.192:443
DNAT       tcp  --  anywhere             anywhere             tcp dpt:43211 to:10.0.3.192:22
DNAT       tcp  --  anywhere             anywhere             tcp dpt:http-alt to:10.0.3.192:8080

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  tcp  --  anywhere             10.0.3.192           tcp dpt:http
MASQUERADE  tcp  --  anywhere             10.0.3.192           tcp dpt:https
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24

バージョン

  • Ubuntu 12.04（ホストとクライアント）
  • LXC（1.0.3-0ubuntu1〜ubuntu12.04.1〜ppa1）

望ましい結果

パブリックIPを介して、クライアント自体からクライアントのポート80でWebサーバーにアクセスしたい。

$ curl http://66.66.66.66
curl: (7) couldn't connect to Host

と同じ結果が得られるはずです

$ curl http://10.0.3.192
<html>.....

不思議なことに、プライベートネットワーク内のクライアントからの$ ping 66.66.66.66は機能します。

私が試したこと

この問題は、いわゆる Hairpin NAT/Loopback NAT ）に非常に関連していることがわかりますが、次のルールでマスカレードを構成することはできませんでした。動作します（PREROUTINGエントリの後の/etc/ufw/before.rules内）：

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -o eth0 -d 10.0.3.192 -p tcp --dport 80 -j MASQUERADE
-A POSTROUTING -o eth0 -d 10.0.3.192 -p tcp --dport 443 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

解決策に対する私の推測は、ブリッジされたネットワーク、またはMASQUERADEルールをセットアップに正しく適合させることができないことが問題であるということです。セットアップ全般に対する提案やコメントは大歓迎です。

関連する質問や記事ですが、役に立ちません

iptablesnatbridgelxcloopback
1
geo_so

（最初に書いたのは、ブリッジネットワークではなくルーテッドネットワークです。現在、LXCを使用していることがわかりますので、よくわかりません。ただし、PREROUTINGが既に機能している場合は、以下に記述した内容が機能することを願っています）

PREROUTINGチェーンを使用している場合、このチェーンは、ルーティングされたパケット（つまり、別の場所から送信されたパケット）のみを変更します。 Hostで生成されたパケット自体はルーティングされないため（他のホストが実行できるように、出力は問題ありません）、このチェーンはcurlのパケットを受信しません。 curlは、いつものようにHostに接続しようとしました。ローカルで生成されたパケットをキャッチする他のチェーンがあります：OUTPUT。

したがって、いくつかの変更を加えて、DNATルールを（-t nat）OUTPUTチェーンにも複製します。OUTPUTは入力インターフェイスを必要としません。 -i eth0を-o lo ! -s 127.0.0.0/8または単に-d 66.66.66.66などに置き換えますが、制限が必要です。それ以外の場合、どこへのWebリクエストもClientに送信されます。最初の例はHostのIPから独立しており、2番目の例は必要に応じて短くなっています。これはタイプミスではありません。それ自体から66.66.66.66に接続する場合、それはローカルパケットであるため、loインターフェイスを経由します。ただし、127.0.0.1のような宛先は再ルーティングできないため（curl http://127.0.0.1/は接続できなかったと言う代わりにタイムアウトします）、127.0.0.0/8は例外として配置されます。

以上です。それ以外はすべてconntrackによって通常どおり処理されます。 2ポート固有のMASQUERADEルールを削除する必要があります。それらは必要ではなく、干渉することさえあります（それらが機能する場合、結果はクライアントは常にホストをWebサーバー上のソースとして見ることになります）

したがって、簡単な答えは（-t natを使用）です。

-A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.3.192
-A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.3.192
-A OUTPUT -o lo ! -s 127.0.0.0/8 -p tcp --dport 80 -j DNAT --to-destination 10.0.3.192
-A OUTPUT -o lo ! -s 127.0.0.0/8 -p tcp --dport 443 -j DNAT --to-destination 10.0.3.192
1
A.B