Tripp Lite 0 Idades Manual

							51
Chapter 4: Serial Port, Device and User Configuration
4.6.2  Manually generate and upload SSH keys
Alternately if you have a RSA or DSA key pair you can manually upload th\
em to the Master and Slave Console Servers. 
Note: If you do not already have RSA or DSA key pair and you do not wish to use you will need to create a key pair\
 using ssh-
keygen, PuTTYgen or a similar tool as detailed in Chapter 15.6
To manually upload the key public and private key pair to the Master Cons\
ole Server: 
• Select System: Administration on Master’s Management Console
•  Browse to the location you have stored RSA (or DSA) Public Key and upload it to SSH RSA (DSA) Public Key 
•  Browse to the stored RSA (or DSA) Private Key and upload it to SSH RSA (DSA) Private Key
• Click Apply
 
Next, you must register the Public Key as an Authorized Key on the Slave.  In the simple case with only one Master with 
multiple Slaves, you need only upload the one RSA or DSA public key for \
each Slave.  
Note: The use of key pairs can be confusing as in many cases one file (Pu\
blic Key) fulfills two roles – Public Key and 
Authorized Key.  For a more detailed explanation refer the Authorized Keys section of Chapter 15.6.  Also refer to this 
chapter if you need to use more than one set of Authorized Keys in the S\
lave 
• Select System: Administration on the Slave’s Management Console
•  Browse again to the stored RSA (or DSA) Public Key and upload it to Slave’s SSH Authorized Key  
• Click Apply
The next step is to Fingerprint each new Slave-Master connection. This once-off step will validate that\
 you are establishing an 
SSH session to who you think you are. On the first connection the Slave\
 will receive a fingerprint from the Master which will be 
used on all future connections:
•  To establish the fingerprint first log in the Master server as root a\
nd establish an SSH connection to the Slave remote host:
 # ssh remhost
Once the SSH connection has been established you will be asked to accept the key. Answer yes and the fingerprint will be 
added to the list of known hosts. For more details on Fingerprinting refer Chapter 15.6 
•  If you are asked to supply a password, then there has been a problem wit\
h uploading keys.  The keys should remove any 
need to supply a password  
						

							52
Chapter 4: Serial Port, Device and User Configuration
4.6.3  Configure the slaves and their serial ports
You can now begin setting up the Slaves and configuring Slave serial po\
rts from the Master Console Server:
  
• Select Serial & Network: Cascaded Ports on the Master’s Management Console: 
•  To add clustering support select Add Slave 
Note: You will be prevented from adding any Slaves until you have automatically\
 or manually generated SSH keys
To define and configure a Slave:
•  Enter the remote IP Address (or DNS Name) for the Slave Console Server 
•  Enter a brief Description and a short L abel for the Slave (use a convention here that enables effective management\
 of 
large networks of clustered Console Servers and the connected devices)
•  Enter the full number of serial ports on the Slave unit in Number of Ports 
• Click Apply. This will establish the SSH tunnel between the Master and the new Slave
The Serial & Network: Cascaded Ports menu displays all the Slaves and the port numbers that have been allocat\
ed on the 
Master. If the Master Console Server has 16 ports of its own then ports 1-16 a\
re pre- allocated to the Master, so the first 
Slave added will be assigned port number 17 onwards.
Once you have added all the Slave Console Servers, the Slave serial port\
s and the connected devices are configurable and 
accessible from the Master’s Management Console menu; and accessible \
through the Master’s IP address e.g. 
•  Select the appropriate Serial & Network: Serial Port and Edit to configure the serial ports on the Slave
•  Select the appropriate Serial & Network: Users & Groups to add new users with access privileges to the Slave serial 
ports (or to extend existing users access privileges)
•  Select the appropriate Serial & Network: Trusted Networks to specify network addresses that can access nominated 
Slave serial ports 
•  Select the appropriate Alerts & Logging: Alerts to configure Slave port Connection, State Change or Pattern Match alerts 
•  The configuration changes made on the Master are propagated out to all\
 the Slaves when you click Apply. 
4.6.4   Managing the slaves
The Master is in control of the Slave serial ports. So for example if ch\
ange a User access privileges or edit any serial 
port setting on the Master, the updated configuration files will be sent out to each Slave in \
parallel. Each Slave will then 
automatically make changes to their local configurations (and only ma\
ke those changes that relate to its particular serial 
ports). 
You can still use the local Slave Management Console to change the settin\
gs on any Slave serial port (such as alter the baud 
rates). However these changes will be overwritten next time the Master \
sends out a configuration file update.
Also while the Master is in control of all Slave serial port related fun\
ctions, it is not master over the Slave network host 
connections or over the Slave Console Server system itself. 
So Slave functions such as IP, SMTP & SNMP Settings, Date &Time, DHCP server must be managed by acces\
sing each Slave 
directly and these functions are not over written when configuration c\
hanges are propagated from the Master. Similarly the 
Slaves Network Host and IPMI settings have to be configured at each Sl\
ave. 
Also the Master’s Management Console provides a consolidated view of \
the settings for its own and all the Slave’s serial ports, 
however the Master does not provide a fully consolidated view. For example if you want to find out who's logged in to cascaded 
serial ports from the master, you’ll see that Status: Active Users only displays those users active on the Master’s ports, so you 
may need to write custom scripts to provide this view. This is covered in Chapter 11.   
						

							53
