Ich muss feststellen, ob eine bestimmte Site über einen bestimmten Port zugänglich ist, da im Netzwerk Firewall-Einschränkungen bestehen.
Wenn ich über einen bestimmten Port nicht auf die Site zugreifen kann, muss ich die Firewall ändern, bevor ich fortfahren kann. Andernfalls kann ich mit meiner beabsichtigten Aufgabe fortfahren, wenn ich die Site erreichen kann.
Ich wollte wissen, ob ich ein Repository mithilfe Githubder https-URL des Repositorys abrufen kann. Eine Beispiel-https-URL: https://github.com/git-for-windows/git.git. Dies kann mit cloneund anderen Tools verwendet werden.
Um zu sehen, ob ich Githubdas Repository erreichen und somit klonen konnte, habe ich den folgenden Befehl ausgeführt:Test-NetConnection -ComputerName github.com -Port 443 |findstr "TcpTestSucceeded"
github.comAuf dem System gab dieser Befehl Folgendes zurück, was darauf hinweist, dass ich eine Verbindung über Port 443 (https) herstellen konnte .
TcpTestSucceeded : True
Allerdings habe ich dann einen Webbrowser geöffnet und besucht https://github.comund der Webbrowser hat angezeigt, dass keine Verbindung hergestellt werden konnte. https läuft über Port 443 und die Domäne ist github.comgenau so, wie ich sie im Test eingegeben habe.
Meine Fragen sind:
- Warum gibt es diese Diskrepanz zwischen den beiden Tests?
- Wie kann ich genau testen
CMD,PowerShellob ich über einen bestimmten Port Zugriff auf eine bestimmte Domäne habe?
Offensichtlich Test-NetConnectionlieferte der Befehl keine genauen Ergebnisse, da der Webbrowser nicht in der Lage war, darauf zuzugreifen github.com.
Antwort1
Offensichtlich lieferte der Befehl „Test-NetConnection“ keine genauen Ergebnisse, da der Webbrowser github.com nicht erreichen konnte.
Das ist keine genaue Aussage.
Test-NetConnection hat tatsächlich eine TCP-Verbindung zu Port 443 des Zielservers hergestellt und überprüft, ob sich TCP-Port 443 auf dem Remote-Server im Abhörstatus befindet. Test-NetConnection prüft nicht, welche Anwendung/welcher Dienst auf Port 443 läuft/abhört.
Im Wesentlichen kann Ihnen Test-NetConnection nicht sagen, was auf Ebene 7 ausgeführt wird/abhört, es kann Ihnen nur sagen, dass Port 443 im Abhörzustand ist.
Antwort2
Die beiden Aussagen „Die Verbindung kann hergestellt werden“ und „Ich kann mit meiner beabsichtigten Tätigkeit fortfahren“ sind alles andere als gleichwertig, und ein einfacher TCP-Verbindungstest wie Test-NetConnectiontestet überhaupt nicht dasselbe wie ein tatsächlicher git clone.
Die Möglichkeit, eine TCP-Verbindung zu einem Port zu öffnen, bedeutet nicht automatisch, dass Sie auf den Dienst zugreifen können, der diesen Port überwacht. Nach der ersten Verbindung können viele Schritte fehlschlagen, z. B. TLS-Verhandlungen, Authentifizierung, Autorisierung oder Protokollaustausch auf Anwendungsebene.
Außerdem sind Firewall-Einschränkungen nicht der einzige mögliche Grund für das Scheitern einer TCP-Verbindung, und Ausfälle der TCP-Verbindung sind nicht die einzige mögliche Auswirkung einer Firewall-Einschränkung. Ihre Aussagen also:
Wenn ich über einen bestimmten Port nicht auf die Site zugreifen kann, bedeutet das, dass ich die Firewall ändern muss, bevor ich fortfahren kann.
Und
Andernfalls könnte ich mit meiner Absicht fortfahren, sofern ich die Site erreichen kann.
sind beide falsch. Das bedeutet, dass Sie, anstatt sich zu fragen, warum Ihr Test-NetConnectionTest das Problem nicht erkannt hat, das später dazu führte, dass Ihr GitHub-Zugriff fehlschlug, analysieren sollten, was das Problem tatsächlich war, und dann beurteilen sollten, ob es von Vorteil wäre, dieses spezielle Problem im Voraus zu erkennen. Wenn die Antwort ja lautet, können Sie einen Test entwickeln, der genau das tut.
In der Praxis ist es häufig am effizientesten, den beabsichtigten Vorgang ohne vorherige Tests einfach auszuprobieren und etwaige Fehler zu beheben, sobald sie auftreten. Eine vorherige Überprüfung auf Probleme ist meist nur dann sinnvoll, wenn sie automatisch behoben werden können oder wenn der Versuch und das Scheitern des eigentlichen Vorgangs mit erheblichen Kosten oder Risiken verbunden sind.
Insbesondere schlagen GitHub-Operationen ziemlich reibungslos und mit einigermaßen klarer Angabe der Fehlerursache fehl. Daher sehe ich keinen direkten Vorteil darin, zuerst die Verbindung zu testen, anstatt die beabsichtigte Operation direkt auszuführen.