Sshサーバーの接続タイムアウト？

openssh-serverをセットアップしようとしていますが、接続に問題があります。ポートを非標準（57757）に変更してから、ルーターをそのポートに転送するように設定しました。私のLANでは、ポート57757を使用してマシンにSSHで接続できますが、WANでは接続できません。

LANの外にいて、間違ったポートでマシンにアクセスしようとすると、すぐに「接続が拒否されました」というメッセージが表示されます。ただし、正しいポートを使用すると、ハングしてタイムアウトするだけです。

問題をデバッグするにはどうすればよいですか？ tracerouteを試しましたが、何も役に立ちませんでした。

編集：私の問題は、ルーターが内部でWANIPによるルーターへのアクセスをサポートしていないことであることに気付きました。別のサーバーにSSHで接続して戻ったところ、正常に機能しました。

承認された回答：

通常、これは、LAN上の間違ったIPアドレスにポートを転送したことを意味します。

NATルーターはポート57757で着信トラフィックを受信し、LAN上の特定のIPアドレスとポートに送信します。

デフォルトでは、Ubuntuはファイアウォールを使用した着信接続の試行をフィルタリングしません。したがって、Ubuntuでファイアウォール設定を変更していない限り、1〜65535のTCPポートへの接続を開こうとすると次のいずれかになります。

ポートが開いている場合は、接続を受け入れます
ポートが閉じている場合は、接続の試行を拒否します

ポートがフィルタリングされた場合ファイアウォールによって、あなたはあなたが見ているものを手に入れるでしょう-接続の試みへの応答はありません。しかし：

ファイアウォール設定を変更した場合を除きます（例：ufw 、iptables ）、フィルタリングされたポートはありません。および
いずれの場合も、LANのポート22に接続できるため、開いています。

ポートを存在しないに転送する場合 NATルーターを備えたマシンでは、そのポートで着信トラフィックを存在しないマシンに送信します。つまり、ブラックホールに送信します。;効果的にドロップされます。

それはまさにあなたが説明した状況を引き起こします。したがって、ポートがLAN上の正しいIPアドレスに転送されていることを確認することで、これを修正できる可能性があります。

それが問題ではなかったことが判明した場合…

…その後、トラブルシューティングを行う必要があります。

LAN側に指定されているポートは正しいですか？つまり、SSHサーバーの構成を変更していないと仮定すると、WAN側のポート57757はポート22に転送するように設定されています。 OpenSSHサーバーで？（これを再確認することをお勧めします。）
選択した特定のポート（57757）に問題がある可能性があります。別のものを試して、それがうまくいくかどうかを確認してください。

（そうでない場合は、これらの手順に進むか、元に戻すか、以下の「57757」を新しい番号に置き換えてください。）
OpenSSHサーバーを再起動してみてください。ネットワークに問題がある場合は、これが役立つ場合があります。それでも問題が解決しない場合は、ルーターとケーブル/ DSL/ISDNモデムも再起動してみてください。

何らかの理由で3つのデバイスすべてを再起動できない場合は、できる限り再起動することをお勧めします。 OpenSSHサービスを再起動できない場合は、少なくともサービスを再起動して（これを修正する可能性が高い）、インターフェースを停止してから再度起動することができます。

OpenSSHサーバーを再起動するには：
```
sudo restart ssh
```
ネットワークインターフェースを停止するには、まず、それがどのインターフェース上にあるかを把握します。
```
ifconfig
```
通常、単一のイーサネットカードおよび/または単一のワイヤレスカードを備えたマシンの場合、イーサネットはeth0です。ワイヤレスはwlan0です。

有線イーサネット接続を停止して再起動する場合は、次のコマンドを実行します。
```
sudo ifdown eth0
```
次に実行します：
```
sudo ifup eth0
```
または、次を実行することもできます：
```
sudo ifconfig eth0 down
```
続いて：
```
sudo ifconfig eth0 up
```
マシンがNetworkManagerを使用してOpenSSHサーバーが実行されているインターフェースを管理している場合でも、上記の方法を試すことをお勧めしますが、NetworkManagerで切断して再接続することもできます。

イーサネット接続の場合は、ケーブルを抜いてから再度差し込んでみてください。ワイヤレス接続の場合は、ハードウェアスイッチ（ある場合）でオフにしてから、もう一度オンにしてみてください。

