技術的な用語を間違って使用している場合は、あらかじめお詫びします。私はまだLinux/ネットワークの初心者です。
私はこの問題を1週間以上解決しようとしていますが、他の人がした関連する質問はどれも役に立ちませんでした。最近、自分のWebサイトをホストするためにapache2で動作するWebサーバーを構築しました。また、SSH、FTP、VNCにも使用するつもりでした。GoDaddyでドメインcokongwu.comを登録しました。サーバーに静的IP（192.168.0.105）が設定されており、ポート80、21、23、53、443のポート転送も静的IPに設定しました。パブリックにアクセス可能なWebサーバーの設定方法に関するガイドを読んで、最初は完璧に機能していたので、これで必要なことはすべて完了だと思いました。しかし、当然のことながら、ネットワーク外のドメイン名を使用してWebサーバーにアクセスしようとすると、接続できないことがわかりました。さらに調べたところ、GoDaddyのゾーンファイル内のAレコードをパブリックIPに変更する必要があることがわかりました。それを実行すると、ネットワーク内でもルーターのページにリダイレクトされ、ネットワーク外でも接続がタイムアウトするなど、Web サーバーにまったく接続できなくなりました。後でわかったのですが、パブリック IP を静的に設定できないため、IP が変更されたときに常に更新できるように、サービス (具体的には dyndns) を使用する必要がありました。ソフトウェア更新センターから dyndns アップデータをセットアップし、パブリック IP を指す A レコードと cokongwu.com を指すエイリアス www.cokongwu.com を使用して、dyndns アカウント cokongwu.com をセットアップしました。また、パブリック IP を指すホスト名 cokongwu.dyndns.org もセットアップし、dyndns ネームサーバーを Godaddy のネームサーバーに追加しました。 godaddy の cokongwu.com の A レコードは依然として内部 IP を指しており、CName レコード (www と cokongwu.com) は両方とも cokongwu.dyndns.org を指しています。(ただし、godaddy のネームサーバーを 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
答え1
私の理解では、次のような問題が発生しているようです:
1 - ウェブサーバー（FQDN、「完全修飾ドメイン名」www.cokongwu.comを使用）にアクセスできません内部LAN
からウェブサイトの機能を確認できません。外?
1 - FQDN を使用して内部から Web サーバーにアクセスします。
質問からは、どこから Web サーバーにアクセスしようとしているのかわかりません。そのため、LAN 内の別のクライアントからアクセスしていると想定します。
おそらく外部DNSサーバーを使用しているため、www.cokongwu.comへのリクエストは、インターネットルーターの外部にある公開IP番号に解決されます（下記参照）。そのルーターは、外部IP番号へ中から内側に戻る、その地点で交通は停止します。
物事がうまくいくために内部ネットワークでは、www.cokongwu.comはあなたの内部IP 番号 (192.168.0.105)。内部 IP 番号を使用して Web サーバーを参照することもできますが、SSL を使用する予定であるため、最終的には FQDN を使用して Web サーバーにアクセスする必要があり、そうしないと証明書エラーが発生します。
内部の名前解決を修正する「難しい方法」は、内部 DNS サーバーをセットアップすることですが、上記の方法はトラブルシューティングや小規模な展開には有効です。Google に精通しているようですが、内部 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ホストは、cname（エイリアス）を指していますホームページこれはAレコードです。逆引き検索を行うと69.171.137.28とすると次のようにdig -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/<.*$//'
（恥ずかしげもなく盗用）ここ) または、詳しくはこちら
これが現在のブラウザだと仮定すると、ホームページ外部から作業する必要があります...
試してみましたが、うまくいきませんでした。これは、次のいずれか、または組み合わせを意味している可能性があります。
A - dyndnsサービスがIPアドレスを更新していません
B - 外部ルーターの転送が機能していない
C - ウェブサーバーが応答していません
を使用して簡単なテストを行っても、telnet <ip number> <port number>上記にリストしたポート番号のいずれからも応答がありません。これは、理由が A または B であることを示しています。理由が B の場合、ポート転送が正しく行われなかったか、モデムとルーターを併用している場合は、モデムとルーターが適切にブリッジされておらず、すべてのポート転送要求を処理できない可能性があります。
さらにいくつかの考察
あなたが言及したことに気づきましたポート53Web サーバーに転送されるポートの 1 つとして。ポート 53 UDP受信の標準ですDNS リクエスト実際にDNS サーバーWeb サーバー マシン上で実行されている場合、このポートを安全に閉じることができます...いずれにしても、何の役にも立ちません。
また、SSHとFTPの使用について触れていますが、ファイアウォールでポート21と23を開き、Webサーバーに転送しています。ポート23はテルネットポート21はFTPポートどちらも安全でないプロトコルであり、すべてユーザー名とパスワードを含む、クリアテキストで。
開封して転送するだけをお勧めしますポート22ファイアウォール内。ポート22使用されるsshこれは、Telnet の暗号化された代替手段です。ポート22は、SCP-10 ...サービスでは、SSH サービスファイル転送用。sshそしてSCP-10 ...telnetやftpの代わりに、Webサーバーとの間のすべてのトラフィックを安全に保てます。
さらに、着信sshには別のポートを使用することを推奨します。できれば1000以上のポート番号、たとえばポート1522（単なる例）を使用してください。これは、着信sshサービスが外部ポートスキャンによって発見されるのを防ぐためです。着信ポートを22からより高いポート番号（つまり1522）に変更するだけで、引き続き次のポートに転送されます。ポート22Web サーバー上で、外部からは高ポート番号 (1522) を使用して、内部からはポート 22 を使用して SSH サーバーにアクセスします。
これがあなたにとって役に立ち、問題が解決することを願っています =)