質問

自宅HTTPサーバー(Apache、80ポート)を立てようと思い、Ubuntu 18.04LTSをサーバーにしてポート解放をして外部から接続できるようにしようと思いました。しかし、何度ポート解放を行って、開放確認を行っても失敗してしまいます。
二重ルータ環境でもなく、サーバーは起動していて、ファイヤーウォールも80番は許可しています。
パソコンのプライベートIPアドレスは192.168.10.8で、ルータには192.168.10.8の80番だけ通す設定にしました。
プロバイダーはここにかいてあるもののうちのどれにも当てはまりません。

ルータはAterm WF1200HPです。
原因は何でしょうか。解決策を教えていただけませんか。

GoogleへのTracerouteの結果

bash
1$ traceroute -d google.com
2traceroute to 172.217.31.142 (172.217.31.142), 30 hops max, 60 byte packets
3 1  aterm.me (192.168.10.1)  3.928 ms  7.802 ms  8.363 ms
4 2  10.141.82.2 (10.141.82.2)  9.449 ms  9.807 ms  13.157 ms
5 3  192.168.37.1 (192.168.37.1)  7.699 ms  8.272 ms  9.359 ms
6 4  192.168.37.240 (192.168.37.240)  13.983 ms  13.020 ms  14.760 ms
7 5  219.99.255.226 (219.99.255.226)  20.579 ms  20.172 ms  19.877 ms
8 6  210.158.148.248 (210.158.148.248)  15.237 ms  9.406 ms  7.977 ms
9 7  209.85.174.218 (209.85.174.218)  9.994 ms  8.905 ms  10.685 ms
10 8  108.170.242.193 (108.170.242.193)  12.925 ms 108.170.242.161 (108.170.242.161)  12.569 ms 108.170.242.193 (108.170.242.193)  12.839 ms
11 9  74.125.251.237 (74.125.251.237)  10.338 ms  10.115 ms  11.566 ms
1210  nrt20s08-in-f14.1e100.net (172.217.31.142)  11.599 ms  10.889 ms  12.319 ms

行動規範の内容に同意します

回答4件

192.168.10.1の外側は10.141.82.2(プライベートアドレス)、さらにその外側が192.168.37.1(これもプライベートアドレス)、さらに192.168.37.240とプライベートアドレスが続きます。
4重ルーター環境(確かに2重ルーター環境ではない)になっていますので、上位3つのルーターもポートフォワードを設定しないと外部からアクセスできません。
もし上位ルーターがプロバイダのものであなたが制御できないのならば、あなたが参照したリストの不備(といっても全てを網羅することは難しいのでNGリストに載っていたらNG、載ってなくてもOKリストに載っていない以上、OKかNGか不明)です。

tracerouteで出てくる個々のIPアドレスがグローバルかローカルかをhttpサーバーに近い方から判定し、内側にローカルのIPアドレスを持ったルーターが続く間は、そのルーターにポートフォワード設定が必要です。
10.で始まるもの、192.168.で始まるもの等がローカルIPアドレスです。

投稿2020/08/11 07:21

編集2020/08/11 08:02

sage

総合スコア1240

fuji_0055

2020/08/11 07:28

tracerouteで同じIPが2つ並んでいなくても、この場合三重ルータになっているということでしょうか？

行動規範の内容に同意します

CATV のインターネットサービスを利用しているのだと思いますが、aterm までグローバルアドレスが来ていないので、自身の管理するルータを弄んで何とかするってことはできません。

やるなら、プロバイダにグローバルを振ってもらう必要があります。

以下のサービスを検討してみてください。
固定IPサービス
集合住宅だと使えないとあるので、難しいかも。。。

まぁ、VPN が楽な気がします。

投稿2020/08/13 11:54

退会済みユーザー

総合スコア0

fuji_0055

2020/08/14 04:55

プランをケーブルから光に変えたことでポート解放ができなくなったので(ケーブルのときはIPが変動するプランでも開放できていた)、プランを変えてネットワーク構成が変わってしまったのが原因としての可能性が高いです。 VPNで自宅サーバーをやることも試してみます。ありがとうございました。

行動規範の内容に同意します