ここで何か奇妙なことが起こっていますが、どれもそれほど時間はかかりません。より骨の折れるトラブルシューティング手順を実行する前に、徹底的に検討する価値があります。
WAN側からどのようにアクセスしようとしていますか？ LAN上でマシンを使用している場合これを行うには（LANからルーターのWAN IPに接続するだけ）、これは一部のルーターでのみサポートされます。結局のところ、ルーターの仕事は、WAN側とLAN側の間でトラフィックをルーティングすることであり、一方の側からそれ自体にトラフィックをルーティングすることではありません。 LAN内からWANIPの転送ポートへの接続のサポートは、実際にはルールではなく例外ですが、多くのホーム/オフィスルーターにはこの機能があります。

したがって、WAN側のホストからポートフォワードをテストしていない場合は、テストする必要があります。このためのオプションは次のとおりです。
- WAN側から接続します。 これは、学校、職場、友人の家などのリモートマシンへのSSHアクセスなど、そこにあるマシンにアクセスできる場合に機能します。
- テストマシンを間に接続しますルーターとそのを提供するものインターネット接続。 イーサネットポートを備えたケーブル/DSL/ ISDNモデムがあり、ルーターがそれに接続されている場合は、スイッチをモデムに接続し、ルーターをスイッチに接続できます。コンピューターをスイッチに接続します。最初そのマシンがインターネットにアクセスできるかどうかを確認します。最近では、多くのISPが2つ以上の個別のIPアドレスを提供しています。 そうでない場合 、ルーターの設定ページに移動し、WAN IPとWANサブネットマスクを確認してから、同じサブネット内にあるスイッチ接続されたマシンにIPアドレスを静的に割り当てます。
  
  この方法にはいくつかの欠点があります。痛いです！また、理論的には、スイッチに接続されたテストマシンがインターネットにアクセスできるように、ISPがネットワークを誤って構成する可能性があります。（ISPが複数のWANIPに接続できるようにする意図がない限り ISPが割り当てたテストマシンのWANIPを選択した場合、それと実際のWANホストとの間のトラフィックはISPによってブロック/ドロップされる必要があります。しかし、一部のISPには奇妙な慣行があるので、誰が知っていますか？）これが発生した場合、深刻な問題が発生する可能性はほとんどありません（たとえ発生したとしても、最大数分間しか接続できません）。ただし、サブスクリプションの範囲を超えて追加のアクセスを取得しようとする試みと見なされる可能性があり、さらに重要なことに、別のユーザーが同じIPを持っている場合、接続を妨害する可能性があります。したがって、この方法を試してみたい場合 、テストマシンからインターネットにアクセスしようとしないでください。テストマシンがインターネットにアクセスできることがわかった場合はすぐに停止し、ISPによって禁止またはアドバイスされている場合は、これをまったく試みないでください。（ルーターのWAN側がオフィスLANの場合は、最初にネットワーク管理者に相談せずに、これを使用しないでください。これはISPではなく、不要なアクセスを防ぐためにリソースがプロビジョニングされるという前提はありません。）
  
  この手法にはバリエーションがあり、より適切な場合もあります。ルーターはおそらく接続情報（IPアドレス、サブネットマスク、WAN上のゲートウェイ（ルーター）のIPアドレス）を取得します。 ISPから、DHCP経由、ケーブル/ DSL / ISDNモデム経由で、どこに何かを送信するか、DNSサーバーに関する情報がわからない場合に使用します。これが、WAN側のテスト結果を意味のあるものにするために必要な構成を与えるために、ルーターをモデムに接続する必要がある理由です。 ただし、ルーターは通常、WAN側のネットワークに実際に接続されている限り、この情報を記憶します。 したがって、ルーター、モデム、およびテストマシンを接続できますが、その後、スイッチが接続されていることを確認する以外に、テストマシンで何かを行う前に 、モデムを切断します。
