Difference between revisions of "SSH/Tunneling"

From braindump
Jump to navigation Jump to search
Line 31: Line 31:
As soon as you bring the interface up you should see traffic going via the tunnel.
As soon as you bring the interface up you should see traffic going via the tunnel.
==== Explanation ====
==== Explanation ====
This hack is kind is using a trick used by load-balancers where a host in an internal RFC 1918 network has to respond to requests from global IP address. But in this case the traffic is not inbound like with load-balancers but outbound. Creating the <tt>lo:1</tt> will route the traffic destined for the IP address locally. When traffic hits the localloop interface and the destination port <tt>ssh</tt> will pick it up and send it to the jump host from there it will be sent to the final destination. There is one caveat if there is more traffic to same destination host on other ports this hack will break the rest of the traffic unless more tunnels are created.
This hack is kind is using a trick used by load-balancers where a host in an internal RFC 1918 network has to respond to requests from global IP address. But in this case the traffic is not inbound like with load-balancers but outbound. Creating the <tt>lo:1</tt> will route the traffic destined for the IP address locally. When traffic hits the local loop interface and the destination port <tt>ssh</tt> will pick it up and send it to the jump host from there it will be sent to the final destination. There is one caveat if there is more traffic to same destination host on other ports this hack will break the rest of the traffic unless more tunnels are created.

Revision as of 00:13, 30 June 2012


Advanced

Tunneling using the actual destination IP

Disclaimer: Don't use this on a production machine unless you fully grasp the mechnism.

Problem

Create a tunnel on a machine where an application is supposed to connect to a host that has been blocked by a firewall. Condition you can not change configuration and restart the application using the connection.

Solution

Asuming the target to connect to is 1.2.3.4 on port 56789 and we use 4.3.2.1 as the jump host. Before starting sshd has to accept remote forwards on all interfaces and IP addresses. To do that on the host running actual application the /etc/ssh/sshd_config file requires the AllowTcpForwarding and GatewayPorts to be set to yes

AllowTcpForwarding yes
GatewayPorts yes

HUPing the sshd process will enable the new configuration. With ssh this out of the way connection to the host in question.

ssh <JumpHost> -R <LocalPort>:<DestinationIP>:<DestinationPort>
ssh 4.3.2.1 -R 56789:1.2.3.4:56789

On the application host create an interface on the lo interface with this address with the traditional ifconfig it looks like below.

ifconfig lo:1 <DestinationIP> netmask 255.255.255.255 broadcast <DestinationIP> up
ifconfig lo:1 1.2.3.4 netmask 255.255.255.255 broadcast 1.2.3.4 up

With the ip command on linux this is how it looks like. Note: label lo:1 is optional.

ip addr add <DestiantionIP>/32 brd + label lo:1 dev lo
ip addr add 1.2.3.4/32 brd + label lo:1 dev lo

As soon as you bring the interface up you should see traffic going via the tunnel.

Explanation

This hack is kind is using a trick used by load-balancers where a host in an internal RFC 1918 network has to respond to requests from global IP address. But in this case the traffic is not inbound like with load-balancers but outbound. Creating the lo:1 will route the traffic destined for the IP address locally. When traffic hits the local loop interface and the destination port ssh will pick it up and send it to the jump host from there it will be sent to the final destination. There is one caveat if there is more traffic to same destination host on other ports this hack will break the rest of the traffic unless more tunnels are created.