Chapter 4: Serial Port, Device and User Configuration
4.7 Serial Port Redirection 
Tripp Lite’s VirtualPort software delivers the virtual serial port technology your Windows applications need to open remote serial 
ports and read the data from serial devices that are connected to your C\
onsole Server.   
 
VirtualPort is supplied with each B096-016 / B096-032 / B096-048 Console Server Man\
agement Switch or B092-016 
Console Server with PowerAlert or B095-003-1E-M / B095-004-1E Console Server. 
You are licensed to install VirtualPort on one or more computers for accessing any serial device connected to a\
ny Tripp Lite 
Console Server port. 
4.7.1   Install VirtualPort client
VirtualPort is fully compatible with 32-bit and 64-bit versions of Windows NT 4.x, Windows XP, Windows 2000, Windows 2003, 
Windows 2008, Windows Vista and 64-bit and Windows 7. The installation process is simple.
• The virtualport_setup.exe program is included on the CD supplied with your Console Server (or a c\
opy can be freely 
downloaded from the ftp site.) Double click the VirtualPort_setup.exe file to start installation process
 
•  Read the License Agreement then follow the prompts to select the destina\
tion path and choose shortcuts you wish to 
create  Once the installer completes you will have a working VirtualPort client installed on your machine and an icon on 
your desktop
•  Click the VirtualPort icon on your desktop to start the client  
						

							54
Chapter 4: Serial Port, Device and User Configuration
4.7.2  Configure the VirtualPort client
Creating the VirtualPort client connection will initiate a virtual serial port data redirecti\
on to the remote Console Server using 
TCP/IP protocol
•  Click on Add Ports
•  Specify a name to identify this connection in the "Server Description " \
tab 
 
•  Enter the Console Server's IP address (or network name)
•  Enter the Server TCP Port number that matches the port you have configured for the serial device\
 on the remote Console 
Server. Ensure this port isn't blocked by firewall
  o Telnet RFC2217 mode is configured by default so the range of port numbers available \
on a 16 port console server  
    would be 5001-5016
 o Alternately check RAW mode (4001- 4048 on a 48 port console server)
  o Select Encrypted to enable SSL/TLS encryption of the data going to the port. You will need to enter a Password 
•  Select the starting COM port (COM1 to COM4096)
•  Specify the number of ports you want to add. Sequential port numbers wil\
l be assigned automatically however if a COM 
port # is already being used by other applications that # will be skippe\
d
• Click OK to add the specified COM ports  
						

							55
Chapter 4: Serial Port, Device and User Configuration
 
•  To configure a COM port you have created simply click on the desired CO\
Mx label in the left hand menu tree
•  In the Properties window you can edit the IP Address or TCP Port to be used to connect to that COM port
•  You can then configure the COM port in the Connection and Advanced wind\
ows:
 
• Connect at system startup—When enabled VirtualPort will try to connect to the Console Server when the VirtualPort 
service starts (as opposed to waiting for the application to open the s\
erial port before initiating the connection to the 
Console Server)
• The Time between connection retries specifies the number of seconds between TCP connection retries after a client-
initiated connection failure. Valid values are 1-255 (The default is 1 second and VirtualPort will continue attempting to 
reconnect forever to the Console Server at this interval)
• The Send keep alive packets option tests if the TCP connection is still up when no data has been sent for a while by 
sending keep-alive messages. Select this option and specify period of ti\
me (in milliseconds) after which VirtualPort sends 
a command to remote Console Server end in order to verify connection's i\
ntegrity and keep the connection alive
• The Keep Alive Interval specifies the number of seconds to wait on an idle connection before \
sending a keep-alive 
message. The default is 1 second. The Keep Alive Timeout specifies how long VirtualPort should wait for a keep alive 
response before timing out the connection.
• Disable Nagle Algorithm — the Nagle Algorithm is enabled by default and it reduces the number\
 of small packets sent by 
VirtualPort across the network  
						

							56
Chapter 4: Serial Port, Device and User Configuration
 