- インターネット上の無料サービスを使用して、ポートをテストします。 ルーターのWANインターフェイスとインターネット（上記）の間にテストマシンを挿入することは非常に複雑であり、ISPによってブロックされているためにアクセスできない場合でも、ポートがアクセス可能であると表示されるためです（ルーターの接続にも当てはまります）。 LAN側からのWANIP）–通常は、Webベースのポートスキャンサービスを使用することをお勧めします。
  
  多くのポートスキャンサービスがあります。（一部の人は、ほとんどの人がブロックしようとしているという考えで、「ファイアウォールを確認する」というフレーズを使用しています。促進ではなくアクセス。）これは1つです。それを使用する場合は、[続行]をクリックします、テキストボックスに57757と入力し、[指定されたカスタムポートプローブを使用]をクリックします。。サーバーを実行するために、したい 「オープン」であること。「クローズ」とは、ポートにアクセスできるがサーバーが実行されていないことを意味します（したがって、接続の試行は拒否されました）。「ステルス」とは、ポートにアクセスできないことを意味します。まるでマシンがそこにないかのように（または、ポートがマシンのない場所に転送されたかのように）
さて、あなたはそれが本当にインターネットからアクセスできないと判断しました。（理想的にはWAN側から）スキャンして詳細を取得できる可能性がありますが、多くの場合、これでは役立つ情報が得られません。

これを実行する場合は、WAN側で次を実行できます。
```
sudo nmap -sS -sV -p57757 -vv WAN-IP
```
ポートがフィルタリングされたものとして表示されている場合は、そこに送信されたパケットがおそらくどこにも行かない（または途中でブロック/ドロップされる）ことを確認します。
WANにさらされているポートが、サーバーが実際にリッスンしているポートとは異なることが原因で問題が発生していないかどうかを確認することをお勧めします。 WANのポート55757をLANマシンのポート22に転送すると、問題なく動作するはずですが、おそらくどこか（サーバー、クライアント）で、サーバーとクライアントの観点からポート番号が同じであると想定されています。

おそらく、ルータを介してポート22を転送することはできません。おそらく、ISPがそのポートをブロックしています。しかし、それができるのなら、それをしてください！

それ以外の場合は、OpenSSHサーバーを実際に作成できます。ポート57757でリッスンします。

これを行うには、サーバー構成ファイルをバックアップします。
```
cd /etc/ssh
sudo cp sshd_config sshd_config.old
```
次に編集します：
```
gksu gedit sshd_config
```
または、マシンにGUIがない場合は、コンソールテキストエディタを使用します。
```
sudo nano -w sshd_config
```
ファイルの上部近くに、次のテキストブロックが表示されます：
```
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
```
Port 22を変更するだけです上部の行、たとえばPort 57757 代わりに。
- 追加できますポートを変更するのではなく。ただし、最も単純で効果的な構成でテストすることをお勧めします。
  
  man sshd_configを参照してください OpenSSHサーバーの構成の詳細については。
ファイルを保存し、テキストエディタを終了して、SSHサーバーを次のコマンドで再起動します。
```
sudo restart ssh
```
次に、ルーターのポートフォワードを変更して、ポート57757がOpenSSHサーバーのポート57757（22ではなく）に転送されるようにし、インターネットからアクセスできるかどうかを確認します。
それでも機能しない場合は、Ubuntuのファイアウォールが実際にLANの外部から発信されたトラフィックをブロックしていないかどうかを確認してください。

（自分でこのように構成しなかった場合、これは起こりそうにありませんが、すべての設定が正しく、上記の手順のいずれも問題について何も明らかにしなかった場合は、確認する価値があります。）

実行：
```
sudo iptables -L
```
デフォルトでは、Ubuntuでは出力は次のようになります：
```
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
```
これは単純な許容ポリシーであり、基本的にファイアウォールを実行しないのと同じです。（実際、netfilterファイアウォールモジュールがカーネルにコンパイルされていない場合、システムは上記の設定と同じように動作しますが、iptables netfilterを照会するコマンドの設定はもちろん機能しません。）

構成がそのように見えない場合は、man iptablesをお読みください彼らが何をしているのかを理解したり、質問を編集したり（または、これを読んで同様の問題を抱えている別の人の場合は、新しい質問を投稿したり）、それらを含めます。潜在的に、iptablesに注意してくださいルールにより、構成に関する機密情報が開示される可能性があります。実際には、これは通常は当てはまりません。ただし、ブロックされている特定のホストに関するルールを除いて、または構成が非常に悪い/安全でない場合は、通常、攻撃者にとって、特にマシンにとって、この情報の有用性があります。 NATルーターの背後にあるホーム/オフィスLAN上 、最小限です。

関連：NVidia GeForceGTX970の問題ubuntu16.04？