Raktbeej Proxy

All we could think of imagining a routine day of a NOC guy is looking at all the fancy and colorful multiple screens around, but is this all it?

The answer to the above statement is NO! As a NOC, We have access to the information that is critical to analyze and plot company infra strength and on top of that, access to the servers and protected network makes the situation more critical if thing happens to be in wrong hands.

To support the NOC system, team needs to have access on protected networks in a distributed infrastructure. This could lead to a scenario where every member of the NOC team has its own pair of access keys which may further complicate the access management and make the system more vulnerable.

Here, we are with a solution to unify ever discrete pieces of loosely coupled security, audit and access to our clients most critical and vulnerable information through a single window and since the architecture is more like a micro-service shot of concept it could give us an easily plug-able environment. We call it RAKTBEEJ PROXY. 

Solution We Designed

Binding and building all the dependencies into a single environment can’t be better explained than the concept of containerization. RAKTBEEJ PROXY inspired by the same philosophy is the coagulation of such pre-configured containers where each one of them represents an identity of our single client, guarded by a single-window entrance like SSO powered by tools like KeyCloak which allow only the very legitimate users in.

Challenges faced

  • Multi VPN support 
  • Nested virtualization of LAN adapters
  • Single Sign ON mechanism
  • Managed proxy traffic redirection
  • Audit and logging user access 
  • Automated pipeline for creating clients specific containers.
  • Orchestrate container deployment and rollbacks

Why can’t I connect two or more vpn at the same time?  

Let’s assume if  VPN1 and VPN2 connect the same time or broadcast a route for the same subnet, which does not correspond to the same physical hosts? E.g., you have two Client infra with the exact same configuration Client1 Running some service in address 192.168.0.100.

VM as Solution:- So we decided to use the Isolate environment to perform this task so we started using VM to connect two vpn. But in the VM as the main issue. Memory usage and performance is still a big problem in this approach.

Containers as Solution:- So containers that have lightweight and isolated environments will solve our problem. I decided to go with the container.

Architecture

We used Nginx as Front-end for Path base routing. If we have to connect the VPN1 service, then requests are proxied through the docker container for VPN1. Inside each of the docker containers, a VPN client service is running which is creating a private secure tunnel to its respective VPN server.

Sample Front-End Nginx Config:-

      location /service1/ {                                                     
           proxy_pass          http://vpn1/;       
       
        }

In the above config, we redirect request to VPN1 Docker container.

In every container also has an Nginx running for route internal requested forward page.

Sample Internal Nginx Config:-

   server {                                                                 
        listen       80  default_server;                                     
        listen       [::]:80  default_server;                                
        server_name  localhost;                                              
        root         /usr/share/nginx/html;                              
                                                                         
                                                                         
        # Load configuration files for the default server block.         
#        include /etc/nginx/default.d/*.conf;                             
                                                                         
        location / {                                                     
           auth_basic "Restricted Content";
           auth_basic_user_file /etc/nginx/.htpasswd;
           proxy_pass          http://192.168.1.100/service1/;       
       
 }                                                                

after a request receives to container internal Nginx forward the request.

For a single SSO solution, I have integrated Gmail OAuth for authorization by an authenticated user.

 

In a couple of days, we hope to OpenSource this solution!

Happy Blogging!

 

Opstree is an End to End DevOps solution provider

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s