Я играл с SSH и пытался направить трафик через мой ноутбук. В конце концов, мне это удалось, но, похоже, я испортил свою сеть. Я использовал только ssh и поиграл с флагами -D и -L. Я бегу Arch.

После настройки, настроив прокси socks5, я могу легко просматривать хром.

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

Если я не использую этот прокси-носки, я не могу просматривать. И моя сеть, похоже, не может устанавливать какие-либо соединения через любой порт (даже 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

Проверка, используется ли порт 80, не дает результатов:

$ sudo fuser 80/tcp

Просто чтобы убедиться, что он будет видеть мой прокси-носок:

$ sudo fuser 1338/tcp
1338/tcp:           20208

Моя конфигурация iptables никогда не менялась:

$ 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

Я не могу whois:

$ whois google.com
connect: Network is unreachable

Тем не менее, я могу пинговать:

$ 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

В моем env нет ничего, что grep -i http или grep -i proxy ловит, а /etc /environment пуст.

Я полностью потерян. Кто-нибудь знает, что происходит?

Редактирование с помощью traceroutes: IP-адрес, который я получаю от pinging google, получен от моего провайдера.

Я не уверен, что читать из этих traceroutes, запрос, кажется, не идет дальше, чем мой шлюз:

$ 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

На пакеты ICMP отвечает мой провайдер.

$ 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 *
|источник

1 ответ1

1

IP-адрес, который вы получаете для google.com , не принадлежит Google. Это может означать одно из двух: либо взлом DNS (возможно, интернет-провайдером), либо Google использует внешний интерфейс, размещенный на IP-адресе, принадлежащем провайдеру.

Прежде всего вы должны попробовать поиск DNS для разных доменов через разные DNS-серверы, чтобы проверить, не были ли они все захвачены или результаты DNS, полученные с google.com являются законными.

Далее вы можете попробовать сравнить вывод

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

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

Вывод traceroute показывает несколько интересных деталей. При трассировке с помощью пакетов эхо-запросов ICMP ответы бывают быстрыми, а цель находится в четырех шагах. При трассировке TCP-пакетов на порт 80 или 443 первый прыжок реагирует медленно, задержка выглядит как типичное время ожидания ARP.

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .