Eu tenho um VPS baseado em Debian que funcionou bem até recentemente. Ontem, eu estava trabalhando na programação de sites quando o servidor simplesmente não respondia mais. Fiz algumas pesquisas e, para ser breve, no momento ele responde quando acesso com o endereço ipv6, mas não quando acesso com o endereço ipv4. Quando faço o pingtrace do endereço, não recebo resposta após o servidor da empresa de hospedagem. Suspeitei que meu firewall pudesse ter causado o problema, então limpei o IPtables. Essa não foi a solução. Entrei em contato com a empresa de hospedagem e eles disseram que não dão suporte técnico porque é um VPS autogerenciado. Espero que o problema não esteja no servidor deles.
Alguém pode pensar em algo que eu não vi?
Atualizar ifconfig tem o endereço ipv4 e o endereço ipv6 em eht0, então tudo bem. E consigo me conectar ao ipv6. Quando paro o iptables, ainda não consigo fazer ping. Eu tenho o CSF rodando no Webmin. Quando faço service csf stop e service lfd stop, meu 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
Além disso, quando faço ping para google.com a partir do meu vps, recebo
host desconhecido www.google.com
atualização 2 Acabei de descobrir que Bcast e Default gw são diferentes. (Ainda aprendendo...) route -n resulta em:
[ipaddress] 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Isso deveria ser diferente? Como posso descobrir o que preciso?
Responder1
Se o seu VPS possui um console de gerenciamento. pode haver um meio de realizar um login no console pela web. Ou, como você diz que o IPV6 funciona, faça um login no console pelo IPV6.
Trate isso como um guia genérico de teste de configuração de rede.
Depois de fazer login no console:
Verifique se a interface IPV4 está ativa e tem o endereço correto - as informações sobre a configuração correta da rede deveriam ter sido fornecidas na abertura da conta VPS. (comando ifconfig)
Verifique se sua tabela de roteamento IPV4 está intacta e possui uma rota padrão correta. (comando de rota)
Faça ping no endereço da rota padrão. (ping)
Faça ping em um endereço IPV4 global (ping www.google.com)
R. Se (3) funcionar, mas não (4), o problema está na rede dos seus provedores VPS. Dê a eles as informações acima. Se eles não responderem ou não quiserem responder, mude de fornecedor - posso recomendar o Afterburst, pois eles são muito bons em responder dúvidas e têm baixo custo.
B. Se (3) não funcionar, verifique seu firewall (desative-o temporariamente). Verifique também a rota padrão com o provedor VPS. Se desabilitar o firewall faz com que ele funcione, então esse é o seu problema.
C. Se (4) funcionar, o problema não está no seu VPS, mas na sua rede local - esse é o seu problema.
Comandos de exemplo
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
Isso nos diz:
- eth0 IPV4 é globalmente roteável (não é um endereço RFC1918)
- o endereço eth0 IPV4 é 55.135.9.135 com uma máscara de sub-rede de 26 bits (255.255.255.192)
- o endereço de transmissão eth0 é 55.135.9.191
- O gateway padrão é 55.135 .9.129, é para lá que enviamos tudo o que não é coberto por nenhuma outra rota.
Nós logicamente E os IPs de dispositivos conhecidos com a máscara de sub-rede, vemos que ele está na mesma sub-rede que nós, por exemplo
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 o resultado é o mesmo, deveremos ser capazes de acessá-lo diretamente, já que o gateway padrão normalmente é acessível diretamente na sub-rede local.
Então, se fizermos ping no gateway, deveremos vê-lo.
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
Se isso funcionar, devemos ver o endereço de hardware do nosso gateway na lista arp
user@srv0:~$ sudo arp -a
? (55.135.9.129) at 00:21:59:cd:6a:48 [ether] on eth0
Se tudo estiver bem, ignorando quaisquer problemas de firewall, poderemos entrar em contato com hosts externos. Qualquer falha ao fazer isso deve ser causada pelo gateway padrão e/ou pela rede upsream do gateway padrão.