外部通信用のNAT設定について

Question

あるクラウド環境でサーバ運用しています
今回、WEBサーバから決済用で通信するIPアドレスを１つに固定するために
決済サーバと通信する専用のサーバを作成することになりました
そこで、WEBサーバから決済用のドメイン宛てはNATサーバ経由で決済サーバと通信させるための
NAT設定についてご教示頂きたく思います

構成は下記のようになります
                                                            決済会社への通信
  　　　　Webサイトへの通信                                           ----->> [ 決済会社サーバ ]
   　　　　[ LoadBalance ]                                           |
        　　　　 |                                                   |　　
<外部I/F>        |　　　　　　　　　　　　　　　　　                   <外部I/F>
   [ WEBサーバ ] ----- > [ 決済接続ドメイン通信 ] ----- > [ NATサーバ ]
  　　　　　　　 <内部I/F>  　                         <内部I/F>

WEBサーバには外部接続用のI/Fと内部接続用のI/Fがあります
決済用通信はWEBサーバとNATサーバ通信は内部通信I/F同士で接続出来るようにして
NATサーバの外部通信I/Fから決済会社サーバと接続させる方向です

この時のNAT設定（iptabale設定）をどのようにすればいいのかあまり理解出来ておりませんので
ご教示頂けますと幸いです

よろしくお願い致します

要件が変わりましたので再度修正記載させて頂きます

サーバは内部IPを保持していますが、サーバ間通信はグローバルIPアドレス同士でしか接続しないことが条件です
構成は下記図のようになります

現時点、natサーバから決済用サーバへの80ポート通信は出来ています
WEBサーバから決済用サーバには80ポート接続は出来ない仕様です
WEBサーバからの決済接続ドメイン通信はNATサーバと接続させるための
WebサーバとNATサーバとの内部用VPCネットワークなどでのルーティング設定はされていません（しない方針です）

とりあえず、hostsファイル内で決済サーバの名前解決を詐称して、
route add -hostで決済サーバのグローバルIPアドレスはnatサーバのグローバルIP経由で
natサーバに接続させるようにしました。

いちよ、Webサーバからnatサーバまで接続出来るようにしましたが、
natサーバまで受けた決済サーバ宛先の通信を実際の外部決済サーバに転送させる設定について
ご教示いただけますでしょうか
ご回答頂きました設定を入れてみましたが、natサーバから決済サーバへの通信ができない状態となっています

構成は下記のようになります
                                                            決済会社への通信（GlobalIP 150.1.*.*）
  　　　　Webサイトへの通信                                           ----->> [ 決済会社サーバ ]
   　　　　[ LoadBalance ]                                           |
        　　　　 |                                                   |　　
<GlobalIP　50.151.*.*>        |　　　　　　　　　　　　　　　　　     <GlobalIP　50.161.*.*>           
   [ WEBサーバ ] ----- > [ 決済接続ドメイン通信 ] ----- > [ NATサーバ ]
<PrivateIP　10.200.0.2>    　　　　　　　　                         <PrivateIP　10.210.0.2>  

route情報は下記になります

Webサーバのroute情報

