art na do #2

<h2>Introduction</h2>

By reading this article you can learn how to create safe, encrypted tunnel between our computer and your droplet, how to bypass limits in a corporate network, how to bypass NAT etc.</br>
You'll learn theory basics about that, if you like. In the examples you'll see where you can use it.</br>
If you think that you know enough about that, you can jump to examples.<br/><br/>

<h2>Communication in the Internet, network protocols and communication ports</h2>

Every installed on your computer software, that wants to send or receive data through the Internet, has to use any protocol of application layer from TCP/IP stack. Those protocols define a way to communicate, format of messages sent between hosts in the Internet etc. For instance:
<ul>
<li>HTTP - used to download websites and files by your web browser</li>
<li>FTP - used to send files between client and server</li>
<li>DNS - used to change host name into IP address and vice versa</li>
<li>POP3 and (or) IMAP - used to download/browse your e-mail</li>
<li>SMTP - used to send your e-mail</li>
<li>telnet - used to remote work on server's terminal</li>
<li>SSH - it's the same as telnet, but in <b>secure</b>, encrypted version, so nobody can see what we send to a server and what server sends to us.</li>
</ul>

Next, messages of given protocol has to be packed into TCP segment or UDP datagram (in transport layer). Those protocols are used to transport data through the Internet - they are working in transport layer. TCP protocol is connection-oriented, which means that before sending data it is required to create connection between remote machines. TCP always provides data in correct order. If any segment will be lost in the network, it will be send again in case of not receiving confirmation in time. So, because of that, TCP is possibly reliable.<br/><br/>

UDP protocol is not connection-oriented. It doesn't provide retransmissioning lost datagrams. If packets will not be received in correct order, UDP will give them to an application this way. Because of that, UDP is mainly used to transmiss real-time multimedia data - VoIP talks, videoconferences, audio streamings and video. UDP is used sometimes by other protocols in application layer - for instance, DNS. In this case a protocol of higher layer has to take on itself retransmission of given query after not receiving an answer in given time etc. UDP is used here mainly, because it has low overhead: sending 1 small query in 1 datagram and receiving an answer takes so less time and needs to transmiss less data than making a TCP connection (exchanging 3 segment between hosts), sending a query by a client, sending a confirmation by the server, sending an answer by the server, sending a confirmation by a client and disconnecting the connection (4 segments).<br/><br/>

