Ich habe einen Debian-basierten VPS, der bis vor kurzem einwandfrei lief. Gestern habe ich an der Programmierung von Websites gearbeitet, als der Server einfach nicht mehr reagierte. Ich habe einige Nachforschungen angestellt und um es kurz zu machen: Im Moment reagiert er, wenn ich mit der IPv6-Adresse darauf zugreife, aber nicht, wenn ich mit der IPv4-Adresse darauf zugreife. Wenn ich die Adresse pingtrace, erhalte ich nach dem Server des Hosting-Unternehmens keine Antwort. Ich vermutete, dass meine Firewall das Problem verursacht haben könnte, also habe ich die IPtables geleert. Das war nicht die Lösung. Ich habe das Hosting-Unternehmen kontaktiert und sie sagten, dass sie keinen technischen Support bieten, da es sich um einen selbstverwalteten VPS handelt. Ich hoffe, das Problem liegt nicht an ihrem Server.
Fällt jemandem etwas ein, das ich nicht gesehen habe?
Aktualisieren ifconfig hat die IPv4-Adresse und die IPv6-Adresse in eht0, also sollte das in Ordnung sein. Und ich kann eine Verbindung zu IPv6 herstellen. Wenn ich iptables stoppe, kann ich immer noch keinen Ping senden. Ich habe CSF in Webmin laufen. Wenn ich service csf stop und service lfd stop mache, lautet mein 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
Wenn ich von meinem VPS aus einen Ping an google.com sende, erhalte ich
unbekannter Host www.google.com
Aktualisierung 2 Ich habe gerade festgestellt, dass Bcast und Default gw unterschiedlich sind. (Lerne immer noch...) route -n ergibt:
[ipaddress] 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Sollte das anders sein? Wie kann ich herausfinden, was ich brauche?
Antwort1
Wenn Ihr VPS über eine Verwaltungskonsole verfügt, kann er möglicherweise eine Konsolenanmeldung über das Internet durchführen. Oder führen Sie, wie Sie sagen, IPV6 funktioniert, eine Konsolenanmeldung über IPV6 durch.
Betrachten Sie dies als allgemeine Testanleitung zur Netzwerkeinrichtung.
Sobald Sie sich über eine Konsolenanmeldung verfügen:
Überprüfen Sie, ob die IPV4-Schnittstelle aktiv ist und über die richtige Adresse verfügt. Informationen zur korrekten Netzwerkeinrichtung sollten beim Öffnen des VPS-Kontos bereitgestellt worden sein. (Befehl „ifconfig“)
Stellen Sie sicher, dass Ihre IPV4-Routingtabelle intakt ist und über eine korrekte Standardroute verfügt. (Route-Befehl)
Pingen Sie die Adresse der Standardroute. (Ping)
Pingen Sie eine globale IPV4-Adresse (ping www.google.com)
A. Wenn (3) funktioniert, aber (4) nicht, liegt das Problem am Netzwerk Ihres VPS-Anbieters. Geben Sie ihm die oben genannten Informationen. Wenn er nicht antwortet oder nicht antworten will, wechseln Sie den Anbieter – ich kann Afterburst empfehlen, da sie sehr gut darin sind, Fragen zu beantworten und kostengünstig sind.
B. Wenn (3) nicht funktioniert, überprüfen Sie Ihre Firewall (deaktivieren Sie sie vorübergehend). Überprüfen Sie auch die Standardroute beim VPS-Anbieter. Wenn das Deaktivieren der Firewall funktioniert, ist das Ihr Problem.
C. Wenn (4) funktioniert, liegt das Problem nicht bei Ihrem VPS, sondern bei Ihrem lokalen Netzwerk – da liegt Ihr Problem.
Beispielbefehle
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
Dies sagt uns:
– eth0 IPV4 ist global routbar (es ist keine RFC1918-Adresse)
– die eth0 IPV4-Adresse ist 55.135.9.135 mit einer 26-Bit-Subnetzmaske (255.255.255.192)
– die eth0-Broadcast-Adresse ist 55.135.9.191
– das Standard-Gateway ist 55.135.9.129, hierher senden wir alles, was von keiner anderen Route abgedeckt wird.
Wir verknüpfen die bekannten Geräte-IPs logisch mit der Subnetzmaske und sehen, dass sich das Gerät im selben Subnetz befindet wie wir, z. B.
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
Da das Ergebnis dasselbe ist, sollten wir direkt darauf zugreifen können, da auf das Standard-Gateway normalerweise direkt im lokalen Subnetz zugegriffen werden kann.
Wenn wir also das Gateway anpingen, sollten wir es sehen.
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
Wenn dies funktioniert, sollten wir die Hardwareadresse unseres Gateways in der ARP-Liste sehen
user@srv0:~$ sudo arp -a
? (55.135.9.129) at 00:21:59:cd:6a:48 [ether] on eth0
Wenn alles in Ordnung ist, sollten wir, wenn wir alle Firewall-Probleme ignorieren, in der Lage sein, externe Hosts zu kontaktieren. Sollte dies nicht gelingen, muss dies am Standard-Gateway und/oder am Upstream-Netzwerk vom Standard-Gateway liegen.