インバウンド方向の設定が必要なのでは？

DMZホスト機能
https://www.aterm.jp/function/wf1200hp/guide/dmz.html

投稿2020/08/11 14:38

退会済みユーザー

総合スコア0

fuji_0055

2020/08/12 04:19

ありがとうございます。DMZホスト機能の設定を行ってみましたが、外部からアクセスできませんでした。

退会済みユーザー

2020/08/12 06:43

確認ですが、Aterm WF1200HPがWAN側にグローバルIPアドレスを持っていて、そのグローバルIPアドレスで開放確認行っているんですよね？あと開放確認の失敗メッセージは、タイムアウトした場合の「到達できませんでした」、リセットパケットが返された「アクセスできません」とあるようですが、到達～のほうですか？

hana_yama_san

2020/08/13 12:28

unreachable（到達できません）とtimeoutは別物です。 rstなりport unreachableは存在秘匿のために普通は返しません。サーバ自体に特に設定していなくてもネットワーク機器などの「TCP Intercept」等で実装されているのではないでしょうか。ルーティングが無い場合の「network unreachable」は、比較的そのまま返ってきます。

fuji_0055

2020/08/14 04:49

ありがとうございます。「到達できませんでした」のほうです。

退会済みユーザー

2020/08/16 03:55

コメントありがとうございました。 atermの設定などではなく、他の方が書かれているようにプロバイダ関連の問題のようですね。

行動規範の内容に同意します

ベストアンサー

ルータが何重であるかは、関係有りません。
※そもそもルータなのかNAT箱なのかも関係有りません。

重要なのは、各段階での静的NAPTが適切に設定されているかどうかであり、
されていないから、通信できないのです。

自分のサーバからGoogleへのTracerouteをしても意味が有りません。
※戻りアドレスが通るかどうかは診断できるが、その戻りアドレスは見えない。

逆にインターネット側から「自分のIPのグローバルアドレス」に
tracerouteしてください。

その上で、そのtracerouteが完全に止まってしまう最後のアドレスを持つ
機器のLANに近い側のアドレスを、調査するなどすれば、
被擬箇所を特定できるかも知れません。

特定できてプロバイダにお願いしても、まず対応してもらえないでしょうけれど。

・・・しかし、そんな多段LSNのプロバイダが有るのかな？

2 10.141.82.2 (10.141.82.2) 9.449 ms 9.807 ms 13.157 ms
3 192.168.37.1 (192.168.37.1) 7.699 ms 8.272 ms 9.359 ms
4 192.168.37.240 (192.168.37.240) 13.983 ms 13.020 ms 14.760 ms

・・これら全部反対側はグローバルIPが設定されていると言う落ちも可能性としては有ります。

とにかくWAN側かtracerouteすれば何か解ってくることが有るでしょう。

投稿2020/08/11 12:06

hana_yama_san

総合スコア923

fuji_0055

2020/08/12 04:25

ありがとうございます。https://mgt.jp/t/traceroute#を使って、WAN側からこちら側にアクセスしてみました。しかしながら、IPに到達できませんでしたと表示されます。結果は以下のとおりです。 traceroute to 自分のIP (自分のIP), 20 hops max, 40 byte packets 1 172.22.0.254 0.444 ms 0.407 ms 0.393 ms 2 103.87.178.122 3.305 ms 3.454 ms 3.584 ms 3 103.87.177.5 5.654 ms 5.860 ms 5.997 ms 4 103.87.176.225 5.160 ms 5.157 ms 5.146 ms 5 111.108.4.85 5.185 ms 5.120 ms 5.109 ms 6 27.85.199.1 7.510 ms 7.366 ms 7.352 ms 7 27.85.132.158 12.374 ms 13.948 ms 13.798 ms 8 27.85.224.250 11.113 ms 11.332 ms 11.319 ms 9 210.132.125.221 11.880 ms 11.858 ms 11.929 ms 10 111.87.15.2 12.076 ms 11.749 ms 11.953 ms 11 210.158.147.107 108.797 ms 107.194 ms 107.115 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * *

hana_yama_san

2020/08/12 11:29

