"Home office", or when you do not need to go to work

    "Home office", or when you do not need to go to work



    I have long dreamed about it, and now, finally, it happened! I can work at home and do (almost) everything that I usually do in the office. And I succeeded because I set up the Reverse SSH tunnel on my home server and learned how to manage this tunnel.

    Continued ...

    In the office I have to do this:
    1. work with ORACLE (requests, procedures, etc.) - connection to servers is required (ports 1521, 1527)
    2. work with UNIX (scripts, file copying, etc.) - requires telnet or SSH connection
    3. office mail
    4. communication with colleagues
    5. viewing Habr and other interne places


    Due to the fact that my home provider provides me with direct IP, and thanks to the courtesy of our network administrators at work, I have access to home from a working machine. I take this opportunity to access work from home laptops (I have 3 of them) via VNC , as well as to copy files to and from the home server. Of course, at the entrance there is a router with NAT and other bells and whistles, which allows me to live beautifully throttling incoming connections.

    But I do not have access from home to a working machine. The company’s security policy does not allow. VPN and other things (for now) are missing. Mom, mom, what will I do? Ku!

    We set the task: to provide work on items (1-5) from home. At work - Windows, the working computer does not turn off. At home, there is a Linux -based NSLU2 server . Apache is running on the server; its logs are available for reading and analysis.

    Items 3, 4, and 5 are accessible from home using a telephone, browser, and chat agent. But 1 and 2 in the usual way - no way.

    And then a “sweet couple” enters the scene - Putty from the side of the working machine (hereinafter referred to as the client) and sshd from the side of the home server (hereinafter referred to as the server). Typically, the client opens a connection to the server via SSH and establishes a secure "tunnel". The initiator of the “there” connection is always the client.

    I will not describe all the features of SSH - we are only interested in one of them. It is possible to establish the so-called “reverse tunnel” - this means that the server sends data to the specified client port, and the client can send this data further on its network.

    What do we get by installing a “reverse tunnel”? And we will get access through this tunnel from the home network to the working one, i.e. the ability to work with all servers that are usually accessible only from the production network. You only need to correctly configure the tunnel — which server ports lead to which client addresses and ports. This is done in the Putty settings when describing the connection.

    Keeping such a tunnel constantly is not possible: communication breaks, and it is not always needed. The solution is to install the tunnel as needed (after drinking coffee at home and finally deciding to work). Yes, but nobody is at work? Who will run Putty to raise the connection? Like who? Grandfather Fihto of course. The working computer itself will start, you just need to ask for it. But how? A working computer should read my thought “I want a connection to be established” and execute it.

    The rest is only to learn how to materialize your thoughts and teach the working computer to understand them. And then everything is simple.

    I decided to materialize my thought into a regular text file. Yes, the thought should be simple and short. Up! And the tigers sat at my feet. - In the sense, "UP" - to raise the connection. “DN” - omit the connection. Briefly and clearly.

    The client-server scenario looks like this:
    1. We create a file (let's call it a cmd file) with one line of text (a command) and put it on our home page so that the working computer can read and process the command.
    2. We are waiting for the working computer to read the command (watching the Apache logs). When a GET request arrives to download the cmd file from the working address, we can say that our command is received.
    3. The working computer executes the UP command (raises the connection) or DN (breaks it).
    4. After executing the command, the working computer requests from the home page a cmd file with the additional parameter "? ANS". Having received a GET, we can say that our team was successful.


    The rest is to automate all the processes on the client side (at the office) and on the server side (at home) - that's all, you can smoke bamboo to work from home.

    The script for the client consists of a front-end (always running) and a back-end (launched to execute the command), there is only one script for server-side management .

    To make it work, you should run the front-end script on a working computer, and you can go home. By launching a script at home on the server and specifying the UP command , we will receive confirmation in 1-2 minutes that the command has been completed. Everything, you can start working with production servers as if they were on a home network. When the work is completed, specify the DN commandand everything will turn off.

    If the connection is disconnected, then it will automatically rise after a couple of minutes by a working computer. If the connection seems to exist, but does not work, then you should run the DN command and after a couple of minutes - the UP command .

    Future plans include setting up a PSTN <-> VoIP gateway so that a work phone is available at home. Well, and, as usual, the ultimate goal is the capture of the universe.

    Also popular now: