Problemas com a rede depois de usar um proxy de meias

Question

Eu estava brincando com o SSH e tentando direcionar o tráfego pelo meu laptop. No final, eu consegui, mas parece que eu estraguei minha rede. Eu usei apenas o ssh e brinquei com as flags -D e -L. Eu estou correndo Arch.

Eu posso navegar com o cromo bem depois de configurar a configuração de um proxy socks5:

$ ssh -D 1339 HOST
$ chromium --proxy-server="socks5://localhost:1338"

Se eu não usar esse proxy de meias, não consigo navegar. E minha rede não parece ser capaz de fazer qualquer conexão através de qualquer porta (nem mesmo 1338):

$ telnet google.com 80
Trying 157.157.135.91...
Connection failed: No route to host
Trying 157.157.135.102...
Connection failed: No route to host
Trying 157.157.135.117...
...
Connection failed: No route to host
Trying 2a00:1450:400b:c02::64...
telnet: Unable to connect to remote host: Network is unreachable

Verificar se a porta 80 é usada não produz resultados:

$ sudo fuser 80/tcp

Só para ter certeza de que seria o meu proxy de meias:

$ sudo fuser 1338/tcp
1338/tcp:           20208

Minha configuração do iptables nunca foi tocada:

$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 42955 packets, 14M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 36322 packets, 2196K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Eu não posso whois:

$ whois google.com
connect: Network is unreachable

No entanto, posso fazer ping:

$ ping google.com
PING google.com (157.157.135.123) 56(84) bytes of data.
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=1 ttl=62 time=6.96 ms
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=2 ttl=62 time=6.87 ms
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=3 ttl=62 time=6.66 ms

Não há nada grep -i http ou grep -i proxy está capturando no meu env, e o / etc / environment está vazio.

Estou completamente perdido. Alguém tem alguma ideia do que está acontecendo?

Editar com traceroutes: O endereço IP que recebo do ping do google é do meu provedor.

Não sei ao certo o que ler nesses traceroutes, o requestt parece não ir além do meu gateway:

$ sudo traceroute -n -T -p 80 google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  2083.374 ms  88.990 ms  88.625 ms
 2  192.168.1.254  88.168 ms !H  87.715 ms !H  87.254 ms !H

$ sudo traceroute -n -T -p 443 google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  2006.803 ms  13.076 ms  12.669 ms
 2  192.168.1.254  12.210 ms !H  11.740 ms !H  11.335 ms !H

Os pacotes ICMP são respondidos pelo meu ISP.

$ sudo traceroute -n -I google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  6.263 ms  5.779 ms  5.335 ms
 2  * * *
 3  157.157.135.65  12.034 ms * *
 4  157.157.135.123  12.861 ms  6.706 ms *

    

Answer 1

O endereço IP que você está obtendo para google.com não pertence ao Google. Isso pode significar uma de duas coisas: o DNS está sendo sequestrado (possivelmente pelo ISP) ou o Google tem um front-end implantado em um IP pertencente ao ISP.

Antes de mais nada, você deve tentar pesquisas de DNS de domínios diferentes por meio de diferentes servidores DNS, para ver se estão sendo sequestrados ou se os resultados de DNS obtidos de google.com são legítimos.

Em seguida, você pode tentar comparar a saída de

• traceroute -n -T -p 443 google.com
• traceroute -n -T -p 80 google.com
• traceroute -n -I google.com

Isso deve informar até onde os pacotes estão chegando antes de você se deparar com um problema. O problema que você está vendo não pode ter sido causado apenas pela execução do comando ssh que você estava executando ou pela alteração das configurações no Chrome.

A saída do traceroute mostra alguns detalhes interessantes. Ao rastrear com pacotes de solicitação de eco ICMP, as respostas são rápidas e o destino está a quatro saltos de distância. Ao rastrear com pacotes TCP para a porta 80 ou 443, o primeiro salto responde lentamente, o atraso se parece com um tempo limite ARP típico.

Qualquer que seja o bloqueio das solicitações, o motivo provavelmente está em 192.168.1.254 , que é o roteador ao qual seu computador está conectado.