Ein per IP authentifiziertes Proxy-Konto kann von einem Worker aus funktionieren und einen anderen ablehnen, weil die Worker von unterschiedlichen öffentlichen Adressen kommen. Die Flotte braucht einen bewusst gewählten Weg nach außen, bevor sie sich mit dem Proxy verbindet.

Eine AWS-IPv4-Anordnung ist:

private worker → public NAT gateway → internet gateway → proxy service → destination

Ein öffentliches NAT-Gateway hat eine zugehörige Elastic IP. Für Datenverkehr über das Internet-Gateway der VPC übersetzt AWS die private Adresse des NAT-Gateways in diese Elastic IP. Ein entfernter Proxy kann daher diese öffentliche Egress-Adresse autorisieren statt der privaten Adresse jedes Workers.

Leiten Sie den internetgebundenen Verkehr der vorgesehenen Worker über das geplante Gateway und registrieren Sie die möglichen öffentlichen Egress-Adressen beim Proxy-Dienst. Wenn die Bereitstellung mehrere NAT-Gateways oder zusätzliche Egress-Adressen verwendet, berücksichtigen Sie jeden Pfad, den die Flotte nehmen kann.

Die vom Proxy akzeptierte Quelle ist eine Adressbeziehung. Die vom Ziel beobachtete Exit-Adresse des Proxys ist eine andere. Einem Konto eine stabile Verbindungs-IP zu geben, zwingt den Dienst nicht, diese IP als Exit zu verwenden.

Ein privates NAT-Gateway bietet diese Internet-Anordnung mit öffentlicher Elastic IP nicht. AWS dokumentiert außerdem ein anderes Adressverhalten, wenn ein öffentliches NAT-Gateway Datenverkehr über ein Transit- oder virtuelles privates Gateway statt über das Internet-Gateway sendet.

Die operative Prüfung ist die Beobachtung des Proxy-Dienstes bei einer Verbindung aus jeder Worker-Route, einschließlich Failover. Bewahren Sie diese Beobachtung zusammen mit der Egress-Konfiguration auf, damit eine spätere Netzwerkänderung in der Allowlist des Kontos abgebildet werden kann.

Ähnliche Artikel