サーバーの公開ができない

自社サーバーを公開する

ソリューションページはこちら

インデックス

 症状    切り分け手順    状態確認方法    トラブル原因と対処方法

症状：サーバーの公開ができない。

ここでは、RTX1200の基本的な設定が終了し、インターネット接続ができている状態で、サーバー公開ができないケースでのトラブルシューティングを提供します。

切り分け手順：通信状況を以下の手順で確認し、問題の切り分け作業を行います。

1-1

サーバーと同一LAN上のPCからサーバーにアクセスできますか？

YES/NO
サーバーの設定に問題があると考えられますので、サーバーの設定を確認してください。
※ 同一LAN上の通信であれば、RTX1200のフィルタやNATは適用されません。

1-2

LAN1上のPCからサーバーのプライベートアドレスにアクセスできますか？

YES/NO
RTX1200のLAN3のフィルタの設定内容を確認してください。
参考：
3-1. LAN3フィルタの設定間違いによるWWWサーバー接続失敗。
3-4. LAN3フィルタの設定間違いによるFTPサーバー接続失敗。
※ LAN1からLAN3へのアクセスはNATが適用されていませんので、プライベートアドレスで通信することになります。

1-3

インターネットからRTX1200のグローバルアドレスへWWW、FTPでのアクセスができますか？

YES/NO
RTX1200の状態を確認するため状態確認方法へ進んでください。
※ サーバー公開ができない主な原因は、フィルタやNATの設定間違いが考えられます。

正常に動作しています。

状態確認方法

この項目ではコマンドによる状態確認方法を紹介します。表示例は正常接続時のものです。
トラブル発生時の状態と比較することで、問題解決の助けとなります。

2-1 プロバイダとの接続状態を確認する

2-2 NATディスクリプタの状態を確認する

2-3 経路情報を確認する

2-4 デバッグログを確認する

2-5 動的フィルタの動作を確認する。

2-1 プロバイダとの接続状態を確認する。

RTX1200の"show status pp 1"コマンドを実行し、内容を確認します。

[正常時]

# show status pp 1
PP[01]:
説明:
PPPoEセッションは接続されています
接続相手:
通信時間: 17秒
受信: 26 パケット [2192 オクテット] 負荷: 0.0%
送信: 32 パケット [1730 オクテット] 負荷: 0.0%
PPPオプション
　LCP Local: Magic-Number MRU, Remote: CHAP Magic-Number MRU
　IPCP Local: IP-Address, Remote: IP-Address
　PP IP Address Local: 172.16.0.1, Remote: 172.16.0.10
　IPV6CP Local: Interface-ID, Remote: Interface-ID
　PP Interface-ID Local: 02a0defffe37b50d, Remote: 02a0defffe3b1534
　CCP: None

[解説]
接続に成功し"PPPoEセッションは接続されています"と表示されています。

2-2 NATディスクリプタの状態を確認する。

RTX1200の"show nat descriptor address"コマンドを実行し、内容を確認します。

[正常時]

# show nat descriptor address
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
　外側アドレス: 172.16.0.1
　ポート範囲: 60000-64095, 49152-59999, 44096-49151
プロトコル 内側アドレス 宛先 マスカレード 種別

TCP

192.168.10.3.21

*.*.*.*.*

21

static---(1)

TCP

192.168.10.2.80

*.*.*.*.*

80

static---(2)
有効なNATディスクリプタテーブルが1個ありました
[解説]
(1)FTPサーバーを公開するための静的IPマスカレードです。
(2)WWWサーバーを公開するための静的IPマスカレードです。

2-3 経路情報を確認する。

RTX1200の"show ip route"コマンドを実行し、経路情報を確認します。

[正常時]

# show ip route
宛先ネットワーク ゲートウェイ インタフェース 種別 付加情報

default

-

PP[01]

static

 

172.16.0.1/32

-

PP[01]

implicit

 

172.16.0.10/32

-

PP[01]

temporary

 

192.168.0.0/24

192.168.0.1

LAN1

implicit

 

192.168.10.0/24

192.168.10.1

LAN3

implicit

 
[解説]
"default"は"ip route default gateway pp 1"コマンドで設定された静的経路です。
インターネットに接続するためには、"default"経路が必要です。

