☰

IP-адрес VPS заблокирован

tag-icon • tag-icon debian iptables vps ipv6 ipv4
IP-адрес VPS заблокирован

У меня есть VPS на базе Debian, который работал нормально до недавнего времени. Вчера я работал над программированием веб-сайтов, когда сервер просто перестал отвечать. Я провел небольшое исследование, и, если говорить кратко, сейчас он отвечает, когда я захожу на него с адреса ipv6, но не с адреса ipv4. Когда я pingtrace адреса, я не получаю ответа после сервера хостинговой компании. Я подозревал, что мой брандмауэр мог вызвать проблему, поэтому я очистил IPtables. Это не было решением. Я связался с хостинговой компанией, и они сказали, что они не оказывают техническую поддержку, потому что это самоуправляемый VPS. Я надеюсь, что проблема не в их сервере.

Может ли кто-нибудь вспомнить что-то, чего я не увидел?

Обновлять ifconfig имеет адрес ipv4 и адрес ipv6 в eht0, так что все должно быть в порядке. И я могу подключиться к ipv6. Когда я останавливаю iptables, я все еще не могу пинговать. У меня CSF работает в Webmin. Когда я делаю 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

Кроме того, когда я пингую google.com с моего vps, я получаю

неизвестный хост 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 не повреждена и имеет правильный маршрут по умолчанию. (команда route)

  3. Выполните ping-тест адреса маршрута по умолчанию. (ping )

  4. Проверьте связь с глобальным адресом IPV4 (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 - 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

Поскольку результат тот же, мы должны иметь возможность получить к нему прямой доступ, поскольку шлюз по умолчанию обычно напрямую доступен в локальной подсети.

Итак, если мы пропингуем шлюз, мы должны его увидеть.

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

Если все хорошо, то, игнорируя любые проблемы с брандмауэром, мы должны иметь возможность связаться с внешними хостами. Любая неудача в этом должна быть вызвана шлюзом по умолчанию и/или сетью upsream от шлюза по умолчанию.

Связанный контент