• Check Receive DSR/DCD/CTS changes if the flow control signal status from the physical serial port on Co\
nsole Server is to 
be reflected back to the Windows COM port driver (as some serial communications applications pref\
er to run without any 
hardware flow control i.e. in “two wire” mode) 
• The Propagate local port changes allows complete serial device control by the Windows application so it operates exactly 
like a directly connected serial COM port. It provides a complete COM po\
rt interface between the attached serial device 
and the network, providing hardware and software flow control. So the \
baud rate of the remote serial port is controlled by 
the settings for that COM port on Windows computer.  If not selected then the port serial configuration parameters are s\
et 
on the Console Server. 
•  With the Emulate Baud Rate selected VirtualPort will only send data out at the baud rate configured by the local 
Application using the COM port
4.7.3  To remove a configured port
At any stage you can delete a single configured COM port, or delete th\
e Console Server connection (and all the COM ports 
configured on that Console Server) 
•  Select the console server or COM port on the left hand menu and click th\
e Remove button
4.7.4  Configure the remote serial device connection
Ensure the remote serial device is connected to your remote Console Server. Then configure the serial port as detailed in the 
User Guide
•  Set the RS232 Common Settings (e.g. baud rate)
•  Select Console server mode and specify the appropriate protocol to be us\
ed: 
 o RAW TCP allows connections directly to a TCP socket  and the default TCP port address is 4000 + serial port #    
    (i.e. the address of the second serial port is IP Address _ 4002) 
 o RFC2217 enables serial port redirection on that port and the default port addre\
