The Layers of Remote Access
-
Many things in IT come in layers and remote access to a server is no exception. We have many layers at which we can access a machine and interact with it. Understanding what components work at what layer is important in knowing what we can use to troubleshoot or interact at what time.
There are four key layers that we expect in a typical server installation:
- In OS Session
- Via OS Console
- Hypervisor Console
- Hardware Console / IPMI
Each of these layers plays an important role and needs to be understood both for administrators working on existing systems as well as engineers designing systems for reliable maintenance. Each layer has its own features, fragilities, risks and dependencies. While most of these are well understood, rarely do we step back and really consider them as a access stack with hooks into different layers.
In OS Session: This is the layer at which we work the majority of the time. This layer is provided from inside of the operating system and involves session management (e.g. multiple users are possible of the OS supports and allows this) and is often thought of as being an "end user" session. We often get the best performance and richest features from this layer. The common protocols of this layer include RDP, ICA (Citrix), SSH, NX and X. This is the only layer that we have traditionally given to end users for non-administrative access. It is the only type designed for multiple users on a terminal server. This is the most fragile layer of the stack with dependencies on the entire OS stack including, but not limited to, networking, sessions, account management and so forth. Basically everything has to be working for this to work.
Via OS Console: Also known as a console redirect, nearly every OS has a concept of a "local console". In most OSes, like Windows, FreeBSD and Linux, this is what you see if you plug in a monitor to the local graphical output of the box. It is single user and is treated different from the OS Session concept, even if OS Sessions are sometimes layered on top of it. The "hook" goes into a layer beneath the sessions. The famous protocol at this layer is VNC, but ScreenConnect, TeamViewer, Bomgar, LogMeIn and others can operate here as well. This layer still depends on the OS for functionality, so broken networking for example will disable it, but it does not depend on sessions, authentication and such. So for a system that is otherwise locked out or access to pre-session portions of the OS is needed this can be critically important to allow for access, repair and control "as if sitting at the console" even to the point of tricking the OS into thinking that you are actually sitting at the console. This is sometimes called a TTY redirect and in some systems actually involves a data stream that may optionally go over a TTY serial interface (common with Solaris, possible with Linux, etc.)
Hypervisor Console: The hypervisor has even more power than the OS based console redirect. The hypervisor has the ability to redirect the physical hardware output, not just the data that the OS intentionally sends to that hardware, over a networking protocol. Like the layer above, VNC is common here but other technologies are available like SPICE and PCoIP. This layer does not depend on a functional OS whatsoever, but does depend on the hypervisor to be working properly in order to be accessed. This layer is commonly used during OS installation processes. This is the first layer that can work with the virtual BIOS of a VM.
Hardware Consoler Redirect or Out of Band Management / IPMI: This is the most powerful and reliable form of access to any system. This layer is a KVMoIP system built directly into the server (and some high end desktops) that allows for the actual output of the hardware local console to be sent remotely. In the HP world, this is known as ILO. In the Dell world, it is known as DRAC. SuperMicro uses the standard term IPMI. In all cases, it is out of band console access. With this layer the server itself need not even be working, only the KVM "card" needs to still work in order for the system to be accessed. This is the only layer that allows for visibility onto the actual BIOS of the physical server itself and the only one that allows for access to, for example, unlock physically encrypted drives.
All of these layers are important at different times. Each needs to be understood, made accessible, protected from unnecessary dependencies (especially cross domain dependencies like tying AD from the session layer into lower layers) and secured on its own. Good practice (if not best practice) is to have standard access to all or nearly all of these layers at all times. Using only one or even two generally leaves us with limited access and curtails disaster management scenarios. At a general minimum, OOB, Hypervisor console and In OS layers should be available for any system deemed production.
