web-dev-qa-db-ja.com

Telnetを実行すると「ホストへのルートがありません」

azureに異なるパブリックIPを持つ2つのVMがあります。

10.10.1.9
10.10.1.6

サーバー10.10.1.6から次のコマンドでtelnetを実行すると、エラーが発生します。

telnet 10.10.1.9 2181
Trying 10.10.1.9...
telnet: connect to address 10.10.1.9: No route to Host

10.10.1.9側でtcpdumpを実行すると、次のログが表示されます。

#tcpdump -i eth0 port 2181
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
07:55:35.530270 IP 10.10.1.6.55910 > 10.10.1.9.eforward: Flags [S], seq 1018543857, win 14600, options [mss 1418,sackOK,TS val 181360935 ecr 0,nop,wscale 7], length 0

同時に10.10.1.6から10.10.1.9にtelnetを実行しながら、10.10.1.6側でtcpdumpも実行します

tcpdump -i eth0 port 2181
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
07:55:57.970696 IP 10.10.1.6.55910 > 10.10.1.9.eforward: Flags [S], seq 1018543857, win 14600, options [mss 1460,sackOK,TS val 181360935 ecr 0,nop,wscale 7], length 0

** ARPを使用した10.10.1.9のtcpdump **

#tcpdump -i eth0 port 2181 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:00:18.356153 IP 10.10.1.6.55944 > 10.10.1.9.eforward: Flags [S], seq 3337054296, win 14600, options [mss 1418,sackOK,TS val 181643770 ecr 0,nop,wscale 7], length 0
08:00:42.294801 ARP, Request who-has 10.10.1.6 tell 10.10.1.9, length 28
08:00:42.295859 ARP, Reply 10.10.1.6 is-at 12:34:56:78:9a:bc (oui Unknown), length 28

tcpdump on 10.10.1.6

tcpdump -i eth0 port 2181 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:00:40.805565 IP 10.10.1.6.55944 > 10.10.1.9.eforward: Flags [S], seq 3337054296, win 14600, options [mss 1460,sackOK,TS val 181643770 ecr 0,nop,wscale 7], length 0
08:00:45.805204 ARP, Request who-has 10.10.1.9 tell 10.10.1.6, length 28
08:00:45.805721 ARP, Reply 10.10.1.9 is-at 12:34:56:78:9a:bc (oui Unknown), length 28
08:02:04.752283 ARP, Request who-has 10.10.1.9 tell 10.10.1.6, length 28
08:02:04.753141 ARP, Reply 10.10.1.9 is-at 12:34:56:78:9a:bc (oui Unknown), length 28

実行のシーケンス:最初に10.10.1.9と10.10.1.10の両方でtcpdumpを実行し、次に10.10.1.10からtelnetを実行してみました。

arp -a on 10.10.1.9

#arp -a
? (10.10.1.7) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.4) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.1) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.8) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.10) at <incomplete> on eth0
? (10.10.1.11) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.6) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.5) at 12:34:56:78:9a:bc [ether] on eth0

arp -a on 10.10.1.6

#arp -a
? (10.10.1.1) at 12:34:56:78:9a:bc [ether] on eth0
? (10.10.1.10) at <incomplete> on eth0
? (10.10.1.9) at 12:34:56:78:9a:bc [ether] on eth0

前もって感謝します。

4
Nilotpal

10.10.1.9のtcpdumpは、10.10.1.10からパケットを受信したと言っています。しかし、返信できませんでした。その結果、10.10.1.10側で「ホストへのルートがありません」と表示されます。

10.10.1.10から10.10.1.9へのルートが実際にない場合、「ホストへのルートなし」を取得する必要があります。10.10.1.10から10.10.1.9から送信されたパケットが送信されなかったからといってnot t返事をもらう。つまり、最初に10.10.1.10が10.10.1.9にパケットを送信できなかった場合にのみ、「ホストへのルートなし」を取得する必要があります。

おそらく、10.10.1.10で実行されているOSは愚かで、最初からSYN + ACKを返さない場合、たとえばETIMEDOUT(「操作がタイムアウトしました」)ではなくEHOSTUNREACH(「ホストへのルートなし」)を返しています。 SYN。

または多分そこにだった 10.10.1.10から10.10.1.9へのルート

23:46:30.003480 IP 10.10.1.10.42946 > 10.10.1.9.eforward: Flags [S], seq 2823099523, win 14600, options [mss 1418,sackOK,TS val 74982205 ecr 0,nop,wscale 7], length 0

パケットは送信されましたが、10.10.1.9はその最初のSYNにSYN + ACKで応答できなかった、または応答しなかったため、10.10.1.10がSYNを再送信すると、パケットを10.10に送信できなくなりました。 1.9、「ホストへのルートがありません」と報告されています。

これが再現可能な場合は、両方ホストでtcpdumpを実行して、何が起こったかの詳細を確認することをお勧めします。私は次のようなコマンドを実行することをお勧めします

tcpdump -i eth0 port 2181 or arp

たとえば、他のホストのARPエントリがホストの1つでタイムアウトになり、その後他のホストのMACアドレスの再ARP試行が失敗したことが問題である場合、それが表示されます。 (ここでは、10.10.1.10と10.10.1.9の間にルーターがないと想定しているため、「ホストへのルートなし」は「ホストのARPエントリがない」ことを意味します。)

(別の可能性としては、ある種の「パケットフィルター」/ファイアウォールがいずれかのホスト上にあり、一部のポートを他とは異なる方法で処理しているため、ポート22への接続は可能ですが、ポート2181への接続は不可能です。)

4
user862787