1

I am not sure if I should be asking this in Unix & Linux or Network Engineering

Here is the physical scenario

[Host 1]----[Carrier-grade NAT]---->AWS<----[Carrier-grade NAT]----[Host 2]

Host 1 and Host 2 are reverse ssh'ed (autossh) into an AWS Box, so they do have shell connectivity if required, and possibility to expose any other port if required.

Host 2 pushes backup dumps to Host 1 using SCP on regular basis. There are actually Host2 X 10 boxes pushing the data dumps. Nearest AWS location is quite far from the location of boxes so latency is quite a lot.

Is there a possibility to use the AWS box as a rendezvous point to broker a ssh tunnel between the boxes? I am aware about the IPv6 tunnel brokers but the ISPs in the region are yet to adopt it (20 years late... duh!) I am exploring a solution bases on:

  • TCP / UDP hole punching (with practical implementation)
  • UPnP / NAT-PMP service on AWS
  • Using tools such as Chrome Remote Desktop, hack it to expose SSH port rather then VNC
  • Any other router service.
  • Any other practical approach.

Boxes are running CentOS 6/7 mostly.

Improve this question
17
  • Is setting up a VPN on AWS instance a viable option? Commented Nov 19, 2017 at 16:31
  • Not in this specific case, the latency issue. Also the direct connection (once brokered) will help keeping AWS bills in check. Commented Nov 19, 2017 at 16:37
  • 2
    I don't see why you need a regional IPv6 broker. I use one that's based out of the US (not my country). As long as your IPv6-in-IPv4 traffic isn't blocked I don't see the problem. I'll make this an answer if it helps you. Commented Nov 19, 2017 at 19:55
  • 2
    For TCP hole punching: you should gather more informations on how your CGN is working. Perhaps by comparing with multiple tests the SSH source port seen on host1 then same source seen on aws. Do they differ?. Same for the ssh source port seen on host2 then on aws. Doing tests with a 2nd "broker" IP would be preferable too. If they differ and you can't find an algorithm able to predict what it will become, I don't see what to do. If you can find or they don't differ, then maybe its possible (TCP allows handshakes initiated with a simultaneous SYN/SYN instead of the usual SYN/SYN+ACK/...) Commented Nov 20, 2017 at 1:40
  • 1
    you surely can use socat (not netcat) to punch the hole, then connect ssh to it (to localhost). eg: on one side (the "server" side, so host1) : socat TCP4-CONNECT:cgnatedhost2:cgnatedport2,bind=outgoingip1:outgoingport1 TCP4-CONNECT:localhost:22 on the "client" side socat TCP4-CONNECT:cgnatedhost1:cgnatedport1,bind=outgoingip2:outgoingport2 TCP4-LISTEN:2222 and on the "client" you'd connect with ssh -p 2222 user1@localhost (and if the port 2222 is never used for something else, modern ssh will remember the correct remote hostid, so no need for NoHostAuthenticationForLocalhost) Commented Nov 29, 2017 at 0:05

1 Answer 1

Reset to default
0

Not exactly what you need, however: You may expose host1 or host2 reversed local port as an external port using iptables. So let's say you connected your host2 as ssh reversed tunnel:

user2@host2 $ ssh -R 9999:localhost:22 [email protected]

Now you may forward the incoming port aws.com:9999 to aws [localport:9999]: On AWS server:

[email protected] # iptables -t nat -I PREROUTING -p tcp --dport 9999 -j DNAT --to 127.0.0.1:9999

And now you can connect from host2 to host1 this way:

user1@host1 $ ssh [email protected] -p 9999

Bingo. You connected this way:

[host 1] --> [aws:port 9999] --> [aws: reversed tunnel on 127.0.0.1:9999] --> [host 2]

You should remove the iptable record when this connection not used anymore:

[email protected] # iptables -t nat -A PREROUTING -p tcp --dport 9999 -j DNAT --to 127.0.0.1:9999

The downside of this solution is that host2 is exposed to everyone through external port 9999. You still need to enter a password for log-in, however it is exposed.

UPD: you also may need to enable local forwarding:

awsuser@aws # ls echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet

Or instead of enabling it for all interfaces enable only on income interface:

awsuser@aws # ls echo 1 > /proc/sys/net/ipv4/conf/eth0/accept_local
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.