Mit dem Network Analyzer können Sie Konfigurationen erkennen, die nicht wie erwartet funktionieren. Diese ungültigen Konfigurationen können auf einige Einrichtungsfehler oder Regressionen zurückzuführen sein, die durch andere Änderungen verursacht werden. Wenn verschiedene Teams Inhaber der Dienste sind, die von einer solchen ungültigen Konfiguration betroffen sind, kann es schwierig sein, solche Probleme zu beheben. Wenn Sie solche Fehler entdecken, können sie zu einer schnelleren Fehlerbehebung und effektiven Kommunikation zwischen verschiedenen Teams führen.
Konfigurationsfehler aufgrund blockierender Firewalls
Fehler bei der Firewallkonfiguration, die Google Cloud-Dienste blockieren, können während oder nach der Ersteinrichtung auftreten.
Während der Ersteinrichtung
Im Folgenden sind einige gängige Firewallfehler aufgeführt, die das Funktionieren von Google Cloud-Diensten blockieren:
- Firewallkonfiguration fehlt. Beispielsweise wurde die Systemdiagnose-Firewall des Load-Balancers nicht konfiguriert.
- Tippfehler im manuellen Konfigurationsprozess, die fehlerhafte Konfigurationen verursachen.
- Eine durch fehlende VM-Tags verursachte inkonsistente Konfiguration. Beispiel: Sie konfigurieren die Firewallregel mit den erwarteten Ziel-VM-Tags, aber einige Backend-VMs sind nicht mit dem spezifischen Tag verknüpft.
Nach der Ersteinrichtung
Eine unbeabsichtigte Änderung der Firewallkonfiguration kann einen zuvor ordnungsgemäß funktionierenden Dienst beeinträchtigen. Beispiel: Sie können unbeabsichtigt eine Firewallregel mit höherer Priorität erstellen, die die Verbindung zu GKE- oder Cloud SQL-Diensten blockiert.
Szenario: Die Firewall für die Systemdiagnose ist für den Load-Balancer nicht konfiguriert
In diesem Beispiel meldet Network Analyzer einen Insight in der Kategorie Informationen zum Load-Balancer vom TypFirewall für Systemdiagnose ist nicht konfiguriert. Auf der Seite mit den Statistikdetails wird die implizierte Regel zum Ablehnen von eingehendem Traffic in dem Netzwerk angezeigt, in dem der Load-Balancer konfiguriert ist. Die Regel für eingehenden Traffic blockiert den Bereich der Systemdiagnose. Dies gibt an, dass die Back-Ends des Load-Balancers keine Firewallregeln konfiguriert haben, die den Bereich der Systemdiagnose zulassen.
Konfigurieren Sie die Firewallregel für die Systemdiagnose so, dass der Bereich der Systemdiagnose explizit für den Zugriff auf die Load-Balancer-Back-Ends zugelassen wird.
Szenario: GKE-Knoten zur Verbindung zur Steuerungsebene, der durch eine Firewallregel blockiert wird
In diesem Beispiel wird eine Information der Kategorie Insights: GKE-Knotenverbindung vom Typ Verbindung vom GKE-Knoten zur Steuerungsebene generiert.
Auf der Seite mit den Insight-Details wird angezeigt, dass eine Firewallregel die Verbindung vom GKE-Knoten zur Steuerungsebene in einem Cluster ablehnt. Dieses Problem beruht auf einer Ablehnungsregel. Entfernen Sie diese Regel oder richten Sie eine Genehmigungsregel mit höherer Priorität ein, um das Problem zu beheben.
Szenario: Verbindung von der GKE-Steuerungsebene zum Knoten wird durch eine Firewallregel blockiert
In diesem Beispiel wird eine Information der Kategorie Insights: Konnektivität GKE-Steuerungsebene vom Typ Verbindung von der GKE-Steuerungsebene zum Knoten generiert.
Auf der Seite der Insight-Details wird angezeigt, dass eine Firewallregel die Verbindung von der GKE-Steuerungsebene zu den Knoten in einem Cluster ablehnt.
Fehler bei der Routingkonfiguration
Routen mit ungültigen nächsten Hops können zu partiellem oder umfassenden Trafficverlust führen. Ein solcher Verlust kann darauf zurückzuführen sein, dass Routen zu nächsten Hop-VMs weiterleiten, die nicht ausgeführt werden oder gelöscht wurden.
Konfigurationsänderungen, die zu einer unbeabsichtigten Routingänderung führen können, beinhalten folgende Szenarien:
- Das Hinzufügen eines neuen Subnetzes mit IP-Adressbereichen, die sich mit einer dynamischen Route überschneiden, führt dazu, dass die dynamische Route verdeckt wird. Dies kann zu einem Traffic-Abfall führen.
- Das Hinzufügen einer neuen Standardroute über ein VPN kann Kapazitätsengpässe verursachen, die sich auf die Netzwerkleistung auswirken.
Szenario: Die VM im nächsten Hop wurde gelöscht.
In diesem Beispiel tauchen Informationen der Kategorie "Routen mit ungültigen nächsten Hops" vom Typ VM gelöscht auf.
Auf der Seite der Insight-Details wird angezeigt, dass die nächste Hop-VM in dieser Route gelöscht wurde. Daher wird diese Route als ungültig gemeldet.
Löschen Sie entweder die Route oder erstellen Sie eine neue VM-Instanz, die als nächster Hop der Route verwendet werden soll. Eine Konfigurationsänderung, die diese Statistik verursachen kann, wird auf der Seite mit den Statistikdetails angezeigt. Klicken Sie auf den Link, um die Cloud Logging-Seite zu öffnen und die Konfigurationsdetails anzuzeigen, z. B. den Nutzer, der die Änderung vorgenommen hat, sowie den Zeitpunkt der Änderung.
Szenario: Die dynamische Route ist verdeckt
In diesem Beispiel werden Informationen der Kategorie Insights: Verdeckte dynamische Routen des Typs Durch Peering-Subnetzroute vollständig verdeckt generiert.
Auf dieser Seite mit den Statistikdetails wird angezeigt, dass eine importierte dynamische Route, die vom Netzwerk-Peer mit dynamischen Hop-Netzwerkrouten für den nächsten Hop ermittelt wurde, verdeckt wird. Der IP-Adressbereich der dynamischen Route überschneidet sich mit einer neuen Subnetzroute und ist daher vollständig verdeckt. Traffic, der an das Peering-Netzwerk an diesen IP-Adressbereich gesendet wird, wird an ein Subnetz im VPC-Netzwerk weitergeleitet.
Szenario: Verbindung zur Cloud SQL-Instanz wird durch fehlendes Netzwerk-Peering blockiert
In diesem Beispiel werden Informationen der Kategorie "Cloud SQL-Konnektivität" vom Typ Verbindung zur Cloud SQL-Instanz wird durch ein Routingproblem blockiert angezeigt.
Auf der Insight-Seite wird angezeigt, dass die Verbindung zu einer Cloud SQL-Instanz blockiert ist, da das Netzwerk-Peering fehlt.