2-4 デバッグログを確認する。

RTX1200に"syslog debug on"を設定し、その後"disconnect 1"を実行します。
LAN1上のPCからWWWブラウザを起動し、URLに"netvolante.jp"を指定します。
その後、RTX1200で"show log"コマンドを実行すると以下のようなログが表示されます。

[接続成功時ログの例]

2010/04/05 18:43:32: PPPOE[01] Connecting to PPPoE server
2010/04/05 18:43:32: PPPOE[01] SEND PADI
2010/04/05 18:43:32: 　　11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1
2010/04/05 18:43:32: 　　93 76 fd 4f
2010/04/05 18:43:32: PPPOE[01] RECV PADO
2010/04/05 18:43:32: 　　11 07 00 00 00 1c 01 01 00 00 01 02 00 00 01 04
2010/04/05 18:43:32: 　　00 06 00 a0 de 37 b5 0e 01 03 00 06 59 e1 93 76
2010/04/05 18:43:32: 　　fd 4f
2010/04/05 18:43:32: PPPOE[01] SEND PADR
2010/04/05 18:43:32: 　　11 19 00 00 00 1c 01 01 00 00 01 02 00 00 01 04
2010/04/05 18:43:32: 　　00 06 00 a0 de 37 b5 0e 01 03 00 06 59 e1 93 76
2010/04/05 18:43:32: 　　fd 4f
2010/04/05 18:43:32: PPPOE[01] RECV PADS
2010/04/05 18:43:32: 　　11 65 00 0d 00 1c 01 01 00 00 01 02 00 00 01 04
2010/04/05 18:43:32: 　　00 06 00 a0 de 37 b5 0e 01 03 00 06 59 e1 93 76
2010/04/05 18:43:32: 　　fd 4f
2010/04/05 18:43:32: PPPOE[01] PPPoE Connect
2010/04/05 18:43:32: PP[01] SEND LCP ConfReq in STARTING
2010/04/05 18:43:32: 　c0 21 01 01 00 0e 01 04 07 00 05 06 0a 06 c3 4d
2010/04/05 18:43:32: PP[01] RECV LCP ConfReq in REQSENT
2010/04/05 18:43:32: 　c0 21 01 01 00 13 01 04 05 ae 03 05 c2 23 05 05
2010/04/05 18:43:32: 　06 49 8b ff 05 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND LCP ConfAck in REQSENT
2010/04/05 18:43:32: 　c0 21 02 01 00 13 01 04 05 ae 03 05 c2 23 05 05
2010/04/05 18:43:32: 　06 49 8b ff 05
2010/04/05 18:43:32: PP[01] RECV LCP ConfAck in ACKSENT
2010/04/05 18:43:32: 　c0 21 02 01 00 0e 01 04 07 00 05 06 0a 06 c3 4d
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] RECV CHAP Challenge in CS_LISTEN/SS_CLOSED
2010/04/05 18:43:32: 　c2 23 01 01 00 1c 10 01 6e b4 2b ab f5 2c 24 c4
2010/04/05 18:43:32: 　6e 4b 1e 98 7f 98 ce 30 2e 30 2e 30 2e 30 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND CHAP Response in CS_LISTEN/SS_CLOSED
2010/04/05 18:43:32: 　c2 23 02 01 00 1d 10 87 88 e2 0f 76 2a cf cc fe
2010/04/05 18:43:32: 　dc 4f bc 6c db 77 7c 61 63 63 6f 75 6e 74 31
2010/04/05 18:43:32: PP[01] RECV CHAP Success in CS_OPEN/SS_CLOSED
2010/04/05 18:43:32: 　c2 23 03 01 00 1d 41 75 74 68 65 6e 74 69 63 61
2010/04/05 18:43:32: 　74 69 6f 6e 20 73 75 63 63 65 65 64 65 64 2e 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND CCP ConfReq in STARTING
2010/04/05 18:43:32: 　80 fd 01 01 00 09 11 05 00 01 03
2010/04/05 18:43:32: PP[01] SEND IPCP ConfReq in STARTING
2010/04/05 18:43:32: 　80 21 01 01 00 10 81 06 00 00 00 00 83 06 00 00
2010/04/05 18:43:32: 　00 00
2010/04/05 18:43:32: PP[01] SEND IPV6CP ConfReq in STARTING
2010/04/05 18:43:32: 　80 57 01 01 00 0e 01 0a 02 a0 de ff fe 37 b5 0d
2010/04/05 18:43:32: PP[01] RECV IPCP ConfReq in REQSENT
2010/04/05 18:43:32: 　80 21 01 01 00 0a 03 06 ac 10 00 0a 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND IPCP ConfAck in REQSENT
2010/04/05 18:43:32: 　80 21 02 01 00 0a 03 06 ac 10 00 0a
2010/04/05 18:43:32: PP[01] RECV IPV6CP ConfReq in REQSENT
2010/04/05 18:43:32: 　80 57 01 01 00 0e 01 0a 02 a0 de ff fe 3b 15 34
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND IPV6CP ConfAck in REQSENT
2010/04/05 18:43:32: 　80 57 02 01 00 0e 01 0a 02 a0 de ff fe 3b 15 34
2010/04/05 18:43:32: PP[01] RECV CCP TermAck in REQSENT
2010/04/05 18:43:32: 　80 fd 06 01 00 04 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] RECV IPCP ConfRej in ACKSENT
2010/04/05 18:43:32: 　80 21 04 01 00 0a 81 06 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND IPCP ConfReq in ACKSENT
2010/04/05 18:43:32: 　80 21 01 02 00 0a 83 06 00 00 00 00
2010/04/05 18:43:32: PP[01] RECV IPV6CP ConfAck in ACKSENT
2010/04/05 18:43:32: 　80 57 02 01 00 0e 01 0a 02 a0 de ff fe 37 b5 0d
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] PPP/IPV6CP up
2010/04/05 18:43:32: PP[01] Local PP Interface-ID 02a0defffe37b50d
2010/04/05 18:43:32: PP[01] Remote PP Interface-ID 02a0defffe3b1534
2010/04/05 18:43:32: PP[01] RECV IPCP ConfNak in ACKSENT
2010/04/05 18:43:32: 　80 21 03 02 00 10 83 06 c0 a8 14 fe 03 06 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] SEND IPCP ConfReq in ACKSENT
2010/04/05 18:43:32: 　80 21 01 03 00 10 03 06 ac 10 00 01 83 06 c0 a8
2010/04/05 18:43:32: 　14 fe
2010/04/05 18:43:32: PP[01] RECV IPCP ConfAck in ACKSENT
2010/04/05 18:43:32: 　80 21 02 03 00 10 03 06 ac 10 00 01 83 06 c0 a8
2010/04/05 18:43:32: 　14 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2010/04/05 18:43:32: 　00 00 00 00 00 00 00 00
2010/04/05 18:43:32: PP[01] PPP/IPCP up (Local: 172.16.0.1, Remote: 172.16.0.10)
2010/04/05 18:43:32: PP[01] Local PP IP address 172.16.0.1
2010/04/05 18:43:32: PP[01] Remote PP IP address 172.16.0.10