To identify different connections from/to the same IP address, we use port numbers. Each server of given application layer protocol is binding to a given port number and waiting for an incoming connection. Client connects to this port (in case of TCP conn.) or sends a datagram to that port (in case of UDP). For the most used, well-known protocols, there are reserved port numbers. For instance, HTTP server usually listens on port 80 TCP (otherwise clients would have to connect with it by specifying that port number in an address - http://example.org:1234/), DNS server usually listens on port 53 UDP (sometimes port 53 TCP, too). The client needs to use a port on its side, too. They are "high ports" like 52044. They are randomly generated.<br/><br/>

<a href="http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers" alt="More reserved ports here...">Here</a> you can see more reserved ports that we use everyday.<br/><br/>

The segments and datagrams are packed then into IP packets - in network layer. In those packets, an ID of source and target computer are IP addresses. They are global - at the same time only 1 host in the Internet can use the same address (excluding a magic like NAT used in home routers with private IP addresses: 192.168.x.x, 10.x.x.x, 172.16-31.x.x; x is a number between 1 and 255). Routers in the Internet, basing on those addresses, decides, where to send packet to get to the target computer.<br/><br/>

The packets are then packed into frames/cells in data link layer, and then transmitted in a cable or in radio waves form in local network. In the data link layer, in the frames, the IDs of computers are MAC addresses. Frames with MAC addresses are completely deleted on routers which extract packets from them. Then they decide into what network they should send packets, pack them into new frames and send them where they have to be send. If a network between both routers uses MAC addresses, addresses of those routers are included in the frame - the source one and the target one. It's not possible to communicate between two computers in different networks using only MAC addresses, even if they are not repeatable - the producer puts only one address to only one card, so any of the manufactured carts can have the same MAC address as card made by another producer.<br/><br/>

<img src="http://i.imgur.com/3QObugv.jpg" width="500px" alt="TCP/IP (DoD) model" /></br></br>

<img src="http://i.imgur.com/mBPNzIH.png" width="500px" alt="Encapsulation" /><br/><br/>

<h2>About SSH. Theory, part 1</h2>

SSH is a protocol in application layer, as I said. It's a succesor of telnet. It's used for remote working in terminal on your server in text mode. Unlike telnet, SSH is encrypted. Uses port 22 TCP, but you can freely change it in your server's configuration.
It allows user to authenticate himself on many different ways, for example:
-using username and password
-using a pair of keys - first, private (top secret), and second - public (on server): a program that you use to connect with SSH has to solve math problem using a private key and send to server the solution. The problem is different every time, so it's hard to break the key using that authenticate method.
Nowadays we use version 2 of SSH.
The most popular SSH server implementation is OpenSSH. The most popular clients are PuTTY (for Windows) and OpenSSH (for Linux). PuTTY (and OpenSSH too) allows to create tunnels, tunneling windows via x11 using local X server, f.e. xming and has a lot of features.<br/><br/>

SSH allows creating TCP tunnel between server and client and sending data through that tunnel. SSH supports TCP tunnels only, but you can skip that f.e. via SOCKS proxy. A tunnel like that is established between chosen TCP port on server and chosen local port. It's encrypted, of course, so anybody can check what we use it to.<br/><br/>

<h3>Concepts that will be used</h3>

<b>Loopback interface</b> - a virtual network card installed in the system with IP address <i>127.0.0.1</i>. The access to that address have only applications installed in the system. Remote access is not possible. You can start a server on that interface and have a remote access only from the same system or via tunnel.<br/><br/>

<b>SMTP</b> - an application layer protocol that let you sending e-mails. It's used for both communicating between mail servers and communication between a server and a mail client. SMTP uses port 25 TCP to unencrypted communication and port 587 TCP or 465 TCP (deprecated - not recommended) to encrypted connection (SSL).<br/><br/>

<b>POP3</b> - protocol in an application layer used to download new e-mails from server to local mail client. Nowadays it's rarely used, superseded by IMAP. For unencrypted connections it uses 110 TCP port, for encrypted connections - 995 TCP port.<br/><br/>

<b>IMAP</b> - alike POP3, but supports folders, labels, reading and managing messages and folders on server without downloading everything to local PC and deleting it from server. Uses 143 TCP port for unencrypted connections and 993 TCP port for encrypted connections.<br/><br/>

<h2>Example 1. Tunnel to IMAP server</h2>
A tunnel between local port 143 on loopback interface - 127.0.0.1 - and IMAP server for mail receiving (unencrypted connection) on the same remote machine (it has SSH server).<br/><br/>

<h3>Unix and OpenSSH:</h3>

<pre>ssh abc@def -L 110:127.0.0.1:110

abc - username on server
def - server address
110: - local port that will be opened on loopback interface (127.0.0.1) on local machine
127.0.0.1 - IP address of computer that we creating a tunnel to via our SSH tunnel
:110 - port number of target machine we'll get to via tunnel</pre>

<h3>Windows and PuTTY:</h3>

<a href="https://www.digitalocean.com/community/articles/how-to-log-into-your-droplet-with-putty-for-windows-users
" alt="See it!">Here</a> you can read how to create connection to your Droplet using PuTTY. That connection is required to create a tunnel.

<ul>
<li>Choose your connection, load data and go to Connection->SSH->Tunnels and set it like that: <img src="http://screencloud.net/img/screenshots/0a116b96da9f5ded11de4b9112f523b5.png" alt="Yay!"></li>
<li>Click on Add. After that every protocols it should look like that: <img src="http://screencloud.net/img/screenshots/24873f747e8d4782e28360bd25b693bc.png" alt="Yay!"></li>
<li>Now you can save the session and connect using it.</li>
</ul>

Now you can just configure your mail client to connect to server not directly, but using port 110 of loopback interface - 127.0.0.1. You can do the same thing with different protocols - SMTP (25), IMAP (143)...<br/><br/>

<h2>Example 2. Tunnel to a web server</h2>

A tunnel between local port 8080 on 127.0.0.1 and WWW server on binded to remote machine's port 80, but this time we'll connect to it using loopback interface.<br/><br/>

As I said, HTTP protocol is used to download WWW websites by the browser.</br></br>

<h3>Unix and OpenSSH:</h3>

<pre>ssh abc@def -L 8080:11.22.33.44:80

    abc - username on server
    def - server address
    8080: - local port that will be opened on loopback interface (127.0.0.1) on local machine
    11.22.33.44 - IP addres of server that we'll create a tunnel through our SSH server</pre>

<h3>Windows and PuTTY:</h3>

<ul>
<li>Choose connection and load the settings.</li>
<li>Go to Connection->SSH->Tunnels</li>
<li>Set it like that: <img alt="It looks like that" src="http://screencloud.net//img/screenshots/c788de4c03a54a70020b3dacf8701754.png" /></li>
<li>Click on Add: <img alt="It looks like that" src="http://screencloud.net//img/screenshots/f85e0293d5cfed9974d92968d1c83b8a.png" /></li>
<li>Now you can save the session and connect.</li>
</ul>

Theoretically speaking, after going to <i>127.0.0.1:8080</i> in your browser you should see a website located on server we've connected to.<br/>
Practically speaking, HTTP 1.1 introduced <i>Host</i> parameter to a query. That param is used to send a DNS domain name of server we're connecting to. If it uses Virtual Hosts Mechanism, a page you'll get to will be either error page or server's main page (f.e. on hosting pages or redirecting to the right site), but not through the tunnel.<br/>
In that case we have to do one more thing - to the <i>hosts</i> file on local PC, add server address and your loopback:
<pre>127.0.0.1 website</pre>
<i>website</i> is an address to site you connect to (<b>without</b> <i>http://</i> at begining and <i>/</i> at the end).</br></br>

<i>Hosts</i> file is located in /etc/hosts (Linux) or C:\Windows\system32\drivers\etc\hosts (Windows). To edit that file you must be an admistrator or has administrative privileges.<br/><br/>

Important! If you want to create a tunnel on local port numbered less than 1024 on Unix systems, you must have root privileges.<br/></br>

<h2>Example 3. SOCKS proxy</h2>

SOCKS proxy allows sending traffic from any protocols through a tunnel. It looks like 1 TCP connection.<br/>
In this example we'll create a tunnel between SSH server and a client on port 5555 on loopback interface. Next, we'll set a browser to use our SOCKS server as proxy server for every outgoing connections.</br>
That solution might be useful to bypass limits in corporate networks.
If the port that our SSH uses is locked, we can set server to listen on port 443 - <i>Listen</i> option in OpenSSH configuration file (/etc/ssh/sshd_config or /etc/openssh/sshd_config).<br/><br/>

<h3>Unix and OpenSSH:</h3>

<pre>ssh abc@def -D 5555

    abc - username
    def - server address
    5555 - local port number, on which a tunnel will be created</pre>


<h3>Windows and PuTTY:</h3>

<ul>
<li>Choose connection and load the settings.</li>
<li>Go to Connection->SSH->Tunnels</li>
<li>Set it like that: <img alt="It looks like that" src="http://screencloud.net/img/screenshots/8664f5e28f4774e66207315648f4ab15.png" /></li>
<li>Click on Add: <img alt="It looks like that" src="http://screencloud.net/img/screenshots/8664f5e28f4774e66207315648f4ab15.png" /></li>
<li>Save a session and connect to.</li>
</ul>

In your browser settings set SOCKS proxy which works on 127.0.0.1:5555 from now on until you'll close connection in PuTTY or OpenSSH.<br/><br/>

<h2>Example 4. Bypassing NAT</h2>

NAT (specifically PAT, NAT form used in home routers) is a mechanism that allows many people using one internet connection. A router that makes NAT has one public address and changes all private addresses in received packets from internal network to it's public address and sends to the Internet. Back, it makes the opposite - on connecting it remembers IP addresses and port numbers in special NAT table.</br>
A connection from outside is possible only when we'll set appropriate port forwarding on the router. However we can bypass that problem and create a tunnel between out computer and server to connect our computer and server directly.<br/><br/>

<h3>Part 1.</h3>

In the second part we'll create a tunnel between local port 80 (on our computer - local HTTP server) and 8080 remote port (on server). However, because of security reasons, 8080 remote port on server we'll be opened only on loopback interface - <i>127.0.0.1</i>. Because of that we have to reconfigure our server to open connections on every port. We'll do that now.<br/><br/>

<ol>
<li>In your favourite editor open /etc/ssh/sshd_config (or /etc/openssh/sshd_config) file.
<pre>nano /etc/ssh/sshd_config</pre></li>
<li>Find:
<pre>#GatewayPorts no</pre></li>
<li>Change that line to:
<pre>GatewayPorts yes</pre></li>
<li>Save the file and close the editor.</li>
<li>Restart SSHD server:
<pre>Debian/Ubuntu:
service ssh restart
CentOS:
/etc/init.d/sshd restart</li>
</ol>

<h3>Part 2.</h3>

We'll create the tunnel.<br/><br/>

<h3>Unix and OpenSSH:</h3>

<pre>ssh abc@def -R 8080:127.0.0.1:80

    abc - username
    def - server address
    8080 - port number that will be opened on remote server - our proxy server
    127.0.0.1 - IP address we open tunnel to
    80 - port number we open tunnel to</pre>

This time locally, but we can tunnel connection to other computer in the same network with NAT - f.e. as the spy in a corporation ;)</br></br>

<h3>Windows and PuTTY:</h3>

<ul>
<li>Choose connection and load the settings.</li>
<li>Go to Connection->SSH->Tunnels</li>
<li>Set it like that: <img alt="It looks like that" src="http://screencloud.net//img/screenshots/82e68d6ec26056e92e177e20507eeafc.png" /></li>
<li>Click on Add: <img alt="It looks like that" src="http://screencloud.net//img/screenshots/45deae0c8a7259181abf25d4720c3414.png" /></li>
<li>Save a session and connect to.</li>
</ul>

After logging in we can get to our local HTTP server from outside through proxy server with OpenSSH that has a public IP address by opening in a browser <code>http://IP-address-or-domain-of-our-server-change-that-for-your-name:8080/</code>.<br/><br/>

<h2>Theory continued</h2>

As you can see, there are three types of SSH tunnels:
<ul>
<li>Local - <code>-L</code> option - a tunnel is opened on our local port and listens for connections that are redirected by our save connection to SSH server and next to the target host.</li>
<li>Remote - <code>-R</code> option - a tunnel is opened on SSH server. After receiving a connection by server, all transmission is redirected to our local tunnel out.</li>
<li>Dynamic - <code>-D</code> option - a tunnel is opened on a local loopback interface. Transmission takes place through SOCKS protocol. You can tunnel any packets through that - TCP, UDP. It's possible to connect to whichever server in the Internet through out proxy SSH server. To redirect all system traffic through SOCKS proxy, you can use a program like <i>proxifier</i>.</li>
</ul>