Probleme mit dem Netzwerk nach Verwendung eines Socks-Proxys

Ich habe mit SSH rumgespielt und versucht, den Datenverkehr über meinen Laptop zu leiten. Am Ende war ich erfolgreich, aber ich scheine mein Netzwerk durcheinander gebracht zu haben. Ich habe nur ssh verwendet und sowohl mit -D- als auch mit -L-Flags herumgespielt. Ich leite Arch.

Ich kann ganz gut mit Chrom browsen, nachdem ich einen socks5-Proxy eingerichtet habe:

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

Wenn ich diesen Socken-Proxy nicht benutze, kann ich nicht stöbern. Und mein Netzwerk scheint keine Verbindungen über irgendeinen Port herstellen zu können (nicht einmal 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

Wenn Sie überprüfen, ob Port 80 verwendet wird, erhalten Sie keine Ergebnisse:

$ sudo fuser 80/tcp

Nur um sicherzugehen, dass mein Socken-Proxy angezeigt wird:

$ sudo fuser 1338/tcp
1338/tcp:           20208

Meine iptables-Konfiguration wurde noch nie berührt:

$ 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 

Ich kann nicht whois:

$ whois google.com
connect: Network is unreachable

Ich kann jedoch pingen:

$ 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

Es gibt nichts, was grep -i http oder grep -i proxy in meiner Umgebung abfängt, und / etc / environment ist leer.

Ich bin völlig verloren. Hat jemand eine Idee, was los ist?

Bearbeiten mit Traceroutes: Die IP-Adresse, die ich durch Pingen von Google erhalte, stammt von meinem ISP.

Ich bin mir nicht sicher, was ich aus diesen Traceroutes lesen soll, die Anfrage scheint nicht weiter zu kommen als mein 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

ICMP-Pakete werden von meinem ISP beantwortet.

$ 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 *

Die IP-Adresse, nach der Sie suchen, google.comgehört nicht zu Google. Dies kann eines von zwei Dingen bedeuten: Entweder wird DNS (möglicherweise vom Internetdienstanbieter) entführt, oder Google hat ein Frontend auf einer IP-Adresse des Internetdienstanbieters implementiert.

Zunächst sollten Sie versuchen, DNS-Lookups verschiedener Domänen über verschiedene DNS-Server durchzuführen, um festzustellen, ob alle Domänen entführt werden oder ob die DNS-Ergebnisse, die Sie erhalten, google.comlegitim sind.

Als nächstes können Sie versuchen, die Ausgabe von zu vergleichen

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

Dies sollte Ihnen sagen, wie weit die Pakete kommen, bevor Sie auf ein Problem stoßen. Das Problem, das Sie sehen, kann nicht darauf zurückzuführen sein, dass Sie nur den von sshIhnen ausgeführten Befehl oder die Änderung der Einstellungen in Chrome ausgeführt haben.

Die Traceroute-Ausgabe zeigt einige interessante Details. Bei der Verfolgung mit ICMP-Echoanforderungspaketen sind die Antworten schnell und das Ziel ist vier Hops entfernt. Beim Tracen mit TCP-Paketen zu Port 80 oder 443 reagiert der erste Hop langsam, die Verzögerung sieht aus wie ein typisches ARP-Timeout.

Was auch immer die Anforderungen blockiert, der Grund dafür ist höchstwahrscheinlich 192.168.1.254der Router, mit dem Ihr Computer verbunden ist.