"PP[01] PPP/IPCP up"が表示され、プロバイダとの接続が成功していることが分かります。
参考：Open in new window PPPoEのFAQ

2-5 動的フィルタの動作を確認する。

RTX1200の"show log"コマンドを実行し、ログを確認します。
※ログ採取の前にRTX1200に"syslog notice on"を設定しておきます。

[正常時]

2010/04/07 11:52:29: [INSPECT] PP[01][in][201] TCP 172.16.1.1:60297 > 192.168.10.2:80 (2010/04/07 11:52:10)---(1)
2010/04/07 11:52:29: [INSPECT] LAN3[out][101] TCP 172.16.1.1:60297 > 192.168.10.2:80 (2010/04/07 11:52:10)---(2)
2010/04/07 11:55:04: [INSPECT] LAN3[out][100] TCP 172.16.1.1:60302 < 192.168.10.2:60173 (2010/04/07 11:54:59)
2010/04/07 11:55:04: [INSPECT] PP[01][in][202] TCP 172.16.1.1:60302 < 192.168.10.2:60173 (2010/04/07 11:54:59)
2010/04/07 11:55:04: [INSPECT] PP[01][out][105] TCP 192.168.10.2:60173 > 172.16.1.1:60302 (2010/04/07 11:54:59)
2010/04/07 11:55:32: [INSPECT] LAN3[out][100] TCP 172.16.1.1:60298 > 192.168.10.3:21 (2010/04/07 11:53:13)---(3)
2010/04/07 11:55:32: [INSPECT] PP[01][in][202] TCP 172.16.1.1:60298 > 192.168.10.3:21 (2010/04/07 11:53:13)---(4)

