In many CUBiT deployments the client nodes that are provisioned by developers and users are protected by the CUBiT manager that acts as a firewall preventing inbound network traffic. This is the default configuration of a SAAS-based CollabNet CUBiT deployment and is depicted in diagram 1.
Diagram 1 - Isolated-Access Mode
This is the ideal deployment when security is paramount and is termed "Isolated-Access". Client nodes are provisioned on their own private subnet that is managed by CUBiT. To access client nodes in this deployment mode requires a network configuration that will securely tunnel through the CUBiT manager firewall. The following technologies later in this article will be covered in depth, all of which can provided network connectivity to client nodes but will different advantages and disadvantages.
- SSH Tunneling
- Port Forwarding
- Host URL remapping
Before we discuss those technologies it is wise to discuss how to provided network access at a higher level, i.e. at the design stage, by planning correctly up front we can eliminate a great deal of unnecessary work at a later stage. CUBiT can support three modes of network deployment one of which we have already mentioned, "Isolated-Access", the others are "Direct-Access" (diagram 2) and "Mixed-Access" a hybrid of the two (diagram 3).
Diagram 2 - Direct-Access Mode
Unlike "Isolated-Access" in this environment there is only one subnet (can be a VLAN) that is managed by CUBiT. Users can access their client nodes directly from their enterprise network without any specialized network configuration. This type of configuration is ideal within an enterprise network whereby network level security is already provided by corporate firewalls.
Diagram 3 - Mixed-Access Mode with LOM (Lights Out Management) Network
In this mode CUBiT is connected and manages multiple subnets, (1) a Direct-Access network (2) an Isolated-Access network and (3) a Lights Out Management network. This mode is consider the most flexible of all methods as it is possible to development systems within the security boundaries of an "Isolated" network and when required the client node can be move to a physical system that is connected to the "Direct-Access" network allow testing and access from systems that would not normally have direct connectivity.
How to access client nodes within an "Isolated-Access" mode deployment Using SSH Tunneling
SSH (Secure Shell) is an Open Source network protocol that allows data to be exchanged over a secure channel between two computers. It is used extensively for encrypted remote access to UNIX based operating system and has many features. If you need more information then visit
http://en.wikipedia.org/wiki/Secure_Shell
http://www.openssh.org
This article will limit the discussion to tunneling other protocols within the SSH network protocol.
Advantages
- Secure - Data is encrypted
- Can be independently configured by user
- Any protocol an be tunneled
Disadvantages
- Is a point to point solution between client node and user workstation
- Tunnel is not persistent after reboots and have to be re-established
- Can be difficult to configure on a Windows client node
- Can be difficult to tunnel protocols using UDP
There are many SSH clients available, Open Source and commercial. A very popular client that is freely available to download is "Putty" http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. This article will show you how to configure putty for SSH tunneling. The concept is that a tunneling rule establishes a connection between your local workstation and a destination system. Within that connection common protocols can be tunneled. In our example the tunnel will pass through the CUBiT manager that is protecting the "Isolated" subnet.
Requirements for successful configuration of an SSH tunnel:
- Valid userid and password on CUBiT Manager
- Valid userid and password on client node
- Installation of the Putty client
The SSH tunnel will be create from the local workstation via the CUBiT manager. Add the name of the CUBiT Manager in the "Host Name" field and add an identifiable name for the session in "Saved Sessions"
Now go to SSH -> Tunnels
In this example the "Source port" is set to "9022" and the "Destination" is set to "cu018.demo.cubitdemo.net:22". When a connection is establish to the local workstation on "localhost port 22" the connection is forward in a encrypted tunnel to "cu018.demo.cubitdemo.net port 22" via the CUBiT manager "mgr.cubit.example.com". The protocol that is forwarded in this example is SSH, i.e. port 22. Other useful protocols that can be forwarded are:
- Windows Remote Desktop Protocol - TCP 3389
- VNC (Virtual Network Computing) - TCP 5900 or 5901
Virtually any protocol using TCP can be tunneled securely with SSH.
Save your session by selecting "Session" and "Save" and click "Open" to establish tunnel. You will be prompted for your userid and password for "mgr.example.cubit.com". If successful you will see the following screen.
The tunnel is now established
The next step is to open a SSH connection to "localhost port 9022". You will be prompted for your userid and password for the client node "cu018.demo.cubitdemo.net"
Once successfully authenticated you will see the following
Using Port Forwarding
Port Forwarding is similar to SSH tunneling in that the CUBiT Manager will forward the connection to the client node; however there are some very distinct differences.
Advantages
- Opens a UDP/TCP port to a client node globally, i.e. a many to point connection
- Port Forwarding is persistent after reboots
- It is simple to configure clients to support Port Forwarding
Disadvantages
- Security - unless the forwarded protocol provided encryption the Port Forwarding will not encrypt data like SSH
- Security implication with globally accessible UDP/TCP ports
- Has to be configured by a CUBiT domain administrator
The basic concept is that a firewall rule is added on the CUBiT Manager that will forward network data inbound to the manager on a defined port to a client node and port in the isolated networks. CUBiT provides configuration of Port Forwarding from its management interface which requires domain administrator authority.
Administration -> Port Forwarding
In this example there are two Port Forwarding rules.
- Connections to CUBiT Manager (sc74.sjc.collab.net) on TCP port 7000 will be forward to the client node cu011.demo.cubitdemo.net TCP port 1212. However the rule is disabled.
- Connections to CUBiT Manager (sc74.sjc.collab.net) on TCP port 6998 will be forward to the client node cu013.demo.cubitdemo.net TCP port 2323. The rules is enabled.
A working example of using Port Forward would be if you have a web application that requires testing from users that have no direct access to the client node that the application is running on, i.e. the CUBiT environment is using "Isolated -Access" deployment. By adding a Port Forwarding rule for HTTP (TCP port 80), all users could access the web application.
Using Host URL Mapping
Using CUBiT’s Host URL Mapping will allow you to expose a web application on a client node that is hosted with a CUBiT isolated network. Unlike Port Forwarding that forwards the connection at the TCP layer URL Mapping works at the application protocol layer and it’s not require to define a separate external port. Host URL Mapping also provides a consistent URL interface to a web-based service that can be easily moved between different hosts.
Advantages
- Consistent URL that uses standard HTTP protocol
- Configuration is persistent after reboot
- Easy for users to use, standard HTTP URL
Disadvantages
- Has to be configured by CUBiT domain administrator
- Have to consider security implications of exposing a web application globally.
Administration -> Host URL Mapping
In this example, the web application that resides on the internal client node http://cu012.demo.cubitdemo.net/archiva is accessible externally from http://sc74.sjc.collab.net/apps/archiva
