Die Organisation, zu deren Netzwerk dieser Server gehört, ändert ihren ISP. Wenn ich diesen Server auf neue Werte für IP, Gateway usw. umstelle, kann ich mich nicht mehr per SSH mit ihm verbinden. Ich habe eines der Port-Checking-Tools aufgerufen und als ich Port 22 überprüft habe, wurde mir angezeigt: „Ich konnte Ihren Dienst unter _neuem_IP_Wert_ auf Port 22 nicht sehen.“
Die neue IP ist statisch. Auf dem betreffenden Server gibt es keinen Router und keine Portweiterleitung – das Netzwerkkabel geht direkt in den Server.
Natürlich dachte ich, dass das Netzwerk der Organisation oder der neue ISP Port 22 blockierte, also rief ich den Netzwerkadministrator an und bat ihn, ihn zu öffnen oder den ISP zu bitten, ihn zu öffnen. Er sagte, er würde das tun. Aber es änderte sich nichts. Ich rief ihn einen Tag später mit derselben Frage an, aber man merkte, dass er beschäftigt war – er sagte, er habe getan, worum ich gebeten hatte, und legte dann im Grunde auf.
Jetzt denke ich, dass vielleicht doch etwas mit den Einstellungen des Servers nicht stimmt. Aber alle Linux-Tools wie lsof, netstat, nmap usw. zeigen an, dass sshd läuft und auf Port 22 lauscht, Port 22 geöffnet ist usw. und ich kann immer noch per SSH auf den Server zugreifen, wenn ich ihn wieder auf das Netzwerk unseres alten ISPs umstelle – ich ändere nur IP, Gateway, DNS, sonst nichts.
Könnte es auf diesem Server etwas geben, das SSH-Verbindungen blockiert, wenn sich der Server im Netzwerk des neuen ISP befindet, aber nicht im Netzwerk des alten? Das Betriebssystem ist Linux Mint.
Antwort1
Führen Sie eine Paketerfassung auf dem Client und eine Paketerfassung auf dem Server aus. Die gängigsten Tools sind Wireshark und tcpdump:
tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"
Wenn Sie sehen, dass die TCP-SYN-Pakete den Client verlassen, aber nicht beim Server ankommen, liegt das Problem normalerweise am Netzwerk – höchstwahrscheinlich am ISP des Servers, da Online-Tools zur Portprüfung die Möglichkeit ausgeschlossen haben, dass der ISP auf der Clientseite der Fehler ist.
(Vielleicht hat der Administrator die Ports überhaupt nicht geöffnet oder sie nicht für die richtige Adresse geöffnet. Es kommt auch nicht selten vor, dass Port 3389 auf ISP-Ebene geschlossen wird.)
Ich denke,
tcptraceroutedass dies möglicherweise dabei helfen kann, herauszufinden, wie weit die Pakete reisen, bevor sie verschwinden.Wenn Sie sehen, dass TCP-SYN-Pakete beim Server ankommen, aber nicht beantwortet werdenüberhaupt, liegt das Problem am Server. Es könnte an der internen Firewall des Servers liegen (tcpdump erhält PaketeVorsie treffen die Firewall), also überprüfen Sie, ob Sie irgendwelche iptables Regeln habenUndalle NFT-Regeln.
Stellen Sie außerdem sicher, dass der Server über eineRückwegan den Client und dass es tatsächlich über die richtige Schnittstelle an das richtige Gateway geht:
ip -4 route get <client_ip> ip -4 route show match <client_ip>Führen Sie den Vorgang auch aus,
systemctl cat sshdum zu prüfen, ob Whitelists für IP-Adressen auf Cgroup-Ebene vorhanden sind. Führen Sie den Vorgang auch aus, um zu prüfen,ip xfrm policyob IPsec-Richtlinien vorhanden sind.Wenn Sie sehen, dass TCP SYN-Pakete ankommen, diese aber TCP RST-Antworten generieren, könnte es immer noch an der Firewall liegen, oder es könnte sein, dass der SSH-Daemon so konfiguriert ist,Hörenan die falsche Adresse. (Sie haben nicht erwähnt, wasLokale Adressewird von lsof/netstat neben „Port 22“ angezeigt. Wenn 0.0.0.0:22 oder [::]:22 angezeigt wird, ist das in Ordnung, aber wenn die alte Adresse angezeigt wird, muss diese in sshd_config geändert werden.)
Wenn Sie sehen, dass TCP-SYN-Pakete ankommen und SYN/ACK-Antworten vom Server kommen, der Client diese Antworten aber nie erhält, handelt es sich ebenfalls um ein Netzwerkproblem und liegt höchstwahrscheinlich wieder auf der ISP-Seite des Servers.