[root@web ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.200.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 eth0
169.254.0.0     0.0.0.0          255.255.0.0     U     1002   0        0 eth0
0.0.0.0         10.200.0.1       0.0.0.0         UG    0      0       0  eth0

NATサーバのroute情報

[root@nat ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.210.0.1       0.0.0.0        255.255.255.255 UH    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         10.210.0.1      0.0.0.0         UG    0      0       0  eth0

Answer 1

nat テーブルの POSTROUTING チェインで SNAT または MASQUERADE すればいいです。

// 内部I/Fのネットワークアドレス : 192.168.1.0/24
// NATサーバの外部I/F デバイス名: eth0
// NATサーバの外部I/F IPアドレス: AAA.BBB.CCC.DDD

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source AAA.BBB.CCC.DDD
  または
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

以下の条件が必要です。

• NATサーバの ip_forward が有効であること (sysctl -w net.ipv4.ip_forward=1)
• NATサーバの iptables filter テーブルの FORWARD チェインで許可されていること
• WEBサーバのルーティング設定で、決済会社サーバへの通信が NATサーバを経由すること

---

##(2017/12/22) 18:49 追記

WEBサーバ(50.151.)と NATサーバ(50.155.)は別ネットワークなのですよね？
であれば、「決済接続ドメイン通信」ネットワーク向けのルーターが、それぞれのネットワークに用意されていると思います。
まずは、WEBサーバ <--> NATサーバ で「決済接続ドメイン通信」を経由して双方向に疎通できるようにルーティングする必要があります。

50.151.0.X : 「決済接続ドメイン通信」ネットワークの WEBサーバ側ゲートウェイ
50.155.0.Y : 「決済接続ドメイン通信」ネットワークの NATサーバ側ゲートウェイ


[root@web]# ip route add 50.155.0.0/24 via 50.151.0.X dev eth0

[root@nat]# ip route add 50.151.0.0/24 via 50.155.0.Y dev eth0

  ※ネットワークプレフィックスは /24 と仮定

---

##(2017/12/22) 23:41 追記
ネットワーク構成がわからなくなりましたが、結局、WEBサーバ <--> NATサーバ の通信はデフォルトゲートウェイを経由しているのですか？

WEBサーバ <--> NATサーバ が疎通できていて、80番ポートのみでいいのであれば、NATサーバでは SNAT/MASQUERADE するのではなく、プロキシーを建てればいいのではないでしょうか？

Comments

[tk_flavor]

ご回答ありがとうございます。
接続要件が変わってしまいましたので
質問を修正加筆しております
お手数ですがご回答いただけますと幸いです

[tk_flavor]

ご回答ありがとうございます。

すみません、質問を加筆修正させて頂きました。

スタティックルート設定ですが、下記のように
Webサーバ側に決済ドメイン通信のIPアドレス対象の時はnatサーバ側経由する
設定を入れまして、
Webサーバのhostsファイルで、決済用ドメインをnatサーバIPアドレスとして詐称しています

route add -host 150.1.*.* gw 50.161.*.* eth0

この設定を入れる事でWebサーバから決済サーバへの80ポート通信はnatサーバ側まで来る事が出来ました
このhostsファイルの詐称は不要で、ご回答あるようなスタティックルート設定を入れるほうがいいのでしょうか
これは検証をしてみます

あと、お手数ですが、Webサーバからの決済用通信がnatまで到着したのを
実際のnatサーバ側に送受信できるための設定をご教示いただけますと幸いです
上記、回答のようなnat -A POSTROUTING 設定を入れてみたのですが
natサーバから直で決済サーバに通信が出来なくなりました

大変、お手数おかけしますが
よろしくお願いします

[tk_flavor]

度々、すみません
ありがとうございます

WEBサーバ <--> NATサーバ の通信はデフォルトゲートウェイを経由しているのですか？
→
Webサーバ、NATサーバでrouteコマンドを実行しますとGateWayは表示されていますが、/etc/sysconfig/network-scripts/ifcfg-eth0と/etc/sysconfig/networkには
そのGateWay記載はされいません
NWセグメント超え通信はクラウドのNAT機能などで通信許可などされているのかもしれません
また、サーバ内からcurlコマンドで叩いてtcpdumpで通信内容を確認しましたが
GateWay経由で通信してるようなパケットはありませんでした
yahooとかの外部サイトもcurlで実行しても、GateWay経由で通信されているようなパケットは拾えませんでした。

現在は、下記のようにWebサーバ側で決済サーバのホスト対象はNATサーバのグローバルIPを経由する設定だけを入れていましてNATサーバと接続は出来るようにはしています

route add -host [決済サーバIPアドレス 150.1.*.*] gw [NATサーバのグローバルIPアドレス 50.161.*.*] eth0

ご回答ありましたように
その先のNATサーバをプロキシー設定で決済サーバ側に飛ばしてもいいのですね

大変、申し訳ございません
もし、NATの設定を入れるときはどのような内容ですればよろしいのかなど
ご教示頂けますと幸いです

[TaichiYanagiya]

デフォルトゲートウェイを経由しているのかどうかは traceroute や mtr コマンドで確認できると思います。
環境は AWS なのですか？
「決済接続ドメイン通信」は VPN などではなく、VPC のルーティングテーブルで 10.200.0.0/24 <--> 10.210.0.0/24 を許可するということでしょうか。

> route add -host [決済サーバIPアドレス 150.1.*.*] gw [NATサーバのグローバルIPアドレス 50.161.*.*] eth0

これだと、AWS のグローバル側のネットワークを経由することになりますが、いいのでしょうか？
10.200.0.0/24 <--> 10.210.0.0/24 を許可して、プライベートIPアドレスで通信した方が安全と思いますが、それができないのであれば仕方ないですね。

> もし、NATの設定を入れるときはどのような内容ですればよろしいのか

SNAT, MASQUERADE は 2つの I/F を経由する場合(eth1 -> eth0 など)しか試したことはないのですが、ip_forward を有効にして、「iptables -t nat -A POSTROUTING -s WEBサーバのグローバルIPアドレス/32 -o eth0 -j MASQUERADE」でできませんでしょうか？

[TaichiYanagiya]

すみません。
よくよく考えると、AWS の場合、物理的なサーバ・ネットワークとは異なり、宛先IP (今回の場合、決済サーバ)がサーバの持つものと異なるパケットはフィルターされて、(今回の場合、NATサーバに)届かないかもしれません。
その場合、グローバル側で NAT することはできません。

[TaichiYanagiya]

またまた、すみません。
NAT するためには、WEBサーバから決済サーバ宛のパケットが、NATサーバに直接届く(MACアドレスをNATサーバのものに付け替える)必要があります。
間にルーターを挟むとダメです(ルーターのルーティングテーブルにより、決済サーバに送られるので)。

なので、グローバルIPアドレスでも、プライベートIPアドレスでも、WEBサーバと NATサーバが同じネットワークセグメントである必要があります。

[tk_flavor]

お世話になっております。
コメント頂きましてありがとうございます。

tracerouteコマンド実行したところ
yahooなど外部通信時はGateWayのホップが表示されてきません
今、使用しているクラウドは基本的に別セグメント同士で接続するときは対向サーバのグローバルIPアドレスで接続しています
なぜそのような構成にしたのかはよくわかっていません

>NAT するためには、WEBサーバから決済サーバ宛のパケットが、NATサーバに直接届く(MACアドレスをNATサーバのものに付け替える)必要があります。
→
こちらですが、WebサーバからのMACアドレス情報をNATサーバ側で自身のMACアドレス情報に
書き換える作業が発生するとの事でいいでしょうか
MACアドレス情報を書き換えてNATさせるとき、どのような設定がよろしいのでしょうか
お手数ですが、ご教示頂けますと幸いです

>間にルーターを挟むとダメです(ルーターのルーティングテーブルにより、決済サーバに送られるので)
→
クラウド上でおそらくルータはあるのかと思います
そうなってくると難しいのでしょうか

それか、NATサーバ側のapacheのproxy設定で飛ばすしかないのでしょうか・・

[tk_flavor]

お世話になっております。

NATサーバ側で下記設定して
service iptables save、/etc/rc.d/init.d/iptables reload
してみましたが、Webサーバから決済サーバ側に到達できませんでした

「iptables -t nat -A POSTROUTING -s WEBサーバのグローバルIPアドレス/32 -o eth0 -j MASQUERADE」

戻りパケット設定などがいるのでしょうか

[TaichiYanagiya]

> こちらですが、WebサーバからのMACアドレス情報をNATサーバ側で自身のMACアドレス情報に書き換える作業が発生するとの事でいいでしょうか

違います。
WEBサーバからの送信パケットは、本来は以下のようになります。
Source IP: WEBサーバのIP
Destination IP: 決済サーバのIP
Destination MAC: NATサーバMAC

ところが、NATサーバと別ネットワークのため、ルータ/ゲートウェイに送ることになります。
Source IP: WEBサーバのIP
Destination IP: 決済サーバのIP
Destination MAC: ルータ/ゲートウェイのMAC

受けとったルータ/ゲートウェイは NATサーバのことは知らないので、決済サーバのIPに送ろうとします。
結果、NATサーバには届きません。

> それか、NATサーバ側のapacheのproxy設定で飛ばすしかないのでしょうか・・

はい。
Apache httpd でも squid でも、他のプロキシソフトウェアなどでも。

[tk_flavor]

度々すみません
下記の設定でいけました

■接続元のWebサーバ側で
１．route add -host [決済サーバIPアドレス] gw 接続元Webサーバのデフォルトゲートウェイ eth0
２．/etc/hostsファイルで決済サーバIPアドレスを中継する
　　NATサーバのグローバルIPアドレスに偽装して記載
　[NATサーバのグローバルIPアドレス 決済サーバドメイン]

■中継するNATサーバ側で
１．"echo 1 > /proc/sys/net/ipv4/ip_forward"
２．NAT側の10.210.0.2:80宛に届いたパケットを決済サーバIPアドレス:80へ投げる
　　というPREROUTING-NATを書く
３．「２．」では宛先アドレスを書き換えるだけなので、
　　決済サーバは10.200.0.2という知らないサブネットから受信することになり、
　　戻りのパケットは自分のデフォルトゲートウェイ10.200.0.1へ送りつける。
　　これではマズいので、NATしたパケットの送信元アドレスを10.210.0.2に変更する
　　決済サーバIPアドレス:80宛のパケットは、NATサーバの10.210.0.2という
　　アドレスに付け替えてから送信する"というPOSTROUTING-NATルールを書く

参考にしたページは
https://mo.kerosoft.com/0203
です

いろいろお時間割いて頂きまして
ありがとうございました

[TaichiYanagiya]

NATサーバで DNAT し(WEBサーバには決済サーバのように見せかけ)て決済サーバにポートフォワード、かつ、SNAT/MASQUERADE ですか。
組み合わせたことはなかったです。
実現できてよかったですが、プロキシの方が素直な気もします。