☰

VPS IP 地址被阻止

tag-icon • tag-icon debian iptables vps ipv6 ipv4
VPS IP 地址被阻止

我有一个基于 Debian 的 VPS，直到最近它都运行良好。昨天，我在编程网站上工作时，服务器突然不再响应。我做了一些研究，简而言之，现在当我使用 ipv6 地址访问它时，它确实有响应，但当我使用 ipv4 地址访问时，它没有响应。当我 ping 跟踪该地址时，在托管公司的服务器之后我没有得到响应。我怀疑我的防火墙可能导致了这个问题，所以我刷新了 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 ping 到 google.com 时，我得到了

未知主机 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 执行控制台登录。

将其视为通用网络设置测试指南。

一旦您有了控制台登录：

  1. 验证 IPV4 接口已启动且具有正确的地址 - 在打开 VPS 帐户时应该提供有关正确网络设置的信息。（ifconfig 命令）

  2. 验证您的 IPV4 路由表是否完整，是否具有正确的默认路由。（路由命令）

  3. Ping 默认路由的地址。(ping)

  4. Ping 全球 IPV4 地址（ping www.google.com）

答：如果 (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 地址是 55.135.9.135，带有 26 位子网掩码（255.255.255.192）
- eth0 广播地址是 55.135.9.191
- 默认网关是 55.135.9.129，这是我们发送任何其他路由未覆盖的内容的地方。

我们对已知设备 IP 与子网掩码进行逻辑与运算，发现它与我们位于同一子网，例如

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

如果一切正常，那么忽略任何防火墙问题，我们应该能够联系外部主机。任何无法做到这一点的原因一定是默认网关和/或默认网关的上行网络。

相关内容