進歩です。今度は「210.158.147.107」に対して内側から tracerouteしましょう。もちろん名前解決付で。そのネックになっている機器がどこの物なのか解る可能性があると思います。そこで問い合わせなり何なり一歩進めるはずです。（多段で問い合わせするハメになる可能性も有りますし、　解決すると言う保証がある訳ではないですが）

fuji_0055

2020/08/13 04:37

ありがとうございます。内部から210.158.147.107にtracerouteしてみました。イマイチ何が原因なのか分からないですね... $ traceroute -d 210.158.147.107 traceroute to 210.158.147.107 (210.158.147.107), 30 hops max, 60 byte packets 1 aterm.me (192.168.10.1) 4.928 ms 5.618 ms 5.927 ms 2 10.141.82.2 (10.141.82.2) 9.632 ms 9.933 ms 10.152 ms 3 192.168.37.1 (192.168.37.1) 7.116 ms 9.504 ms 9.527 ms 4 192.168.37.240 (192.168.37.240) 10.263 ms 10.579 ms 10.453 ms 5 219.99.255.226 (219.99.255.226) 10.632 ms 10.852 ms 11.064 ms 6 210.158.148.248 (210.158.148.248) 11.410 ms 22.451 ms 15.248 ms 7 210.158.147.8 (210.158.147.8) 8.665 ms 210.158.150.24 (210.158.150.24) 9.331 ms 8.671 ms 8 210.158.147.24 (210.158.147.24) 9.765 ms !X 210.158.147.8 (210.158.147.8) 9.473 ms !X 210.158.150.8 (210.158.150.8) 10.522 ms !X

hana_yama_san

2020/08/13 11:52 編集

7 210.158.147.8 (210.158.147.8) 8.665 ms 210.158.150.24 (210.158.150.24) 9.331 ms 8.671 ms 8 210.158.147.24 (210.158.147.24) 9.765 ms !X 210.158.147.8 (210.158.147.8) 9.473 ms !X 210.158.150.8 (210.158.150.8) 10.522 ms !X 興味深いです。8段目は3ルート通っていますが、すべて「!X」（管理的に禁止）ですが、7段目の 210.158.150.24 を通ったパケットが同じ7段目にある210.158.147.8に転送して禁止されています。 ※おそらくこれはループの回避のためのACLが仕込まれている証拠であり、このあたりの機器一群が同じ管理下に有ると思われます。試しに > whois 210.158.150.8 〜中略〜 inetnum: 210.158.150.0 - 210.158.150.255 netname: CNCI-SV descr: COMMUNITY NETWORK CENTER INC. > whois 210.158.147.8 〜中略〜 inetnum: 210.158.147.0 - 210.158.147.255 netname: TDNC-10G descr: COMMUNITY NETWORK CENTER INC. > whois 210.158.147.24 同上と同じ管理下のネットワークであり、反対側からIPが届かなくなった、 > whois 210.158.147.107 〜中略〜 inetnum: 210.158.147.0 - 210.158.147.255 netname: TDNC-10G descr: COMMUNITY NETWORK CENTER INC. ・・と同じ管理下で、しかも（管理上のセグメントで実際のネットワーク構成とは違いますが） 2つと同じ/24ネットワークのアドレスを持っています。以上から、自分のIPとWAN側双方向にIPリーチゃブルになるための鍵は、 COMMUNITY NETWORK CENTER INC.が握っていることが解ります。ここに問い合わせ可能であれば一歩前進できるでしょう。健闘を祈ります。補足-------------------------------------------------------- 内側から出て行くときに最初に遭遇するグローバルアドレス > whois 219.99.255.226 〜中略〜 inetnum: 219.99.224.0 - 219.99.255.255 netname: KATCH-NET descr: KATCH Network Inc. 上記があなたの契約するプロバイダなのかも知れません。その場合、もう次のネットワークが COMMUNITY NETWORK CENTER INC.管理下なので、グループ企業か何かでしょうが、問い合わせ窓口は、 KATCH Network Inc.で有ろうと思われます。出てきた担当がバカだとなかなか言っている意味が通じない可能性も有ります。あせらず根気よくお願いします。

行動規範の内容に同意します

あなたの回答