このシナリオには3つのマシンがあります。
すべてのマシンにUbuntu 11.04(デスクトップAは64ビット)があり、openssh-serverとopenssh-clientの両方があります。
ssh [email protected]
でデスクトップAをラップトップAに接続しようとすると、エラーが発生します。
port 22: No route to Host
両方の場合。
私は両方のマシンを所有していますが、友人のマシンから同じコマンドを実行すると、つまりデスクトップBを介して、ラップトップとデスクトップの両方にアクセスできます。しかし、ラップトップまたはデスクトップからデスクトップBにアクセスしようとすると、
port 22: Connection timed out
私もsshポート番号を変更しようとしました。 ssh_config
ファイルにありますが、成功していません。
注:「ラップトップA」はWiFi接続を使用し、「マシンA」はイーサネット接続を使用し、「マシンB」はまったく異なるネットワーク上にあります。
@ Lekensteynここにあります->
ラップトップA &&デスクトップA-> ISPから提供されたルーター/ Nano_Rcvr。そのため、1台のルーターに2台のマシンが接続され、同時にアクセスできます。両方のマシンのifconfig出力を次に示します。Laptop
wlan0
Link encap:Ethernet HWaddr X:X:X:X:00:bc
inet addr:1.23.73.111 Bcast:1.23.95.255 Mask:255.255.224.0
inet6 addr: fe80::219:e3ff:fe04:bc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:108409 errors:0 dropped:0 overruns:0 frame:0
TX packets:82523 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44974080 (44.9 MB) TX bytes:22973031 (22.9 MB)
デスクトップ
eth0
Link encap:Ethernet HWaddr X:X:X:X:c5:78
inet addr:1.23.68.209 Bcast:1.23.95.255 Mask:255.255.224.0
inet6 addr: fe80::227:eff:fe04:c578/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10380 errors:0 dropped:0 overruns:0 frame:0
TX packets:4509 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1790366 (1.7 MB) TX bytes:852877 (852.8 KB)
Interrupt:43 Base address:0x2000
の出力ip route show
1.23.64.0/19 dev wlan0 proto kernel scope link src 1.23.73.111 metric 2
169.254.0.0/16 dev wlan0 scope link metric 1000
の出力traceroute -n 1.23.73.111
traceroute to 1.23.73.111 (1.23.73.111), 30 Hops max, 60 byte packets
1 1.23.68.209 3008.787 ms !H 3008.786 ms !H 3008.784 ms !H
ルートは正常に見えます。これらのIPアドレスはプライベート(LAN)であり、パブリックにアクセスできないと仮定します。
ネットワーク(wifi /有線)にさまざまな方法で接続しているため、ルーターが有線/無線ネットワークを分離している可能性が非常に高くなります。両方を有線(または無線)接続で接続してみてください。もう1つの可能性は、Ubuntuマシンのファイアウォールが接続をブロックしていることです。
それ以外の場合は、無線接続と有線接続に同じネットワーク(サブネット)を使用するようにルーターを構成します。また、ルーターがクライアント間の通信をブロックしないようにしてください。
ルーターがすべての未承諾パケットをドロップしている可能性があるため、友人はパブリックIPアドレスで「接続がタイムアウトしました」というメッセージを受け取ります。パブリックIPアドレスとポートの組み合わせがLANアドレスに転送されるように、NATポート転送を構成します。
ネットワーク例:
YOUR NETWORK (A)
Router A (public address: 198.51.100.1)
Desktop A - 10.0.0.2
Laptop A - 10.0.0.3
YOUR FRIENDS NETWORK (B)
Router B (public address: 203.0.113.1)
Machine B - 192.168.0.2
ルーターAで、NAT転送のセットアップ:
To make your desktop accessible:
forward the public port 22 to 10.0.0.2
To make your laptop accessible:
forward the public port 2222 to 10.0.0.3
マシンセットにファイアウォール(ufw
、iptables
、...)がある場合、ポート22(デスクトップA)とポート2222(ラップトップA)への着信トラフィックを許可します。
これで、SSHを使用してデスクトップにアクセスできます。
ssh [email protected] -p 22
これで、SSHを使用してラップトップにアクセスできます。
ssh [email protected] -p 2222
友達のマシンにアクセスしたい場合は、これらの指示を彼のマシン+ルーターに適用してください。
同様の問題がありました。有線と無線の1台のマシン。 「lanとwlanのipsを分ける」以外に、ルーターにチェックボックスを見つけて、チェックを外しました。これで、wirelesコンピュータにログインできます。その前に、「ホストへのルートがありません」というエラーメッセージが表示されました。
私は今、vpsで同じ問題を自分で手に入れました。
私は経験豊富なサーバー管理者であり、この種のエラーは通常は断ち切ります。
ホストへのルートがないということは、サーバーがパケットのルーティング方法を知らないことを意味します(ルーティングテーブル。ただし、あるプロトコルでのみ発生し、別のプロトコルでは発生しません)。
私の場合。
いいえNATインターネット接続。 IPTABLEのPingが機能しない壊れたIPの両側のIPに接続できます。壊れたIPは、どのTCPポートでも「ホストへのルートなし」と表示されます。
これは、途中で何かがエラーコードを返しているか、ルーティングテーブルを使用してOSのバグを返していることを示しています。
エラーは即時であり、遅延ではなく、拒否がローカルであることを意味します。しかし、診断できるのはそれだけです。
root@vps1 network # telnet 83.149.xx.xx 23
Trying 83.149.xx.xx...
telnet: Unable to connect to remote Host: No route to Host
root@vps1 network # telnet 83.149.xx.xx 80
Trying 83.149.xx.xx...
telnet: Unable to connect to remote Host: No route to Host
root@vps1 network # ping 83.149.xx.xx
PING 83.149.xx.xx (83.149.xx.xx) 56(84) bytes of data.
64 bytes from 83.149.xx.xx: icmp_seq=1 ttl=56 time=8.89 ms
64 bytes from 83.149.xx.xx: icmp_seq=2 ttl=56 time=7.93 ms
RHELのインストール中にsshチェックボックスをオンにします。私はそれをチェックせず、同じ問題を引き起こしました。そのパラメーターを確認してください
私の場合、VPNと同じCIDRにDockerネットワークがありました。
次のコマンドを使用して、どのネットワークを把握してから削除しました。
docker inspect $(docker network ls -q) | jq '.[] | {name: .Name, cidr: .IPAM.Config[0].Subnet}'
その後、うまくいきました。
PCとRaspberry Piの間でSSHを正常に実行した後でも、奇妙なことにこのエラーが発生します。私にとってそれを修正するのは、wifiのオンとオフ(クライアントとホストの両方)、端末の再起動、新しいIPアドレスの使用です。