So verwenden Sie Squid Proxy für den Zugriff auf Dienste in einer anderen VPC mit Private Service Connect

Dieser Blog verwendet eine Squid Proxy-VM für den Zugriff auf Dienste in einer anderen Google Cloud VPC. Clients verbinden sich mit der Squid Proxy-VM über Private Service Connect. Dadurch werden Probleme mit sich überschneidenden IP-Adressen vermieden und die Komplexität von Netzwerken wie Peering und Routing reduziert.

Überblick über die Lösung

Clients stellen über den Squid-Proxy eine Verbindung zu den Ziel-VPC-Diensten her:

curl -x http://proxy.xebia:3128 http://example-server.xebia/

Squid kann zwar als transparenter Proxy verwendet werden, aber dieser Blog verwendet der Einfachheit halber einen expliziten Proxy.

Die Ziel-VPC-Dienste werden vom Squid-Proxy über Private Service Connect bereitgestellt:

Ein mit Private Service Connect veröffentlichter Dienst ist für Verbraucher in anderen VPCs über Endpunkte und/oder Backends verfügbar. Endpunkte basieren auf einer Weiterleitungsregel. Backends basieren auf einem Load Balancer. Die vorherige Abbildung zeigt eine Endpunkt-basierte Verbindung.

Dienste werden mit Hilfe eines Dienstanhangs veröffentlicht. Der Service-Anhang erlaubt/verweigert (Client-)Verbindungsanfragen und gibt an, wie der Service in der Ziel-VPC gehostet wird.

Das vollständige Beispiel finden Sie auf GitHub.

Bereitstellung der Lösung

Die folgende Konfiguration ermöglicht es dem Squid-Proxy, Quell-VPC-Anfragen zu empfangen:

• Squid Proxy-Server einrichten

Die Squid-Konfiguration lauscht auf Port 3128 und leitet den gesamten HTTP-Verkehr problemlos weiter:

http_port 3128

...

# Allow all HTTP traffic, use a more fine-grained setup in production..
http_access allow all

• Squid Proxy-Dienst veröffentlichen

Der Dienst wird über einen Dienstanhang veröffentlicht, der auf den Squid Proxy Server Load Balancer abzielt:

resource "google_compute_service_attachment" "proxy" {
  project = var.project_id
  region  = "europe-west1"
  name    = "squid-proxy"

  nat_subnets           = [google_compute_subnetwork.destination_vpc_psc.self_link]
  target_service        = google_compute_forwarding_rule.proxy.self_link

  ...
}

Die Clients - die Kunden des Dienstes - verbinden sich mit dem Dienst über eine IP-Adresse aus dem dedizierten NAT-Subnetz. Jede Client-Verbindung verbraucht eine IP-Adresse aus dem Subnetz. Wenn mehrere Verbindungen hergestellt werden, verbraucht jede Verbindung eine IP-Adresse. Dimensionieren Sie daher das Subnetz ausreichend:

resource "google_compute_subnetwork" "destination_vpc_psc" {
  project       = var.project_id
  network       = google_compute_network.destination_vpc.id
  name          = "${google_compute_network.destination_vpc.name}-psc"
  region        = "europe-west1"
  ip_cidr_range = "10.10.0.0/24"

  purpose = "PRIVATE_SERVICE_CONNECT"
}

• Konfigurieren Sie die Squid Proxy Client-Verbindung

Fügen Sie zunächst den Endpunkt Private Service Connect zur Quell-VPC hinzu:

resource "google_compute_forwarding_rule" "proxy_endpoint" {
  project = var.project_id
  region  = "europe-west1"
  name    = "squid-proxy-endpoint"

  ip_address = google_compute_address.proxy_endpoint.id
  load_balancing_scheme = "" # Prevent default to 'EXTERNAL'

  network    = google_compute_network.source_vpc.id
  subnetwork = google_compute_subnetwork.source_vpc_proxy.id

  target = google_compute_service_attachment.proxy.id
}

Schließlich akzeptieren Sie die Client-Verbindung über den Service-Anhang:

resource "google_compute_service_attachment" "proxy" {
  project = var.project_id
  region  = "europe-west1"
  name    = "squid-proxy"

  connection_preference = "ACCEPT_MANUAL"

  # Accept up to 4 connections from the example project
  consumer_accept_lists {
    project_id_or_num = var.project_id
    connection_limit  = 4
  }
}

• Squid Proxy-Dienst verbrauchen

Zugriff auf Ziel-VPC-Dienste über den Squid-Proxy:

curl -x http://proxy.xebia:3128 http://example-server.xebia/

Sehen Sie sich das vollständige Beispiel auf GitHub an, um die DNS-Konfiguration hinzuzufügen.

Diskussion

Private Service Connect vereinfacht die Vernetzung von Diensten. Peering- und Routing-Techniken sind nicht mehr erforderlich. Dies erleichtert zwar die Verbindung von Diensten, kann aber für Squid Proxy-Anwendungsfälle einen Nachteil darstellen. Mit Private Service Connect wechselt der Squid Proxy-Server in das Ziel-VPC-Netzwerk, wodurch er die Details des Quell-VPC-Netzwerks verliert. Ohne diese Details können sich die Zugriffskontrolllistenfunktionen von Squid Proxy nicht auf die IP-Adressen der Clients verlassen (sowohl durch NAT als auch durch den PROXY-Protokoll-Header). Alternativ kann Squid Proxy die Proxy-Authentifizierung (Benutzername/Passwort) verwenden, um Clients zu erkennen und Zugangskontrolllisten durchzusetzen. Aber vielleicht ist es sinnvoller, die Dienste, die Sie bereitstellen möchten, direkt zu veröffentlichen.

Private Service Connect vereinfacht zwar die Verbindung zu Diensten in anderen VPCs, hat aber auch seine Nachteile. Erstens ist die Kommunikation immer noch auf eine Einwegverbindung beschränkt. Eine Zwei-Wege-Kommunikation würde eine umgekehrte Verbindung erfordern. Außerdem stellt die Verwendung dedizierter NAT-Subnetze hohe Anforderungen an das Design der Ziel-VPC, zumal diese Subnetze nur von einem einzigen Service-Attachment verwendet werden können.

Fazit

Es gibt unzählige Möglichkeiten, Google Cloud VPCs zu verbinden. Squid Proxy VMs, die über Private Service Connect veröffentlicht werden, ermöglichen es Clients aus jeder VPC, auf Dienste in der Ziel-VPC zuzugreifen und den Datenverkehr zu überwachen. Um den Datenverkehr mit Hilfe von Zugriffskontrolllisten zu kontrollieren, sind zusätzliche Maßnahmen erforderlich, wie z.B. die Proxy-Authentifizierung. Schließlich ist zu beachten, dass die Clients auf den Proxy aufmerksam gemacht werden müssen, um auf die Dienste zugreifen zu können. Vielleicht ließe sich dies noch weiter vereinfachen, indem die Zieldienste direkt zugänglich gemacht werden.

Bild von Pexels aus Pixabay