jhunt
commented
4 years ago Agents are unable to register through NAT devices currently in the v8.x versions of SHIELD. The main obstacle is that the agent connects to the core for registration (via HTTP), traversing the NAT and picking up the NAT device as the agent IP. The core then (at a later time) connects back to the detected agent IP on the advertised port, which will be the NAT device, on the 5444 port. That isn't likelyto work.
The *_proxy environment variables are aimed primarily at allowing agents to proxy their HTTP(s) traffic during plugin operations; i.e. accessing the AWS S3 API via a proxy in case direct egress HTTP(s) is disallowed by corporate perimeter firewalls in an on-premise environment.
Even if we lifted the constraint in the database, and solved the NAT issue by reporting IPs through the registration payload, you'd have a problem since SHIELD 8.x (and below) cores must initiate the SSH connection to the agent to "push" a task to it; if two agents have the same IP in different subnets, there's a good chance the SHIELD core won't be able to route to both of them without some sort of address translation, and if it could, the Linux kernel would be unable to differentiate the two endpoints on the wire.
peterellisjones
Hi Shield team,
Describe the bug There is a unique constraint on agent IP address. This prevents multiple agents registering with the shield process when they share a NAT gateway or HTTP proxy (or any type of routing which would cause them to appear to come from the same IP address). This prevents the following use case: Multiple agents deployed on separate VMs in VPC 1 and shield process running in VPC 2 with agent-server access via VPC 1 NAT gateway and VPC 2 public IP or LB.
The bosh release supports an
http(s)_proxyarguments for agents, suggesting that multiple agent registration with the same apparent IP should be supported.