ss is IP Address _ Port (5000 +    
   serial port #) i.e. 5001 – 5048 on a 48 port Console Server  
						

							57
Chapter 4: Serial Port, Device and User Configuration
4.8 Managed Devices 
Managed Devices presents a consolidated view of all the connections to a\
 device that can be accessed and monitored through 
the Console Server. 
To view the connections to the devices:
• Select Serial&Network: Managed Devices 
This will display all the Managed Device with their Description/Notes an\
d lists of all the configured Connections:
• Serial Port # (if serially connected) or 
• USB (if USB connected)
• IP Address (if network connected)
• Power PDU/outlet details (if applicable) and any UPS connections 
Devices such as servers will commonly have more than one power connectio\
ns (e.g. dual power supplied) and more than one 
network connection (e.g. for BMC/service processor).
All users can view (but not edit) these Managed Device connections by \
selecting Manage: Devices. The Administrator can edit 
and add/delete these Managed Devices and their connections. 
To edit an existing device and add a new connection: 
• Select Edit on the Serial&Network: Managed Devices and click Add Connection  
•  Select the connection type for the new connection (Serial, Network Host\
, UPS or RPC) and then select the specific 
connection from the presented list of configured unallocated hosts/por\
ts/outlets
 
To add a new network connected Managed Device:
•  The Administrator adds a new network connected Managed Device using Add Host on the Serial&Network:  Network Host 
menu. This automatically creates a corresponding new Managed Device (as\
 covered in Section 4.4 - Network Hosts)
•  When adding a new network connected RPC or UPS power device, you set up \
a Network Host, designate it as RPC or 
UPS, then go to RPC Connections (or UPS Connections) to configure the relevant connection. Again corresponding 
new Managed Device (with the same Name /Description as the RPC/UPS Host\
) is not created until this connection step is 
completed (refer Chapter 8 - Power and Environment)  
						

							58
Chapter 4: Serial Port, Device and User Configuration
To add a new serially connected Managed Device:
•  Configure the serial port using the Serial&Network:  Serial Port menu (refer Section 4.1 -Configure Serial Port)
• Select Serial&Network: Managed Devices and click Add Device 
•  Enter a Device Name and Description for the Managed Device
• Click Add Connection and select Serial and the Port that connects to the Managed Device 
• To add a UPS/RPC power connection or network connection or another serial\
 connection click Add Connection
• Click Apply   
Note: To set up a new serially connected RPC UPS or EMD device, you configure\
 the serial port, designate it as a Device 
then enter a Name and Description for that device in the Serial & Network: RPC Connections (or UPS Connections or 
Environmental). When applied, this will automatically create a corresponding new Man\
aged Device with the same Name /
Description as the RPC/UPS Host (refer Chapter 8 - Power and Environment) 
Also all the outlet names on the PDU will by default be “Outlet 1”\
 “Outlet 2”. When you connect an particular Managed Device 
(that draws power from the outlet) they the outlet will then take up t\
he name of the powered Managed Device
4.9  IPsec VPN
The Console Servers include Openswan, a Linux implementation of the IPsec (IP Security) protocols, which can be used to 
configure a Virtual Private Network (VPN).  The VPN allows multiple \
sites or remote administrators to access the Console 
Server (and Managed Devices) securely over the Internet.
• The administrator can establish an encrypted authenticated VPN connectio\
ns between Console Servers distributed at 
remote sites and a VPN gateway (such as Cisco router running IOS IPsec) on their central office network:
  o Users and administrators  at the central office can then securely acce\
ss the remote console servers and  
    connected serial console devices and machines on the Management LAN subn\
et at the remote location as  
   though they were local
 o With serial bridging, serial data from controller at the central office\
 machine can be securely connected to the  
    serially controlled devices at the remote sites (refer Chapter 4.1)
• The road warrior administrator can use a VPN IPsec software client such as TheGreenBow (www.thegreenbow.com/vpn_
gateway.html)  or Shrew Soft (www.shrew.net/support ) to remotely access the Console Server and every machine \
on the 
Management LAN subnet at the remote location
Configuration of IPsec is quite complex so Tripp Lite provides a simple GUI interface for basic set up as described \
below. 
However for more detailed information on configuring Openswan IPsec at the command line and interconnecting with other 
IPsec VPN gateways and road warrior IPsec software refer http://wiki.openswan.org
4.9.1  Enable the VPN gateway
• Select IPsec VPN on the Serial & Networks menu 
• Click Add and complete the Add IPsec Tunnel screen
• Enter any descriptive name you wish to identify the IPsec Tunnel you are adding such as WestStOutlet-VPN
   
						

							59
Chapter 4: Serial Port, Device and User Configuration
• Select the Authentication Method to be used, either RSA digital signatures or a Shared secret (PSK) 
  o If you select RSA you will asked to click here to generate keys. This will generate an RSA public key for the  
    console server (the Left Public Key).  You will need to find out the key to be used on the remote gateway, then cut  
   and paste it into the Right Public Key  
 o If you select Shared secret you will need to enter a Pre-shared secret (PSK). The PSK must match \
the PSK  
    configured at the other end of the tunnel
• In Authentication Protocol select the authentication protocol to be used. Either authenticate as p\
art of ESP 
(Encapsulating Security Payload) encryption or separately using the AH (Authentication Header) protocol. 
• Enter a Left ID and Right ID. This is the identifier that the Local host/gateway and remote host/g\
ateway use for IPsec 
negotiation and authentication. Each ID must include an ‘@’ and ca\
n include a fully qualified domain name preceded by 
‘@’ ( e.g. [email protected]  ) 
• Enter the public IP or DNS address of the gateway device connecting it t\
o the Internet as the Left Address. You can leave 
this blank to use the interface of the default route  
						

							60
Chapter 4: Serial Port, Device and User Configuration
• In Right Address enter the public IP or DNS address of the remote end of the tunnel (on\
ly if the remote end has a static 
or dyndns address). Otherwise leave this blank 
• If the VPN gateway is serving as a VPN gateway to a local subnet (e.g. \
the Console Server has a Management LAN 
configured) enter the private subnet details in Left Subnet. Use the CIDR notation (where the IP address number is 
followed by a slash and the number of ‘one’ bits in the binary not\
ation of the netmask). For example 192.168.0.0/24 
indicates an IP address where the first 24 bits are used as the networ\
k address. This is the same as 255.255.255.0. If 
the VPN access is only to the console server itself and to its attached \
serial console devices then leave Left Subnet blank 
• If there is a VPN gateway at the remote end, enter the private subnet de\
tails in Right Subnet. Again use the CIDR 
notation and leave blank if there is only a remote host 
• Select Initiate Tunnel if the tunnel connection is to be initiated from the Left console serve\
r end. This can only be 
initiated from the VPN gateway (Left) if the remote end was configur\
ed with a static (or dyndns) IP address 
• Click Apply to save changes 
Note: It is essential the configuration details set up on the Console Serv\
er (referred to as the Left or Local host) exactly 
matches the set up entered when configuring the Remote (Right) host/\
gateway or software client. 
4.10 OpenVPN 
Console Servers also include OpenVPN which is based on TSL (Transport Layer Security) and SSL (Secure Socket Layer).   
With OpenVPN, it is easy to build cross-platform, point-to-point VPNs usi\
ng x509 PKI (Public Key Infrastructure) or custom 
configuration files.    
OpenVPN allows secure tunneling of data through a single TCP/UDP port over an unsecured network, thus providing secure 
access to multiple sites and secure remote administration to a console s\
erver over the Internet.  
OpenVPN also allows the use of Dynamic IP addresses by both the server a\
nd client thus providing client mobility. For example, 
an OpenVPN tunnel may be established between a roaming windows client an\
d a Console Server within a data centre. 
Configuration of OpenVPN can be complex so Tripp Lite provides a simple GUI interface for basic set up as described \
below. 
However for more detailed information on configuring OpenVPN Access se\
rver or client refer to the HOW TO and FAQs at  
http://www.openvpn.net