So verwenden Sie Squid Proxy für den Zugriff auf Dienste in einer anderen VPC mit einer Multi-NIC-VM

Dieser Blog verwendet eine Squid Proxy-VM für den Zugriff auf Dienste in einer anderen Google Cloud VPC. Squid kann zwar als transparenter Proxy verwendet werden, aber dieses Blog verwendet der Einfachheit halber einen expliziten Proxy.

Übersicht über die Konnektivität

Der Squid-Proxy ermöglicht es Clients in der Quell-VPC, sich mit Diensten in der Ziel-VPC zu verbinden:

Der Squid-Proxy verwendet zwei Netzwerkschnittstellen, um die VPCs zu verbinden. Eine Schnittstelle nimmt Anfragen von der Quell-VPC entgegen und eine Schnittstelle verarbeitet Anfragen in der Ziel-VPC. Zusammengenommen ermöglicht der Squid Proxy den Clients in der Quell-VPC den Zugriff auf Ressourcen in der Ziel-VPC.

Das vollständige Beispiel finden Sie auf GitHub.

Überbrückung der Kluft

Clients konfigurieren einen Squid-Proxy mit Lastausgleich, um sich mit den Ressourcen der Ziel-VPC zu verbinden:

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

Mit der folgenden Konfiguration kann der Squid-Proxy Anfragen entsprechend weiterleiten:

• Akzeptieren Sie Verbindungen auf Port 3128

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

..

• Nachschlagen von Ressourcen in der Ziel-VPC

Wenn Sie die Ziel-VPC als primäre Schnittstelle konfigurieren, gehen DNS-Anfragen und IP-Pakete an die Ziel-VPC:

resource "google_compute_instance_template" "proxy" {
  ...

  # NOTE: Order of interfaces matter. DNS et al is bound to primary NIC.
  network_interface {
    subnetwork_project = var.project_id
    subnetwork         = google_compute_subnetwork.destination_vpc_nat.self_link
  }

  network_interface {
    subnetwork_project = var.project_id
    subnetwork         = google_compute_subnetwork.source_vpc_proxy.self_link
  }

  ...
}

• Rücksendung von Datenverkehr mit Lastausgleich an die Quell-VPC

Der Squid Proxy verwendet einen internen Network Load Balancer, um Anfragen auszugleichen. Ein interner Passthrough Network Load Balancer leitet Verbindungen von Clients direkt und ohne Unterbrechung an die gesunden Backends weiter. Zur Annahme von Datenverkehr mit Lastausgleich konfiguriert Google Cloud jede Backend-VM mit der IP-Adresse des Lastausgleichs.

Um einen Lastausgleich zu erreichen, wird eine Route so konfiguriert, dass das Quell-VPC-Gateway für den Verkehr von der Load Balancer-IP verwendet wird:

echo "Adding 'source' route table for load balanced traffic in source VPC"
SOURCE_CIDR=$(ip -o -4 addr show dev ens5 | awk '{print $4}')
SOURCE_IP=$${SOURCE_CIDR%"/32"}

SOURCE_GW_IP=$(ip route | grep 'dev ens5 scope link' | awk '{print $1}')

# Return load balanced traffic over source VPC interface
echo "1 source" >> /etc/iproute2/rt_tables
ip rule add from ${load_balancer_ip} table source
ip route add default via $SOURCE_GW_IP dev ens5 src $SOURCE_IP table source

Diskussion

Diese Einrichtung verhindert zwar, dass Sie Peerings konfigurieren und/oder zu viele Netzwerkdetails austauschen müssen. Die Einrichtung ist jedoch mit einigen Einschränkungen verbunden.

Erstens handelt es sich um einen einseitigen Kommunikationskanal, da man sich auf die eingebaute Funktion der primären Netzwerkschnittstelle (DNS und andere) verlässt. Um eine Zwei-Wege-Kommunikation zu ermöglichen, wäre ein zusätzlicher Proxy erforderlich.

Zweitens ist es anfällig für sich überschneidende IP-Adressen. Anfragen an IP-Adressen des Quell-VPC-Proxy-Subnetzes verlassen das Quell-VPC-Gateway und nicht das Ziel-VPC-Gateway. Zusätzliche IP-Regeln können den Verkehr entsprechend lenken, erfordern aber eine gründlichere Änderung der IP-Routing-Regeln, insbesondere für die lokale Load Balancer-IP-Adresse. Vorzugsweise wird ein sicherer IP-Adressraum vereinbart oder das Problem wird mit Hilfe eines verwalteten Dienstes wie Private Service Connect behoben.

Schließlich müssen die Clients wissen, welchen Proxy sie für welchen Dienst verwenden sollen. Der Name des Proxys könnte zwar auf ein Netzwerk hinweisen, aber den Kunden sind die Netzwerknamen egal. Ebenso wollen Netzwerkadministratoren vermeiden, dass ein einzelner Fehlerpunkt auftritt und/oder die Netzwerkeinrichtung kompliziert wird. Ziehen Sie daher für Service Mesh-Konnektivität alternative Tools wie Service Directory oder Anthos Service Mesh in Betracht, wenn Sie Kubernetes-Cluster betreiben.

Fazit

Es gibt unzählige Möglichkeiten, Google Cloud VPCs zu verbinden. Squid Proxy VMs mit mehreren Netzwerkschnittstellen ermöglichen es den Clients, auf Dienste in der Ziel-VPC zuzugreifen und den Datenverkehr zu kontrollieren/überwachen. Beachten Sie, dass die Lösung zwar nicht invasiv zu sein scheint, die Clients jedoch auf den Proxy aufmerksam gemacht werden müssen und der Proxy ein Netzwerksegment ohne überlappende IP-Adressen benötigt.

Bild von lumix2004 aus Pixabay