Neue Linux-Installation, ssh- oder http-Verbindungen können nicht funktionieren, Verbindungen werden hergestellt, aber verworfen.
359
Richard T
Also, ich / wir haben eine brandneue Fedora Core 28-Installation, die wir online bringen wollten. Die Installation verlief perfekt, soweit wir das beurteilen konnten. Es verfügt über zwei Netzwerkkarten, eine für ein internes Netz und eine mit fester IP-Adresse. Es handelt sich um einen Server, dessen Hauptaufgabe es ist, einen Webserver auszuführen httpd. Und es muss von anderen als der Konsole aus erreichbar sein, damit es läuft sshd.
Zunächst scheint alles in Ordnung zu sein. Die erste Verwendung im Internet war die Verwendung von yum, um viele Pakete zu installieren. Es gab kein Problem. Wir haben hinzugefügt gnome, um eine GUI zu erhalten, hinzugefügt firefox, um einen Webbrowser zu erhalten, und haben diese dann verwendet, um Daten zur Fehlerbehebung zu erhalten. Anschlüsse am inneren Netz sind in Ordnung. Die Verbindung mit SSHist kein Problem, und mindestens ein Konto wurde eingerichtet, um Verschlüsselungsschlüssel zu verwenden, um ein Kennwort zu vermeiden. Das Anschließen an den neuen Webserver scheint ebenfalls gut zu sein, sowohl über interne als auch über externe IP-Adressen. Wir hatten also das Gefühl, dass wir bestätigt hatten, sshund der Webserver wurde ordnungsgemäß konfiguriert. ... Anfangs wussten wir nicht, dass etwas nicht stimmte.
Als wir uns von außen mit der Verbindung befanden, gingen die Dinge "seitwärts". Versuche, eine Verbindung SSHherzustellen, scheiterten direkt und die Verbindungen zum Webserver schienen ebenfalls völlig fehlzuschlagen.
Der erste Versuch war mit der Firewall. Wie ist es konfiguriert? Ist es iptablesoder firewalld? Wie stellen wir sicher, dass wir von außen durchkommen können? Wir haben festgestellt, dass wir die Ausnahme irgendwie konfiguriert hatten /etc/firewalld/zones- die Standardzone ist "FedoraServer.xml"in unserem Fall - httpd, und wir haben bei einem Neustart festgestellt, dass sie sich darüber beschwert und sie geändert hat http, wodurch wir keine Beschwerde mehr bemerkten. Immer noch keine Freude.
Dann ist da noch nmap! Dies ist ein Port-Scanner für Linux-Systeme, um die offenen Ports eines Netzwerkziels zu überprüfen. Dies schien zu zeigen, dass wir nicht von der Firewall blockiert wurden. Wir bestätigten, dass iptableses nicht in Gebrauch war und es war firewalld, also haben wir es ausgeschaltet und immer noch keine Freude.
Dann haben wir uns die ältere Ausrüstung angesehen. Twisted-Pair-Ethernet-Ports sind bidirektionale Geräte. War es also möglich, dass der externe Port eingehend war und der Outbound schlecht war? Oder vielleicht gab es auf dem Switch einen schlechten Port? Also haben wir versucht, sie auszutauschen, intern und extern. Keine Änderung.
Wir haben dann in Betracht gezogen, dass der Router möglicherweise gefiltert wurde, obwohl dies nicht der Fall sein sollte. Die neue Box war ein Ersatz für eine ältere Box, die im Ruhestand war, und die alte war voll funktionsfähig, aber wer weiß? Vielleicht ist der Router verrückt geworden? Also haben wir uns angemeldet und gesehen. Leider konnte niemand das Passwort des Routers finden.
Da der Router die Systeme nur über ihre externen IP-Adressen kennt, haben wir ein voll funktionsfähiges System heruntergefahren und das neue System die IP-Adresse des heruntergefahrenen Systems abholen lassen. Dadurch wird der Router als mögliche Ursache eliminiert, zumindest haben wir das gedacht. Die Probleme blieben jedoch bestehen.
Es wurde vorgeschlagen, dass der Router möglicherweise fehlerhaft ist, da er sich vielleicht MAC-Adressen besorgt hat. Um diese Möglichkeit auszuschließen, haben wir ihn neu gestartet. Wieder keine Verbesserung.
Ich hatte dann die Einsicht, unseren externen Tester aufzufordern, die Ausführlichkeit der ssh-Verbindungsdiagnosedaten zu erhöhen, indem Sie zunehmend -v zur Befehlszeile hinzufügen (Sie können bis zu drei), und unser interner sys-admin zur Überprüfung Apache-Protokolle Und das war sehr hilfreich. Wir fanden heraus, dass die externe Wahrnehmung sshunseren sshdDaemon erreichte, aber die Verbindungen wurden abgebrochen und auch die Protokolle des Webservers zeigten korrekte eingehende Verbindungen von genau den Orten, die wir erwartet hatten, und protokollierten "200" als Ergebnis. Dies bedeutet, httpddass das Web gedacht ist Kunden bekamen ihre Seiten. Aber es stimmte nicht.
OK, also jetzt was?
Portweiterleitung am Router ist etwas, das Sie nicht vermeiden können. Wenn es noch nicht festgelegt ist, benötigen Sie natürlich das Passwort, um die Einstellungen zu ändern. Sie sagen, der Alte hat gearbeitet? Das bedeutet eine von zwei Möglichkeiten: (1) es wurde bereits konfiguriert; oder (2) es handelt sich nicht um einen Router (z. B. werden alte Kabelmodems direkt miteinander verbunden, so dass die Firewall Ihre einzige Sorge ist; ein Router sollte dies laut Definition nicht zulassen).
GabrielaGarcia vor 5 Jahren
0
@GabrielaGarcia Danke für die Antwort, und wir haben überlegt, was Sie in Ihrem Kommentar ansprechen. Genau aus diesem Grund haben wir die IP-Adresse des Servers ausgetauscht, sodass der Router den Unterschied nicht erkennen konnte. Wir haben ihn neu gestartet, um sicherzustellen, dass die MAC-Adressen nicht zwischengespeichert werden. Aber wir haben das Problem gefunden, wie unten beschrieben. Ich habe dies gepostet, um die Anzahl der Leute zu reduzieren, die genauso viel Zeit verlieren wie wir!
Richard T vor 5 Jahren
0
1 Antwort auf die Frage
0
Richard T
Nach großer Agonie, wie oben dokumentiert, fühlte ich, dass eine gründliche, pedantisch detaillierte Umfrage in Ordnung war und getan wurde. Wir haben die Lösung gefunden und es war außergewöhnlich einfach!
Es ist wichtig zu verstehen, dass mehrere langjährige Experten mit mehr als 30 Jahren Erfahrung dies jeweils verpasst haben!
Die Ursache war einfach, dass die Standardroute auf der Box einen Fehler mit einem Zeichen hatte. Es war der Router, aber die falsche der beiden IP-Adressen, auf die der Router reagiert! Eine Adresse dient zur Manipulation des Routers über eine Port 80-Verbindung und die andere zur Weiterleitung des ausgehenden Datenverkehrs.
Es ist hilfreich zu wissen, dass eingehende Verbindungen bis zu einem bestimmten Zeitpunkt gut sind, wenn sich die Rückkehr auf den Fokus konzentriert, und dann, wenn die Antwort von innen und nicht von außen initiiert wird, die Route korrekt sein muss und nicht war. Deshalb ist es fehlgeschlagen.
Ich bin mir nicht ganz sicher, warum die ausgehenden Verbindungen genauso gut funktionierten wie sie, aber eine vernünftige Vermutung ist, dass der Router erkannte, dass die Pakete, die er auf die falsche IP-Adresse erhielt, immer noch nach außen geleitet wurden und entsprechend weitergeleitet wurden. Hmmm. Input dazu wird geschätzt.
Nur weil Sie mit dem Router sprechen, bedeutet dies nicht, dass Sie die Adresse der abgehenden Route korrekt angegeben haben! Zumindest war das für uns wahr.