[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] NAT inside NAT issue.
- Date: Thu, 01 Dec 2016 15:32:14 -0600
- From: Todd L Miller <tlmiller@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] NAT inside NAT issue.
So as I understand your layout, we can simplify to the following
CM: 180.101.18.x (public), 192.168.31.100 (private network A)
Zone A execute node: 192.168.31.y (private network A)
Zone B execute node: 172.17.10.z (private network B)
The CM should be configured with PRIVATE_NETWORK_NAME = PrivateNetworkA.
The zone A executable node should be configured with PRIVATE_NETWORK_NAME
= PrivateNetworkNameA. The zone B executable node should be configured
with PRIVATE_NETWORK_NAME = PrivateNetworkNameB, but will need to use CCB
to be available to anyone outside of zone B. You probably don't want them
to be avilable from off-campus, so the zone B execute nodes should -- if
192.168.31.100 can be directly connected to from zone B -- set the zone B
execute nodes' CCB_ADDRESS to that.
Ignoring security for the moment, that should suffice for
connectivity. Note that only zone B's nodes are configured to use CCB;
the nodes in zone A share a private network with the CM in zone A, so they
don't need to use CCB.
If you want to an EC2 instance to join your pool, set the
following configuration on that instance (and that instance only):
COLLECTOR_HOST = 180.101.18.x
TCP_FORWARDING_HOST = EC2PublicIP
Where for testing you can set EC2PublicIP by hand (based on the public IP
listed on the AWS console). See the first section of
for help setting EC2PublicIP automatically.
This assumes that 180.101.18.x (port 9618) is an interface on the
CM or transparently forwards to it.