IP-адрес VPS заблокирован [закрыт]
У меня есть VPS на базе Debian, который до недавнего времени работал нормально. Вчера я работал над программированием веб-сайтов, когда сервер просто больше не отвечал. Я провел небольшое исследование и, если коротко, прямо сейчас он реагирует, когда я обращаюсь к нему с адресом ipv6, но не когда я получаю доступ с адресом ipv4. Когда я отслеживаю адрес, я не получаю ответа после сервера хостинговой компании. Я подозревал, что проблема могла быть вызвана моим брандмауэром, поэтому я сбросил IP-таблицы. Это не было решением. Я связался с хостинговой компанией, и они сказали, что не предоставляют техническую поддержку, потому что это самоуправляемый 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
update 2 Я только что обнаружил, что Bcast и Default gw отличаются. (Все еще изучаю ...) route -n приводит к:
[ipaddress] 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Это должно быть по-другому? Как я могу найти то, что мне нужно?
Если на вашем VPS есть консоль управления ,. он может иметь средства для входа в консоль через Интернет. Или, как вы говорите, IPV6 работает, выполните вход в консоль через IPV6.
Рассматривайте это как общее руководство по тестированию настройки сети.
После входа в консоль:
Убедитесь, что интерфейс IPV4 включен и имеет правильный адрес - информация о правильной настройке сети должна быть предоставлена при открытии учетной записи VPS. (команда ifconfig)
Убедитесь, что ваша таблица маршрутизации IPV4 не повреждена и имеет правильный маршрут по умолчанию. (команда маршрута)
Отправьте эхо-запрос на адрес маршрута по умолчанию. (ping)
Ping глобальный адрес 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)
- IPV4-адрес eth0 - 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
. Если все в порядке, игнорируя любые проблемы с брандмауэром, мы сможем связаться с внешними хостами. Любая ошибка в этом случае должна быть вызвана шлюзом по умолчанию и / или сетью восходящего потока от шлюза по умолчанию.