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


11

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

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

問題をデバッグするにはどうすればよいですか?tracerouteを試しましたが、有用なことは何もわかりませんでした。

編集:私の問題は、ルーターがWAN IPによる内部アクセスをサポートしていないことであることに気付きました。私は別のサーバーにsshしてから再び接続しましたが、うまくいきました。


リッスンしているポート以外の何かを変更しましたか?
ガントバート

@guntbertいや。ループバックに問題がありますか?
Ci3

ループバック?マシン自体からのみ試しましたか?LAN内にテストする別のデバイスがありますか?
Guntbert

@guntbert別のマシンで試してみましたが、LAN内に問題はありません。
Ci3

「最後の手段」の私の考え:sudo apt-get purge openssh-serverそれを再インストールし(したがって、構成に発生した可能性のあるものをすべて取り除く)、22-> 22を転送するようにルーターを再構成します。
ガントバート

回答:


11

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

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

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

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

ポートがファイアウォールでフィルタリングされている場合、表示れているものが表示れます。接続試行に対する応答はありません。だが:

  • あなたはファイアウォールの設定(例えば、変更した場合を除きufwiptables)、何のポートがフィルタリングされていない、
  • いずれの場合も、LANのポート22に接続できるため、ポートは開いています。

NATルーターを使用してポートを存在しないマシンに転送すると、ポート上の着信トラフィックが存在しないマシンに送信されます。つまり、ブラックホールに送信されます。効果的にドロップされます。

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

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

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

  1. LAN側に指定されたポートは正しいですか?つまり、SSHサーバーの構成を変更していないと仮定すると、WAN側のポート57757 はOpenSSHサーバーのポート22に転送するように設定されていますか?(これを再確認することもできます。)

  2. 選択した特定のポートに問題がある可能性があります(57757)。別の方法を試して、それがうまく機能するかどうかを確認してください。

    (そうでない場合で、これらの手順を続行する場合は、元に戻すか、下の「57757」を新しい番号に置き換えてください。)

  3. 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で切断および再接続を試みることもできます。

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

    ここでは奇妙なことが起こっており、どれも非常に長い時間はかかりません。より骨の折れるトラブルシューティング手順を実行する前に徹底的に行う価値があります。

  4. WAN側からどのようにアクセスしようとしていますか?LAN上のマシンを使用してこれを行う場合(LANからルーターのWAN IPに接続するだけ)、これは一部のルーターでのみサポートされます。結局のところ、ルーターの仕事は、トラフィックをWAN側とLAN側の間でルーティングすることであり、一方から他方へトラフィックをルーティングすることではありません。多くのホーム/オフィスルーターにはこの機能がありますが、実際にはLAN内部からWAN IPの転送ポートへの接続のサポートはルールではなく例外です。

    したがって、WAN側のホストからポートを前方にテストしない場合は、そうする必要があります。これのオプションは次のとおりです。

    • WAN側から接続します。これは、学校、職場、友人の家などのリモートマシンへのSSHアクセスなど、そこでマシンにアクセスできる場合に機能します。

    • 試験機を接続しての間、ルータと何でも提供しインターネット接続を。イーサネットポートを備えたケーブル/ DSL / ISDNモデムがあり、ルーターがそのポートに接続されている場合、スイッチをモデムに接続し、ルーターをスイッチに接続できます。スイッチにコンピューターを接続します。まず、そのマシンがインターネットアクセスを取得しただけかどうかを確認します。最近では、多くのISPが2つ以上の個別のIPアドレスを提供しています。表示されない場合は、ルーターのセットアップページに移動してWAN IPおよびWANサブネットマスクを確認し、同じサブネット内にあるスイッチ接続マシンに静的にIPアドレスを割り当てます。

      この方法にはいくつかの欠点があります。痛い!また、ISPがネットワークを誤って構成して、スイッチに接続されたテストマシンがインターネットにアクセスできるようにすることも理論的には可能です。(複数のWAN IPで接続できるようにすることがISPの意図でない限りISPが割り当てたテストマシンのWAN IPを選択した場合、ISPと真のWANホスト間のトラフィックはISPによってブロック/ドロップされるはずです。しかし、一部のISPには奇妙な慣行があるので、誰が知っていますか?)これが発生した場合、誰かに深刻な問題を引き起こすことはほとんどありません(そして、たとえそれが起こったとしても、最大数分間接続するだけです)。ただし、サブスクリプションの範囲を超えて追加のアクセスを取得しようとする可能性があり、さらに重要なことですが、別のユーザーが同じIPを持っている場合、接続に干渉する可能性があります。したがって、この方法を試してみたい場合、テストマシンからインターネットにアクセスしようとしないでください。テストマシンがインターネットにアクセスできる場合はすぐに停止してください。ISPによって禁止またはアドバイスされている場合は、これを試みないでください。(また、ルーターのWAN側がオフィスLANである場合は、最初にネットワーク管理者に相談することなくこれを使用しないでください。これはISPではなく、望ましくないアクセスを防ぐためにリソースがプロビジョニングされるという仮定はありません。)

      この手法には、より適切な場合もあるバリエーションがあります。IPアドレス、サブネットマスク、ゲートウェイ(ルータ)のIPアドレスをWAN上のこと-あなたのルータには、おそらくその接続情報を取得、それはそれはDNSサーバについて何か、との情報を送信するために場所を知らない場合に使用していますが-あなたからISP、DHCP経由、ケーブル/ DSL / ISDNモデム経由。これが、WAN側のテストの結果を意味のあるものにするために必要な構成を与えるために、ルーターをモデムに接続する必要がある理由です。ただし、ルーターは通常、WAN側のネットワークに実際に接続されている限り、この情報を記憶します。そのため、ルーター、モデム、およびテストマシンを接続できますが、その後すぐに、スイッチが接続されていることを確認する以外に、テストマシンで何かを行う前に、モデムを切断します。

    • インターネット上の無料サービスを使用して、ポートをテストします。ルーターのWANインターフェイスとインターネット(上記)の間にテストマシンを挿入することは非常に複雑であるため、また、ISPによってブロックされているためにアクセスできない場合でもアクセス可能なポートとして表示されるため(これは、 LAN側からのルーターのWAN IP)-通常、Webベースのポートスキャンサービスを使用することをお勧めします。

      多くのポートスキャンサービスがあります。(ほとんどの人がアクセスを容易にするのではなくブロックしようとしているという考えで、「ファイアウォールを確認する」というフレーズを使用しているものもあります。)これは1つです。あなたはそのいずれかを使用することを選択した場合、クリック進み、テキストボックスに57757を入力し、クリックしてください使用して、指定カスタム・ポートプローブを。実行するには、サーバーを取得する目的のために、あなたがしたい、それがために「オープン。」「クローズ」は、ポートはアクセス可能であるが、サーバーが実行されていないことを意味します(したがって、接続試行は拒否されました)。「ステルス」とは、ポートにアクセスできないことを意味します。あたかもそこにマシンが配置されていないかのように(または、ポートがマシンのない場所に転送されているように)

  5. OK、だからあなたは本当にインターネットからアクセスできないと判断した。詳細を取得するために(理想的にはWAN側から)スキャンできますが、多くの場合、有用な情報は得られません。

    これを行うには、WAN側で次を実行します。

    sudo nmap -sS -sV -p57757 -vv WAN-IP

    ポートがフィルター処理されていると表示される場合、そこに送信されたパケットはおそらくどこにも行かない(または途中でブロック/ドロップされる)ことを確認します。

  6. 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_configOpenSSHサーバーの構成の詳細については、を参照してください。

    ファイルを保存し、テキストエディターを終了し、次のコマンドでSSHサーバーを再起動します。

    sudo restart ssh
    

    次に、ルーターのポートを前方に変更して、ポート57757がOpenSSHサーバーのポート57757(22ではない)に転送され、インターネットからアクセスできるかどうかを確認します。

  7. それでも動作しない場合は、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は最小限です。


1

LAN内から動作するため、サーバーのセットアップは正しいようです。あなたはから転送するようにルータに指示する必要があり、ポートあなたが上で使用する外部のポートにマシンに57757。この場合、
A tracerouteは役に立ちません。


さて、マシン側は大丈夫だと思いました。ええ、57757を22に転送するようにルーターを設定していますが、同じ問題があります。sshd_configもポート22に設定されます。
Ci3

おそらく、「外部で使用するポート(例:57757)をマシンのポート22に」。これは、隠蔽が必要なパブリックポートアドレスです。
david6

この場合は正しくありません-クリスの質問を理解したら
-guntbert
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.