Проблемы с сетью после использования SOCKS прокси

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

Я могу просматривать с хромом просто отлично после установки настроив SOCKS5 прокси:

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

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

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

$ 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 нет ничего, что перехватывал бы http grep-i или grep-i прокси, и/etc / environment пусто.

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

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

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

$ 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 *
25
задан eythor
14.12.2022 7:57 Количество просмотров материала 3178
Распечатать страницу

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, что маршрутизатор ваш компьютер подключен.

1
отвечен kasperd 2022-12-15 15:45

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх