For the machines beind NAT, you'll need to edit the configuration to set
the public address they are reachable on. For sshftp, you can add the
-data-interface option to the exec line at the end of
/etc/grid-security/sshftp. The value can be a hostname or IP address.
Mike
On 4/18/2017 2:13 PM, greg whynott wrote:
Hello,
First post, searched around for an answer but maybe I'm not using the
proper lingo. sorry in advance if this has been covered previously.
3 machines involved, 3rd is where commands are being issued from
(tor-hm1) it is local to tor-xfer.
tor-hm1 - local network - behind NAT
tor-xfer - local network - behind NAT
chn-xfer remote network - public IP
This command works as expected, moving data from tor-xfer to chn-xfer,
[hpcdata1@tor-hm1 ~]$ globus-url-copy -vb -cd -p 2
sshftp://hpcda...@tor-xfer.removed.com/var/tmp/outtest.gz
<http://hpcda...@tor-xfer.removed.com/var/tmp/outtest.gz>
sshftp://hpcda...@chn-xfer.removed.com/var/tmp/outtest.gz
<http://hpcda...@chn-xfer.removed.com/var/tmp/outtest.gz>
Attempting to move data in the other direction from chn to tor, this
command will fail:
[hpcdata1@chn-xfer ~] globus-url-copy -vb -cd -p 2
sshftp://hpcda...@chn-xfer.removed.com/var/tmp/chn-300k.fl
<http://hpcda...@chn-xfer.removed.com/var/tmp/chn-300k.fl>
sshftp://hpcda...@tor-xfer.removed.com/var/tmp/chn-300k.fl
<http://hpcda...@tor-xfer.removed.com/var/tmp/chn-300k.fl>
tor-hm1, and tor-xfer are RFC1918 numbered and behind a NAT firewall
with 1 to 1 mapping to an outside address on the firewall. Any
traffic hitting this outside IP will be forwarded to tor-xfer. THis has
been tested and confirmed to work, there are no readability issues from
the remote network for any ports.
chn-xfer has an interface on a rotatable public IP, no NAT.
tor-hm1 and tor-xfer use internal DNS. The answers returned are not
the same as what the internet name servers will return when asking for
host lookups. think split dns.
What appears to be happening is when tor-hm1 contacts chn-xfer, it
asks it to "connect to this IP and send this file", the problem is it
is telling chn-xfer to connect back to the RFC1918 IP address, not the
public one. which of course it can't reach. This was verified via
packet trace, chn-xfer attempts to connect to tor-xfer's internal IP.
*My question:, Is there a method to force the hostname to be passed
over to the remote server instead of the IP, so the remote end does the
lookup?* If chn-xfer did its own lookup on the name, it would get
the 'proper' IP to use and things would likely be good again.
While I could be wrong, it would seem to be a better idea to have the
local NS used instead of the requester doing this for them, what is the
thinking here? Just curious really.
thanks for your time,
greg
