私は最近まで問題なく動作していた Debian ベースの VPS を持っています。昨日、プログラミング Web サイトで作業していたところ、サーバーが応答しなくなりました。調査したところ、簡単に言うと、現在、IPv6 アドレスでアクセスすると応答しますが、IPv4 アドレスでアクセスすると応答しません。アドレスを pingtrace すると、ホスティング会社のサーバーの後に応答がありません。ファイアウォールが問題の原因である可能性があると疑ったため、IPtables をフラッシュしました。しかし、解決には至りませんでした。ホスティング会社に連絡したところ、自己管理型 VPS であるため、テクニカル サポートは提供していないとのことでした。問題が彼らのサーバーで発生していないことを願っています。
誰か私が気づかなかった何かを思いつくことができますか?
アップデート ifconfig には eht0 に ipv4 アドレスと ipv6 アドレスがあるので、問題ないはずです。また、ipv6 に接続できます。iptables を停止しても、ping は実行できません。Webmin で CSF を実行しています。service csf stop と service lfd stop を実行すると、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
また、VPSからgoogle.comにpingすると、
不明なホスト www.google.com
アップデート2 Bcast と Default gw が異なることを発見しました。(まだ学習中です...) route -n の結果は次のようになります:
[ipaddress] 0.0.0.0 255.255.255.0 U 0 0 0 eth0
それは違うのでしょうか? 必要なものをどうやって見つければいいのでしょうか?
答え1
VPS に管理コンソールがある場合は、Web 経由でコンソール ログインを実行する手段がある可能性があります。または、IPV6 が機能するとおっしゃっているように、IPV6 経由でコンソール ログインを実行します。
これを一般的なネットワーク設定テスト ガイドとして扱ってください。
コンソールにログインしたら:
IPV4 インターフェイスが稼働しており、正しいアドレスが割り当てられていることを確認します。正しいネットワーク設定に関する情報は、VPS アカウントを開設したときに提供されるはずです。(ifconfig コマンド)
IPV4 ルーティング テーブルに正しいデフォルト ルートが設定されており、問題がないことを確認します。(route コマンド)
デフォルトルートのアドレスをpingします。(ping)
グローバル IPV4 アドレスに ping を実行します (ping www.google.com)
A. (3) は機能するが (4) は機能しない場合は、VPS プロバイダーのネットワークに問題があります。上記の情報をプロバイダーに伝えてください。回答がなかったり、回答しない場合は、プロバイダーを変更してください。Afterburst は問い合わせへの回答が非常に優れており、コストも低いため、お勧めです。
B. (3) が機能しない場合は、ファイアウォールを確認してください (一時的に無効にします)。また、VPS プロバイダーのデフォルト ルートも確認してください。ファイアウォールを無効にすると機能するようになった場合は、それが問題です。
C. (4) が機能する場合、問題は VPS ではなくローカル ネットワークにあります。これが問題です。
コマンド例
user@srv0:~$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3c:a8:3f:bd
inet addr:55.135.9.135 Bcast:55.135.9.191 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:63541656 errors:0 dropped:0 overruns:0 frame:0
TX packets:54202238 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:28787095338 (28.7 GB) TX bytes:144380431303 (144.3 GB)
user@srv0:~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 55.135.9.129 0.0.0.0 UG 0 0 0 eth0
55.135.9.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0
これは次のことを示しています:
- eth0 IPV4 はグローバルにルーティング可能です (RFC1918 アドレスではありません)
- eth0 IPV4 アドレスは 26 ビットのサブネット マスク (255.255.255.192) を持つ 55.135.9.135 です
- eth0 ブロードキャスト アドレスは 55.135.9.191 です
- デフォルト ゲートウェイは 55.135.9.129 です。これは、他のルートでカバーされていないものを送信する場所です。
既知のデバイスのIPとサブネットマスクを論理的にANDすると、それが私たちと同じサブネット上にあることがわかります。例：
055.135.009.135 (eth0 address)
255.255.255.192 (subnet mask)
----------------AND
055.135.009.128
055.135.009.129 (gw address)
255.255.255.192 (subnet mask)
----------------AND
055.135.009.128
結果は同じなので、デフォルト ゲートウェイは通常、ローカル サブネット上で直接アクセス可能なので、直接アクセスできるはずです。
したがって、ゲートウェイを ping すると、それが表示されるはずです。
user@srv0:~$ sudo ping 55.135.9.135
PING 55.135.9.135 (55.135.9.135) 56(84) bytes of data.
64 bytes from 55.135.9.135: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from 55.135.9.135: icmp_seq=2 ttl=64 time=0.026 ms
64 bytes from 55.135.9.135: icmp_seq=3 ttl=64 time=0.026 ms
^C
--- 55.135.9.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.024/0.028/0.036/0.004 ms
これがうまくいけば、ARPリストにゲートウェイのハードウェアアドレスが表示されるはずです。
user@srv0:~$ sudo arp -a
? (55.135.9.129) at 00:21:59:cd:6a:48 [ether] on eth0
すべてが正常であれば、ファイアウォールの問題を無視すれば、外部ホストに接続できるはずです。これができない場合は、デフォルト ゲートウェイまたはデフォルト ゲートウェイからのアップストリーム ネットワークが原因である必要があります。