☰

VPS IP位址被封鎖

tag-icon • tag-icon debian iptables vps ipv6 ipv4
VPS IP位址被封鎖

我有一個基於 Debian 的 VPS，直到最近都運作良好。昨天，我正在編程網站時，伺服器不再回應。我做了一些研究，簡而言之，現在當我使用 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 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 有管理控制台。它可能有一種透過網路執行控制台登入的方法。或者，正如您所說，IPV6 有效，透過 IPV6 執行控制台登入。

將其視為通用網路設定測試指南。

登入控制台後：

  1. 驗證 IPV4 介面已啟動並具有正確的位址 - 在開啟 VPS 帳戶時應提供有關正確網路設定的資訊。 （ifconfig指令）

  2. 驗證您的 IPV4 路由表是否完整，因為它具有正確的預設路由。 （路線命令）

  3. 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 廣播位址是 5.135
.是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

如果一切順利，那麼忽略任何防火牆問題我們應該能夠聯絡外部主機。任何未能執行此操作的情況都必須是由預設網關和/或預設網關的上行網路引起的。

相關內容