Tengo un VPS basado en Debian que funcionó bien hasta hace poco. Ayer estaba trabajando programando sitios web cuando el servidor ya no respondió. He investigado un poco y, para ser breve, en este momento responde cuando accedo con la dirección ipv6 pero no cuando accedo con la dirección ipv4. Cuando rastreo la dirección, no obtengo respuesta después del servidor de la empresa de alojamiento. Sospeché que mi firewall podría haber causado el problema, así que eliminé IPtables. Esa no fue la solución. Me comuniqué con la empresa de hosting y me dijeron que no dan soporte técnico porque es un VPS autoadministrable. Espero que el problema no esté en su servidor.
¿Alguien puede pensar en algo que no vi?
Actualizar ifconfig tiene la dirección ipv4 y la dirección ipv6 en eht0, por lo que debería estar bien. Y puedo conectarme a ipv6. Cuando detengo iptables, todavía no puedo hacer ping. Tengo CSF ejecutándose en Webmin. Cuando realizo el servicio csf stop y el servicio lfd stop, mi iptables -L es:
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
Además, cuando hago ping a google.com desde mi vps, aparece
host desconocido www.google.com
actualización 2 Acabo de descubrir que Bcast y Default gw son diferentes. (Aún estoy aprendiendo...) route -n da como resultado:
[ipaddress] 0.0.0.0 255.255.255.0 U 0 0 0 eth0
¿Debería ser diferente? ¿Cómo puedo descubrir lo que necesito?
Respuesta1
Si su VPS tiene una consola de administración. puede tener un medio para realizar un inicio de sesión en la consola a través de la web. O, como usted dice que IPV6 funciona, inicie sesión en la consola a través de IPV6.
Trate esto como una guía de prueba de configuración de red genérica.
Una vez que haya iniciado sesión en la consola:
Verifique que la interfaz IPV4 esté activa y tenga la dirección correcta; se debería haber proporcionado información sobre la configuración correcta de la red al abrir la cuenta VPS. (comando ifconfig)
Verifique que su tabla de enrutamiento IPV4 esté intacta y que tenga una ruta predeterminada correcta. (comando de ruta)
Haga ping a la dirección de la ruta predeterminada. (ping)
Haga ping a una dirección IPV4 global (ping www.google.com)
R. Si (3) funciona pero no (4), el problema está en la red de sus proveedores de VPS. Dales la información anterior. Si no responden o no quieren responder, cambie de proveedor. Puedo recomendar Afterburst ya que son muy buenos respondiendo consultas y tienen un bajo costo.
B. Si (3) no funciona, mire su firewall (desactívelo temporalmente). Verifique también la ruta predeterminada con el proveedor de VPS. Si deshabilitar el firewall hace que funcione, entonces ese es tu problema.
C. Si (4) funciona, entonces el problema no está en su VPS sino en su red local; ahí está el problema.
Comandos de ejemplo
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
Esto nos dice:
- eth0 IPV4 es enrutable globalmente (no es una dirección RFC1918)
- la dirección eth0 IPV4 es 55.135.9.135 con una máscara de subred de 26 bits (255.255.255.192)
- la dirección de transmisión eth0 es 55.135.9.191
- La puerta de enlace predeterminada es 55.135 .9.129, aquí enviamos todo lo que no esté cubierto por ninguna otra vía.
Lógicamente Y las IP del dispositivo conocido con la máscara de subred vemos que está en la misma subred que nosotros, por ejemplo
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
Como el resultado es el mismo, deberíamos poder acceder a él directamente, ya que normalmente se puede acceder directamente a la puerta de enlace predeterminada en la subred local.
Entonces, si hacemos ping a la pasarela deberíamos verlo.
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
Si esto funciona, deberíamos ver la dirección de hardware de nuestra puerta de enlace en la lista de arp.
user@srv0:~$ sudo arp -a
? (55.135.9.129) at 00:21:59:cd:6a:48 [ether] on eth0
Si todo está bien, ignorando cualquier problema de firewall deberíamos poder contactar con hosts externos. Cualquier falla al hacer esto debe ser causada por la puerta de enlace predeterminada y/o la red ascendente de la puerta de enlace predeterminada.