So verwenden Sie NGINX als Gateway zu Diensten in einer anderen VPC mit einer Multi-NIC-VM

Dieser Blog verwendet eine NGINX-Gateway-VM für den Zugriff auf Dienste in einer anderen Google Cloud VPC. Die Clients werden über benutzerdefinierte DNS-Einträge an das Gateway (oder den Forward Proxy) weitergeleitet. Daher ist keine Client-Konfiguration erforderlich.

Übersicht über die Konnektivität

Zunächst leiten benutzerdefinierte DNS-Einträge die Clients zum NGINX Gateway. Als nächstes verbindet das NGINX-Gateway Clients aus der Quell-VPC mit Services in der Ziel-VPC:

Das NGINX-Gateway 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 das NGINX-Gateway den Clients in der Quell-VPC den Zugriff auf Ressourcen in der Ziel-VPC.

Das vollständige Beispiel finden Sie auf GitHub.

Die Konnektivität zusammenfügen

Clients verbinden sich mit den Ressourcen der Ziel-VPC wie mit jeder anderen Internetressource:

curl http://example-server.xebia/

Die folgende Konfiguration stellt sicher, dass die Anfragen entsprechend behandelt werden:

• Umleitung von VPC-Zielanfragen an das NGINX-Gateway

Dienste in der Ziel-VPC werden in der privaten DNS-Zone der Quell-VPC registriert:

# The .xebia private DNS zone is made visible to the Source VPC
resource "google_dns_managed_zone" "source_vpc_xebia" {
  project  = var.project_id
  name     = "${google_compute_network.source_vpc.name}-xebia"
  dns_name = "xebia."

  visibility = "private"

  private_visibility_config {
    networks {
      network_url = google_compute_network.source_vpc.id
    }
  }
}

# Any .xebia domain name is redirected to the nginx-gateway VM
resource "google_dns_record_set" "source_vpc_nginx_gateway_redirect_base_xebia" {
  project      = var.project_id
  managed_zone = google_dns_managed_zone.source_vpc_xebia.name
  name         = "*.xebia."
  type         = "CNAME"
  ttl          = 300s
  rrdatas      = [google_compute_address.nginx_gateway.address]
}

Beachten Sie, dass die registrierten Dienste auf die NGINX-Gateway-Adresse verweisen

• Akzeptieren Sie HTTP/S-Anfragen auf dem NGINX-Gateway

Das NGINX-Gateway wartet auf HTTP/S-Anfragen, die weitergeleitet werden sollen:

http {
  ...

  server {
    listen ${load_balancer_ip}:80;

    resolver 169.254.169.254;

    location / {
        # Note: Please include additional security for a production deployment. Exposing all reachable HTTP endpoints is probably not intended.
        proxy_pass http://$http_host$uri$is_args$args;
        proxy_http_version 1.1;
    }
  }
}

stream {
  server {
    listen ${load_balancer_ip}:443;

    resolver 169.254.169.254;

    # Note: Please include additional security for a production deployment. Exposing all reachable HTTPS endpoints is probably not intended.
    proxy_pass $ssl_preread_server_name:443;
    ssl_preread on;
  }
}

• 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" "nginx_gateway" {
  ...

  # 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

Das NGINX-Gateway 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. Um den Datenverkehr mit Lastausgleich zu akzeptieren, 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 Einweg-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ätzliches Gateway 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 hängt der HTTPS-Forwarder von dem Modul ngx_stream_ssl_preread_module ab, um die Zieldomäne zu erhalten. Anfragen ohne eine Server Name Indication (SNI) schlagen fehl.

Fazit

Es gibt unzählige Möglichkeiten, Google Cloud VPCs zu verbinden. NGINX-Gateway-VMs mit mehreren Netzwerkschnittstellen ermöglichen Clients den Zugriff auf Dienste in der Ziel-VPC und die Steuerung/Überwachung des Datenverkehrs. Beachten Sie, dass die Lösung zwar für Clients transparent ist, aber aufgrund von sich überschneidenden IP-Adressen und/oder nicht abgedeckten Client-Anfragen subtile Fehler auftreten können.

Bild von Peter H von Pixabay