[解説]
(1)：WWWサーバー(TCP 80番ポート)へのアクセスが、PP1のIN方向の動的フィルタの201番により通過しました。
(2)：WWWサーバー(TCP 80番ポート)へのアクセスが、LAN3のOUT方向の動的フィルタの101番により通過しました。
(3)：FTPサーバー(TCP 21番ポート)へのアクセスが、LAN3のOUT方向の動的フィルタの100番により通過しました。
(4)：FTPサーバー(TCP 21番ポート)へのアクセスが、PP1のIN方向の動的フィルタの202番により通過しました。

トラブル原因と対処方法

この項目では各トラブル発生時の状態と、原因及びその解決方法を紹介します。
正常時の状態と比較することで、問題解決の助けとなります。

3-1 PP1フィルタの設定間違いによるWWWサーバー接続失敗。

3-2 LAN3フィルタの設定間違いによるWWWサーバー接続失敗。

3-3 PP1フィルタの設定間違いによるFTPサーバー接続失敗。

3-4 LAN3フィルタの設定間違いによるFTPサーバー接続失敗。

3-5 NATディスクリプタの設定間違いによるWWWサーバー接続失敗。

3-6 NATディスクリプタの設定間違いによるFTPサーバー接続失敗。

3-1 PP1フィルタの設定間違いによるWWWサーバーへの接続失敗

このケースは、フィルタの設定間違いによるWWWサーバー公開失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

ログの確認
※ログ採取の前にRTX1200に"syslog notice on"を設定しておきます。

以下ログが表示されました。

2010/04/06 10:28:16: PP[01] Rejected at IN(2000) filter: TCP 172.16.1.1:60133 > 192.168.10.2:80

[解説]
WWWサーバー(TCP 80番ポート)へのアクセスが、PP1のIN方向のフィルタの2000番で破棄されています。
例えば、このような原因としては以下が考えられます。
・PP1のIN方向に静的フィルタの1031番が設定されていない。
pp select 1
ip pp secure filter in 1020 1030 1032 2000 dynamic 201 202
・PP1のIN方向に動的フィルタの201番が設定されていない。
pp select 1
ip pp secure filter in 1020 1030 1031 1032 2000 dynamic 202
※ 設定例では、PP1のIN方向に静的フィルタの1031番と動的フィルタの201番でWWWサーバーへのアクセスを通していますので、これらが設定されていないとインターネットからWWWサーバーへのアクセスができません。

対処方法
フィルタを正しく設定してください。

pp select 1
ip pp secure filter in 1020 1030 1031 1032 2000 dynamic 201 202

3-2 LAN3フィルタの設定間違いによるWWWサーバーへの接続失敗

このケースは、フィルタの設定間違いによるWWWサーバー公開失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

ログの確認
※ログ採取の前にRTX1200に"syslog notice on"を設定しておきます。

以下ログが表示されました。

2010/04/06 10:45:43: [INSPECT] PP[01][in][201] TCP 172.16.1.1:60156 > 192.168.10.2:80 (2010/04/06 10:44:25)
2010/04/06 10:45:45: LAN3 Rejected at IN(2000) filter: TCP 192.168.10.2:80 > 172.16.1.1:60158

WWWサーバー(TCP 80番ポート)からの応答パケットが、LAN3のIN方向のフィルタの2000番で破棄されています。
例えば、このような原因としては以下が考えられます。
・LAN3のOUT方向に動的フィルタの101番が設定されていない。
ip lan3 secure filter out 3000 dynamic 100 200
※ 設定例では、LAN3のIN方向に静的フィルタの2000番で全てのパケットを破棄しています。
同時にLAN3のOUT方向に静的フィルタの3000番と動的フィルタの101番でWWWサーバーへのアクセスを通していますので、これらが設定されていないとWWWサーバーからの応答パケットが通過できません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

