web-dev-qa-db-ja.com

ローカルネットワークの外部/内部でApache Webサーバーにアクセスできない

専門用語を間違った方法で使用した場合、事前に謝罪します。私はまだLinux /ネットワーキングの初心者です

私は1週間以上この問題を理解しようとしてきたが、他の人が尋ねた関連する質問はどれも私を助けてくれなかった。最近、Apache2で実行するWebサーバーを構築して、自分のWebサイトをホストしました。また、SSH、FTP、およびVNCに使用することも意図していました。 GoDaddy、cokongwu.comでドメインを登録しました。サーバーの静的IP(192.168.0.105)がセットアップされており、ポート80、21、23、53、および443の静的IPへのポート転送も設定しています。パブリックにアクセス可能なウェブサーバーのセットアップ方法に関するガイドを読んで、最初は完璧に機能していたので、これで十分だと思いましたが、もちろん、ネットワーク外のドメイン名を使用してウェブサーバーにアクセスしようとすると、 、接続できませんでした。さらに検索した後、GoDaddyのゾーンファイルのAレコードをパブリックIPに変更する必要があることがわかりました。そうすると、ネットワーク内でルーターページを再確認したり、接続が単にタイムアウトしたりするネットワーク外で、ウェブサーバーに接続できなくなったことがわかりました。私は後で、パブリックIPを静的に設定できないため、サービス、特にdyndnsを使用して、IPが変更されたときに絶えず更新できるようにする必要があることを理解しました。ソフトウェア更新センターからdyndnsアップデーターをセットアップし、dyndnsアカウントcokongwu.comをセットアップします。これには、公開IPを指すAレコードと、cokongwu.comを指すエイリアスwww.cokongwu.comを使用します。また、ホスト名cokongwu.dyndns.orgをセットアップします。これは、公開IPも参照し、dyndnsネームサーバーをGodaddyのネームサーバーに追加しました。 godaddyのcokongwu.comのAレコードはまだ内部IPを指し、CNameレコード(wwwおよびcokongwu.com)はどちらもcokongwu.dyndns.orgを指します(ただし、godaddysネームサーバーをdyndnsネームサーバーに置き換えたため、ドメインのゾーンファイルを管理できなくなります)

このすべての後、hostname.comにアクセスしようとすると、以前と同じ問題が発生します。内部IPではなくパブリックIPにアクセスしますが、ネットワーク内ではルーター設定ページに転送され、ネットワーク外ではタイムアウトします。これを修正する方法についてはアイデアが不足しているので、どんなアイデアでも大歓迎です。それ(パブリックIP)を私の内部IPにリダイレクトすべきではありませんか?

これらの専門用語のいずれかを間違った方法で使用している場合、申し訳ありませんが、私はこのこと全体にまだ非常に新しいです。

この投稿に関する特定のコマンドに関連する質問がたくさんあるので、同じことをします。

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:5556          0.0.0.0:*               LISTEN      3387/dyn_updater
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      2729/vino-server
tcp6       0      0 :::80                   :::*                    LISTEN      -               
tcp6       0      0 :::21                   :::*                    LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 ::1:631                 :::*                    LISTEN      -               
tcp6       0      0 :::5800                 :::*                    LISTEN      2729/vino-server
tcp6       0      0 :::5900                 :::*                    LISTEN      2729/vino-server
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           -               
udp        0      0 127.0.1.1:53            0.0.0.0:*                           -               
udp        0      0 0.0.0.0:39124           0.0.0.0:*                           -               
udp        0      0 0.0.0.0:631             0.0.0.0:*                           -               
udp6       0      0 :::5353                 :::*                                -               
udp6       0      0 :::53973                :::*                                -       

ufw:

Sudo ufw status
[Sudo] password for fender: 
Status: inactive

000-default.conf:

