インターネット(SSHまたはRDPの試み)を介してリモートでルーターのコンピュータにアクセスできないのはなぜですか?

インターネット(SSHまたはRDPの試み)を介してリモートでルーターのコンピュータにアクセスできないのはなぜですか?

これは私の最初の投稿なので、建設的な批判を歓迎します。

ターゲットマシンuname -a(NAS自体):

Linux nas 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux

リモートコンピュータuname -a(NASにアクセスしたいコンピュータ):

Linux tilly 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

このドキュメント全体では、次のエイリアスが使用されます。

ローカルIPv4- ルータが割り当てたNASローカルipv4アドレス(192.168.XX)。

ローカルIPv4- 同じルーターに接続されているWindowsシステム(リモートデスクトップ接続を許可)のローカルipv4アドレスは、RDP(192.168.XX)をテストするために使用するシステムです。

公開IPv4- ルータのパブリックIPv4アドレス

NASファイルサーバーを設定していますが、インターネット経由でシステムをシェルするのに問題があります。これはSSHを使用した最初のロデオではありません。一人で修正しようと多くの時間を費やしましたが、失敗しました。

ローカル、つまりターゲットssh localhostコンピュータでうまく機能します。同様にssh LocalIPv4、同じネットワーク上のコンピュータも正常に動作します。私はDebianファイアウォール(ufw)を使った経験がほとんどなく、私が知っている限りデフォルトのままです(下記の出力を参照iptables -L)。

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

ルータのPublicIPv4に対してpingを実行すると、次のような結果が得られます。

PING PublicIPv4 (PublicIPv4) 56(84) bytes of data.
64 bytes from PublicIPv4: icmp_seq=1 ttl=63 time=5.08 ms
64 bytes from PublicIPv4: icmp_seq=2 ttl=63 time=3.59 ms
64 bytes from PublicIPv4: icmp_seq=3 ttl=63 time=11.4 ms
64 bytes from PublicIPv4: icmp_seq=4 ttl=63 time=13.6 ms
^C
--- PublicIPv4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.589/8.424/13.592/4.194 ms

ポート 22 は、ルータの設定から正しいコンピュータに転送されます。出力は次のとおりですssh -vvv PublicIPv4

OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname PublicIPv4 is address
debug2: ssh_connect_direct
debug1: Connecting to PublicIPv4 [PublicIPv4] port 22.
note from op: Hangs here with no timeout; I have to Ctrl+C out.

出力は次のとおりですnetstat -tlpn | grep 22

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      17420/sshd          
tcp6       0      0 :::22                   :::*                    LISTEN      17420/sshd

特定のポートをブロックするISPの問題であることを知って、2222ポートに切り替えてみました。このポートを使用すると、ssh localhost -p 2222ターゲットコンピュータとネットワークコンピュータの両方でssh LocalIPv4 -p 2222すべてが正常に動作します。ただし、実行しても同じ問題が発生しますssh -vvv PublicIPv4 -p 2222

また、デフォルト設定でもあるルータのファイアウォールを完全に無効にしようとしましたが、ポート22をブロックする理由は不明です。奇妙なリバースDNSルックアップ問題の言及を聞いて、/etc/hosts両方のシステムにホストルールを追加しようとしましたが、役に立ちませんでした。

必死に、RDPを使用してネットワーク接続されたWindowsコンピュータにアクセスしてみました。私はrdesktop WinLocalIPv4それを使ってうまくいきましたが、適切なポートを渡した後も同様のデバッグ出力ラインrdesktop PublicIPv4で停止しました。Connecting to . . .

私は私が知っているすべてのオプションと、この交換で見た他のオプションの両方を使い果たしました。トラブルシューティング/診断をよりよく理解するために追加情報が必要な場合は、お気軽にお知らせします。時間をいただきありがとうございます。

編集する:

というサービスを使用した後盾を立てろ!、私が開いたポートが「ステルスモード」で実行されていると報告します。ルータのすべての明白なセキュリティ機能を一時的に無効にした後も、サービスは依然としてこれらのポートを「tcpパケット用ブラックホール」として報告しています。私はそれが問題であると確信していますが、今問題は実際にこのポートをどのように開くことができるかということです。セキュリティ機能とポート転送を無効にしても、これには効果がないようです。新しい質問をしようとしていますが、このプラットフォームが私にとって新しいものであるかどうかは完全にはわかりません。これに対するどんな提案にも感謝します。

編集2:

私のルーターで接続ロギングを有効にし、ポート0-1023に対してプローブを実行した後、盾を立てろ!、私のネットワークの接続ログには着信接続がまったくないと報告されます。ログが稼働中です。出てくるhttpsトラフィックがたくさんあります。これが問題のようですが、この動作を停止する方法がわかりません。この質問はどこに投稿する必要がありますか?

ベストアンサー1

これは答えよりもコメントに近いです。

次のコマンドを使用して、ルータがLAN内のコンピュータにポートを正しく転送することをテストできます。盾を立てろ!

ルータでポート 22 を開いたり転送したりしないことをお勧めします。ポート22に無差別代入を試みる人/ボットネットがたくさんあります。ルータのインターネットSSHポートはポート1024より高くなります。良いルーターを使用すると、あるポートを別の宛先ポートにマッピングできます。 (たとえば、ルーターのインターネットポート9876をSSHサーバーのポート22にマップします。)人々はまだパブリックIPで開いているポートをポートスキャンできますが、65535ポート範囲全体をスキャンするのではなく、パブリックエントリポイントのみを探している可能性があります。 。

また、以下を実行します。失敗2禁止SSHサーバーから。 LAN SSH サーバーのあるポートを変更する場合は、デフォルトでポート 22 をモニターするので、どのポートをモニターするかを教えてください。

1日間Fail2banを実行した後、ログを確認してください。あなたのコンピュータに侵入しようとしているので、多くのIPが禁止されていることがわかります。

編集する:

私が使用しているルータで見つけた1つの注意点は...単一ポート転送が私のルータで機能しないようです。しかし、私はそれを機能させるために別のアプローチを使用しました。一連のポートを転送しました...開始ポートと終了ポートは同じポート番号で動作しました。

また必ずお読みください私の答えエマルジョン。

編集する:

無差別パスワードクラッキングを防ぐには、次のガイドラインを使用して設定してください。SSH公開鍵認証

これを完了したら、公開鍵を使用してrootとしてログインできることをテストし、SSH公開鍵を使用してrootとしてのみログインできるようにrootパスワードログインを無効にするようにsshd設定を変更します。この方法では、SSH公開鍵を使用して標準ユーザーとしてログインすることもできます。

または、root または sudo を使用して、次のコマンドを使用して標準ユーザー アカウントをロックします。

usermod -L username

これにより、このユーザーのパスワードログインが無効になります。ただし、SSH公開鍵を使用してログインすることはできます。

注:上記のコマンドをリモートで使用する場合新しいシェルを開きます。サーバーに移動してログイン機能をテストします。これにより、問題が発生してログインできない場合は、すでに別のシェルにログインしているため、問題を解決できます。

パスワードでログインする機能を削除する前に、SSH公開鍵を使用してアカウントにログインできることをテストしてください。

おすすめ記事