ip lan3 secure filter out 3000 dynamic 100 101 200

3-3 PP1フィルタの設定間違いによるFTPサーバーへの接続失敗

このケースは、フィルタの設定間違いによるFTPサーバー公開失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

ログの確認

以下ログが表示されました。
2010/04/06 10:50:17: PP[01] Rejected at IN(2000) filter: TCP 172.16.1.1:60163 > 192.168.10.3:21

[解説]
FTPサーバーへのアクセス(TCP 21番ポート)が、PP1のIN方向のフィルタの2000番で破棄されています。
例えば、このような原因としては以下が考えられます。
・PP1のIN方向に静的フィルタの1032番が設定されていない。
pp select 1
ip pp secure filter in 1020 1030 1031 2000 dynamic 201 202
・PP1のIN方向にダイナミックフィルタの202番が設定されていない。
pp select 1
ip pp secure filter in 1020 1030 1031 1032 2000 dynamic 201
※ 設定例では、PP1のIN方向に静的フィルタの1032番と動的フィルタの202番でFTPサーバーへのアクセスを通していますので、これらが設定されていないとインターネットからFTPサーバーへのアクセスができません。
参考： 正常時状態

対処方法
フィルタを正しく設定してください。

pp select 1 ip pp secure filter in 1020 1030 1031 1032 2000 dynamic 201 202

3-4 LAN3フィルタの設定間違いによるFTPサーバーへの接続失敗

このケースは、フィルタの設定間違いによるFTPサーバー公開失敗事例です。
以下ではRTX1000の状態を確認し原因の究明を行います。

ログの確認

以下ログが表示されました。
2010/04/06 13:32:02: LAN3 Rejected at IN(2000) filter: TCP 192.168.10.3:21 > 172.16.1.1:60218
2010/04/06 13:32:32: [INSPECT] PP[01][in][202] TCP 172.16.1.1:60218 > 192.168.10.3:21 (2010/04/06 13:31:13)

[解説]
FTPサーバー(TCP 21番ポート)からの応答パケットが、LAN3のIN方向のフィルタの2000番で破棄されています。
例えば、このような原因としては以下が考えられます。
・LAN3のOUT方向に動的フィルタの100番が設定されていない。
ip lan3 secure filter out 3000 dynamic 101 200
※ 設定例では、LAN3のIN方向に静的フィルタの2000番で全てのパケットを破棄しています。
同時にLAN3のOUT方向に静的フィルタの3000番と動的フィルタの100番でFTPサーバーへのアクセスを通していますので、これらが設定されていないとFTPサーバーからの応答パケットが通過できません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

ip lan3 secure filter out 3000 dynamic 100 101 200

3-5 NATディスクリプタの設定間違いによるWWWサーバーへの接続失敗

このケースは、NATディスクリプタの設定間違いによるWWWサーバー公開失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

# show nat descriptor address
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
　外側アドレス: 172.16.0.1
　ポート範囲: 60000-64095, 49152-59999, 44096-49151
プロトコル 内側アドレス 宛先 マスカレード 種別

TCP

192.168.10.3.21

*.*.*.*.*

21

static
有効なNATディスクリプタテーブルが1個ありました
[解説]
WWWサーバーを公開するための静的IPマスカレードが設定されていません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

nat descriptor masquerade static 1 1 192.168.10.2 tcp www

3-6 NATディスクリプタの設定間違いによるFTPサーバーへの接続失敗

このケースは、NATディスクリプタの設定間違いによるFTPサーバー公開失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

# show nat descriptor address
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
　外側アドレス: 172.16.0.1
　ポート範囲: 60000-64095, 49152-59999, 44096-49151
プロトコル 内側アドレス 宛先 マスカレード 種別

TCP

192.168.10.2.80

*.*.*.*.*

80

static
有効なNATディスクリプタテーブルが1個ありました
[解説]
FTPサーバーを公開するための静的IPマスカレードが設定されていません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

nat descriptor masquerade static 1 2 192.168.10.3 tcp 21

それでも問題が解決しない場合は、サポート窓口までご相談ください。

ページトップへ戻るReturn to Top