<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual Host. For the default virtual Host (this file) this
    # value is not decisive as it is used as a last resort Host regardless.
    # However, you must set it for any further virtual Host explicitly.
        ServerName cokongwu.com
        ServerAlias www.cokongwu.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${Apache_LOG_DIR}/error.log
    CustomLog ${Apache_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual Host. For example the
    # following line enables the CGI configuration for this Host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=Apache ts=4 sw=4 sts=4 sr noet
3
onemic

私が理解していることから、あなたは次の問題を抱えています:

1-inside LANからWebサーバーにアクセスできません(FQDN、「完全修飾ドメイン名」www.cokongwu.comを使用)?
2-outside?からWebサイトの機能を確認できません。

1-FQDNを使用して内部からWebサーバーにアクセスします。
ウェブサーバーにアクセスしようとしている場所からの質問が表示されないため、LAN内の別のクライアントからのものであると想定します。

外部DNSサーバーを使用している可能性が高いため、www.cokongwu.comに対するリクエストは、インターネットルーターの外部を意味する公開されているIP番号を解決します(以下を参照)。そのルーターはトラフィックをルーティングしないため、外部IP番号へ内部から内部へ戻るであるため、トラフィックはその時点で停止します。

動作するにはinsideネットワーク、www.cokongwu.comをinternal IP番号(192.168.0.105)として解決する必要があります。内部IP番号を使用してWebサーバーを参照できますが、SSLの使用を計画しているため、最終的にはFQDNを使用してWebサーバーにアクセスする必要があります。そうしないと、証明書エラーが発生します。

内部の名前解決を修正する「ハードな方法」は、内部DNSサーバーをセットアップすることですが、上記はトラブルシューティングと小規模な展開に役立ちます。あなたはグーグルに見知らぬ人ではないようで、内部DNSサーバーをセットアップしたい場合は、インターネット上にそれに関する多くのガイドがあります。

内部の名前解決により内部IPアドレスが取得されると、Webサーバーを参照すると、外部からクライアントであるかのように同じ応答が返されます。

2-Webサーバーへの外部アクセス
www.cokongwu.comをDig www.cokongwu.com +noall +answerで解決すると、次の返信がありました。

www.cokongwu.com。 0 in CNAME cokongwu.com。
cokongwu.com。 59 IN A 69.171.137.28

これは、wwwホストがcokongwu.com(Aレコード)を指すcname(エイリアス)であることを示しています。 69.171.137.28Dig -x 69.171.137.28 +shortを使用して逆ルックアップを実行すると、次の結果が得られます。

dsl-69-171-137-28.acanac.net

これは動的ホストのように見えます。 dyndns更新が機能している場合、それは現在のパブリックIPアドレスです。コマンドラインで次のコマンドを使用してこれを確認します。

curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'

here から盗まれた)またはwww.whatismyip.comを閲覧する

これがあなたの現在のものであると仮定すると、www.cokongwu.comへのブラウジングは外部から動作するはずです...

私はそれを試しましたが、うまくいきませんでした。つまり、次のいずれかまたは組み合わせを意味する可能性があります。

A-dyndnsサービスはIPアドレスを更新していません
B-外部ルーターでの転送が機能していません
C-Webサーバーが応答していません

telnet <ip number> <port number>を使用して簡単なテストを実行しても、上記のポート番号のいずれからも応答はありません。これにより、理由はAまたはBであると考えられるようになります。Bの場合は、正しくポートフォワードしなかったか、モデムと組み合わせてルーターを使用している場合、正しくブリッジされていない可能性があります。モデムをルーターに接続して、すべてのポート転送要求を処理できるようにします。

その他の考え
Webサーバーに転送されるポートの1つとしてport 5を指定したことに気付きました。 ポート53 UDPは着信の標準ですdns要求。実際にWebサーバーマシン上でdns serverを実行していない限り、このポートを安全に閉じることができます...とにかく目的を果たすことはありません。

また、sshとftpの使用に言及していることに気付きましたが、ファイアウォールでポート21と23を開き、Webサーバーに転送しました。ポート23はtelnetポートであり、ポート21はFTPポートです。これらのサービスはどちらもeverythingをユーザー名とパスワードを含むクリアテキストで送信する安全でないプロトコルなので、どちらも使用しないことを強くお勧めします。

ファイアウォールでport 22のみを開いて転送することをお勧めします。 ポート22は、sshによって使用されます。これは、telnetの暗号化された代替品です。 ポート22は、ファイル転送にsshサービスを使用するscpサービスでも使用されます。 telnetおよびftpの代わりにsshおよびscpを使用すると、Webサーバーとの間のすべてのトラフィックが安全に保たれます。
別の推奨事項は、着信sshに別のポート、できればポート1522(単なる例)のような1000を超えるポート番号を使用することです。これは、外部のポートスキャンによって着信sshサービスが検出されるのを防ぐためです。着信ポートを22からそれ以上のポート番号(つまり1522)に変更しますが、それでもWebサーバーのport 22に転送されたままにします。次に、高いポート番号(1522)を使用して外部からsshサーバーにアクセスし、ポート22を使用して内部からsshサーバーにアクセスします。

これがあなたの役に立つことを望み、あなたがあなたの問題を解決することを願っています=)

2
CalMo