Introduction
As your SOHO grows, you'll eventually need to establish some form of secure data link with a supplier, vendor, branch office, business partner, or customer that will enable you to access their servers behind their Internet firewall.
One method of doing this is to create a Virtual Private Network (×××) to provide an encrypted data stream between your firewall and theirs. A ××× is really convenient, because you can refer to the remote servers, not by their public network address translated IP addresses, but by their real, private IP addresses. This avoids problems inherent in connecting to servers behind a many to one NAT configuration.
This chapter will outline the configuration of a permanent site-to-site ××× link or tunnel using Openswan, one of the most popular ××× packages for Linux.
If you are new to ×××s, please refer to
Appendix I, "Miscellaneous Linux Topics", for some important background information that will provide a deeper understanding of the steps outlined in this chapter.
××× Guidelines
Here are some recommended guidelines that I suggest you consider before attempting a simple SOHO Linux ×××.
- The IPSec protocol on which ×××s are based will not tolerate its data packets being network address translated. If your firewall does NAT, then you'll have to disable it specifically for the packets that will traverse the ×××.
- Life will be much easier if you make your Linux ××× box also function as a firewall. Configure and test the firewall first and then configure the ×××. Chapter 14, "Linux Firewalls Using iptables", should help a lot.
- The networks at both ends of the ××× tunnel must use different IP address ranges. Many company networks operate using 192.168.0.x or 192.168.1.x addresses, you may have to reassign IP addresses to your network if overlaps occur.
- Permanent site-to-site ×××s require firewalls at both ends that use static, DHCP IP addresses.
Scenario
Figure 35-1 illustrates the topology of a ××× between two SOHO environments. Here's the scenario.
- The two sites need a ××× so that they can communicate with each other without the fear of eavesdropping.
- The network administrators at both sites are aware that permanent site-to-site ×××s require fixed Internet IP addresses and have upgraded from their basic DHCP services originally provided by their ISPs. The sites' IP addressing schemes do not overlap.
- Neither site wants to invest in a CA certificate service or infrastructure. The RSA key encryption methodology will be used for key exchange. (At the end of the chapter, I'll discuss an alternative Cisco-compatible method called alternately shared secret, pre-shared, or symmetric key.)
- Site 1 uses a private network of 172.168.1.0 /24 and has a Linux ×××/firewall device default gateway with an external Internet IP address of 97.158.253.25.
- Site 2 uses a private network of 10.0.0.0 /24 and has a Linux ×××/firewall device default gateway with an external Internet IP address of 6.25.232.1.
Figure 35-1 Openswan Topolology Diagram
Download And Install The Openswan Package
You can download the Openswan RPM at www.openswan.org . The site has good instructions on how to install the product on Fedora and other versions of Linux. Be aware that to download the RPM version of Openswan you must have the ipsec-tools RPM package installed on your system. (Remember, RPM filenames usually start with the software's name and version number, as in openswan-2.1.4-1.fc2.i386.rpm. If you need more details, see Chapter 6, "
Installing Linux Software".
How to get Openswan Started
You can configure Openswan to start at boot time using the chkconfig command:
[root@bigboy tmp]# chkconfig ipsec on
You can start, stop, and restart Openswan after booting using the ipsec initialization script as shown:
[root@bigboy tmp]# service ipsec start [root@bigboy tmp]# service ipsec stop [root@bigboy tmp]# service ipsec restart
Remember to restart the ipsec process every time you make a change to the ipsec.conf file for the changes to take effect on the running process.
Get The Status Of The Openswan Installation
Immediately after installing Openswan, run the ipsec verify command. It should give an [OK] status for most of its checks:
[root@***2 tmp]# ipsec verify Checking your system to see if IPsec got installed and started correctly Version check and ipsec on-path [OK] Linux Openswan U2.2.0/K2.6.8-1.521 (native) Checking for IPsec support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADEing [N/A] Checking for 'ip' command [OK] Checking for 'iptables' command [OK] Checking for 'setkey' command for native IPsec stack support [OK] [root@***2 tmp]#
How to fix common Status errors
The status check may provide some errors. The most common ones are related to IP forwarding and opportunistic encryption.
IP forwarding
Each Linux ××× device needs to have routing or IP forwarding enabled. To enable it, simply add an ip_forward entry to the /etc/sysctl.conf file.
# # File: /etc/sysctl.conf # #--------------------------------------------------------------- # Enable routing (IP forwarding) #--------------------------------------------------------------- net/ipv4/ip_forward = 1
Now use the sysctl -p command to activate the settings.
[root@bigboy tmp]# sysctl -p ... ... net.ipv4.ip_forward = 1 [root@bigboy tmp]#
You can find more details on the /etc/sysctl.conf, in Appendix I, "Miscellaneous Linux Topics."
Opportunistic Encryption DNS Checks:
The opportunistic encryption DNS checks feature of Openswan allows gateways to encrypt their traffic, even if the two gateway administrators have had no prior contact and neither system has any preset information about the other. The rationale behind this is to make all connections to servers behind the ××× device automatically be encrypted using IPSec in the same way that HTTP traffic can be seamlessly encrypted to become HTTPS traffic.
This feature should be disabled by default in your configuration file; simply ignore the errors related to it.
××× Configuration Steps (Using RSA Keys)
One of the more secure ways of setting up a ××× tunnel is to encrypt the data using certificate-based (RSA) keys. There are other ××× parameters too, but Openswan is very forgiving when it establishes a tunnel. It automatically goes through all the various combinations of IKE and IPSec settings with the remote ××× box until it finds a match. You don't have to configure most of these settings explicitly as you often have to do in the case of routers and firewall/××× appliances.
The /etc/ipsec.conf file
Preparation work requires you to draw a basic network diagram such as Figure 35.1. The ××× box on the left is called the left-hand side and the one on the right is called the right-hand side. Left and right parameters must be configured in the /etc/ipsec.conf configuration file. Table 35-1 explains each parameter.
Table 35-1 Parameters of the /etc/ipsec.conf file
| Parameter | Description |
|---|---|
Left | Internet IP address of the left-hand side ××× device. |
Leftsubnet | The network protected by the left-hand side ××× device. |
Leftid | Fully qualified domain name in DNS of the left-hand side ××× device, which is preceded by an "@" sign. If DNS is set up for the IP addresses, remove this entry, because names that don't resolve correctly cause the ××× initialization to fail. |
Leftrsasigkey | The entire left RSA sig public key for the left-hand side ××× device. This can be obtained by using the ipsec showhostkey --left command. |
Leftnexthop | The next hop router from the left-hand side ××× device when trying to reach the right-hand side ××× device. You may use an auto-generated variable %defaultroute, which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router. |
Right | Internet IP address of the right-hand side ××× device. |
Rightsubnet | The network protected by the right-hand side ××× device. |
Rightid | Fully qualified domain name in DNS of the right-hand side ××× device, which is preceded by an @ sign. If DNS isn't set up for the IP addresses, remove this entry, because names that don't resolve correctly cause the ××× initialization to fail. |
Rightrsasigkey | The entire right RSA sig public key for the right-hand side ××× device. This can be obtained by using the ipsec showhostkey --right command. |
Rightnexthop | The next hop router from the right-hand side ××× device when trying to reach the right-hand side ××× device. You may use an auto-generated variable %defaultroute, which will be valid in most cases, or the actual IP address of the next hop router in cases where the next hop is not the default router. |
First you must gather all this information, then you have to enter it in the /etc/ipsec.conf configuration file.
Obtaining RSA Keys
To configure the /etc/ipsec.conf file, you need to get the left RSA public key for the left ××× device and the right key for the right ××× device. You need to generate these and insert them in the /etc/ipsec.conf file of the ××× peer device.
The best approach is to generate files containing these keys and then use the vi editor's read command (r) to read them into your /etc/ipsec.conf file. Cutting and pasting screen output over an SSH session may automatically insert carriage return and line feed characters at the end of each line where the text would normally wrap around on the screen. This can corrupt the keys.
Creating Your Own Keys
The Openswan installation automatically generates the keys. If you want to change them, you can issue the command:
[root@***2 tmp]# ipsec rsasigkey --verbose 2048 > keys.tmp [root@***2 tmp]#
You can then edit the /etc/ipsec.secrets file and replace the contents between RSA: { and the final } with the contents of the keys.tmp file generated from the ipsec command above.
Get The Left Public Key
On the left ××× server, issue this command to export the left public key to a file named /tmp/left.pub.
[root@***1 tmp]# ipsec showhostkey --left > /tmp/left.pub [root@***1 tmp]#
Get The Right Public Key
On the right ××× server, export the right public key to a file named /tmp/right.pub.
[root@***2 tmp]# ipsec showhostkey --right > /tmp/right.pub [root@***2 tmp]#
Edit the /etc/ipsec.conf Configuration File
Each ××× in the /etc/ipsec.conf file has its own subsection. The example creates a subsection called net-to-net, which then receives all the needed parameters.
#
# File: /etc/ipsec.conf
#
conn net-to-net
left=97.158.253.25 # Public Internet IP address of the
# LEFT ××× device
leftsubnet=172.16.1.0/24 # Subnet protected by the LEFT ××× device
leftid=@***1.my-site.com # FQDN of Public Internet IP address of the
# LEFT ××× device with an "@"
leftrsasigkey=0sAQNrV9AYdaW94FXvIxu5p54+MRaW0wy0+HHQrdGofklZYQ4TCBlL+Ym00Ahfc8mqXlerZY12Os41G
8SIV+zzIO04WZ4wmOvEr8DZaldTbfCuvUvMhrTtCpZdm53yF5rCaUbg+Vmx71fgyVmGu8/kuhzB7nWtOYqDFO8OHDGePOyO
VPQi73KfRoDbdb3ND0EtfnRhRPblKJ239OlIq1
leftnexthop=%defaultroute # correct in many situations
right=6.25.232.1 # Public Internet IP address of
# the RIGHT ××× device
rightsubnet=10.0.0.0/24 # Subnet protected by the RIGHT ××× device
rightid=@***2.another-site.com # FQDN of Public Internet IP address of the
# RIGHT ××× device with an "@"
rightrsasigkey=0sAQNNdxFPWCga+E/AnDgIM+uIDq4UXcZzpomwMFUpyQ9+rhUHT9w8nr3rjUR/qTZOKR2Vqd4XoBd1s
HkPDBQ8oNjtA3Oz+UQOU3KTMHN5ydFwe6MpTJV/hL6LvhB0OXQad/NhjMIx8vOnhM8g8SPRnj7pL3abgu7Sg7eFREV1MJSVB
h p0DJ0EbVMVV+Xvwlm9++9zbY3mlc+cSXMPAJZ
rightnexthop=97.158.253.25 # correct in many situations
auto=start # authorizes and starts this connection
# on booting
Some Important Notes About The /etc/ipsec.conf File
Be sure to maintain the indentation before each parameter. The correct arrangement is.
conn net-to-net left=x.x.x.x leftsubnet=y.y.y.y/24
Do not use
conn net-to-net left=x.x.x.x leftsubnet=y.y.y.y/24
The net-to-net subsections must be the same in the /etc/ipsec.conf for both the left- and right-hand side ××× devices. You can configure ×××s to other remote destinations in this file as long as they don't share a subsection name with other ×××s. So in this example, there should be only one net-to-net subsection which uniquely defines the ××× between our two sample sites.
Also, make sure no blank lines separate the net-to-net section's parameters. Lines commented with a # character are acceptable.
Restarting IPSec to reload the configuration file doesn't necessarily restart the tunnels. If you set the auto= parameter to add, you can start the tunnel only manually with the ipsec command. If the parameter is commented out, then the tunnel will never start. A value of start causes the tunnel to start automatically.
Restart Openswan
On both ××× devices, you need to start Openswan for the new /etc/ipsec.conf settings to take effect.
[root@***2 tmp]# service ipsec restart ipsec_setup: Stopping Openswan IPsec... ipsec_setup: Starting Openswan IPsec U2.2.0/K2.6.8-1.521... [root@***2 tmp]#
Initialize The New Tunnel
To initialize the new tunnel, you can use the ipsec command to start the tunnel net-to-net. Be sure to issue the command simultaneously on the ××× boxes at both ends of the tunnel.
[root@***2 tmp]# ipsec auto --up net-to-net
104 "net-to-net" #1: STATE_MAIN_I1: initiate
106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established
112 "net-to-net" #2: STATE_QUICK_I1: initiate
004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe0bdd0e9 <0x13ac7645}
[root@***2 tmp]#
The "IPsec SA established" message signifies success.
Testing The New Tunnel
The troubleshooting section at the end of the chapter shows you how to test that everything is working correctly.
Possible Changes To IP Tables NAT/Masquerade Rules
If you are running iptables with masquerading/NAT for the ××× devices, then you must exclude packets traversing the tunnel from the NAT operation. This example assumes that interface eth0 is the Internet facing interface on your Linux ×××/firewall.
Change the left-hand side ××× device's iptables statement from.
iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -j MASQUERADE
to
iptables -t nat -A POSTROUTING -o eth0 -s 172.168.1.0/24 -d \! 10.0.0.0/24 -j MASQUERADE
For the right-hand side ××× device, change the statement
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
to
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 176.16.1.0/24 -j MASQUERADE
How To Ensure Openswan Starts When Rebooting
If your ××× subsection in the /etc/ipsec.conf file contains the line auto=add, then IPSec only authorizes but doesn't establish the connection at startup. You'll have to use the ipsec auto --up <***-name> command to start it manually.
You must change this to auto=start for Openswan to start the ××× automatically when IPSec restarts or when the system reboots.
Using Pre-Shared Keys (PSK)
You don't always have to use RSA type keys. Sometimes the ××× device at the other end of the tunnel won't support them, but will accept a simpler pre-shared key. Here is how to do it.
1) Create the PSK using one of two methods. You can create a random pre-shared key using the ipsec command.
[root@***2 tmp]# ipsec ranbits --continuous 128 0x33893a081b34d32a362a46c404ca32d8 [root@***2 tmp]#
Or, you can create them out of your head. Make them long (over 20 bytes), as in.
Nonebutourselvescanfreeourminds
2) Update /etc/ipsec.secrets by adding text in this format at the beginning of the file.
***1-ip-address ***2-ip-address : PSK "key in quotations"
For the example the line is:
97.158.253.25 6.25.232.6 : PSK "nonebutourselvescanfreeourminds"
3) Update /etc/ipsec.conf. The PSK configuration is very similar to the RSA configuration with exception that the leftid, rightid, leftrsasigkey, and rightrsasigkey fields are omitted from the relevant conn subsection. Also add the authtype=secret command to the configuration.
conn net-to-net
authby=secret # Key exchange method
left=97.158.253.25 # Public Internet IP address of the
# LEFT ××× device
leftsubnet=172.16.1.0/24 # Subnet protected by the LEFT ××× device
leftnexthop=%defaultroute # correct in many situations
right=6.25.232.1 # Public Internet IP address of
# the RIGHT ××× device
rightsubnet=10.0.0.0/24 # Subnet protected by the RIGHT ××× device
rightnexthop=97.158.253.25 # correct in many situations
auto=start # authorizes and starts this connection
# on booting
Remember to have the same configuration on the Linux ××× boxes on either side of the tunnel and to restart Openswan to activate the new settings.
Troubleshooting Openswan
Troubleshooting is always important when setting up ×××s, because many things can go wrong. Here are some quick checks you can do to make sure all is working correctly.
Determine the Tunnel Status
The ipsec auto --status command provides a status on Opesnswan running on your ××× device. The output is divided into three sections:
- IKE Section: Defines the various encrypted key exchange algorithms and their parameters. At least one set of values must match between the left- and right-hand side ××× devices. This is also frequently referred to as the Phase 1 parameters, because the key exchange process is the first thing to occur in establishing a ×××.
- ESP Section: Defines the various data encryption algorithms and their parameters. At least one set of values must match between the left- and right-hand side ××× devices. This is also frequently referred to as the Phase 2 parameters, because the data encryption process is the second and final thing to occur in establishing a ×××.
- ××× Section: This is usually prefaced by the name of the ××× tunnel, in this case net-to-net. If there are no entries, then the ××× hasn't been established at all. If there are entries, but no STATE_QUICK_R2 (IPsec SA established) lines then the IPSec parameters are configured, but the tunnel hasn't been established. This can be normal, tunnels become active once the Phase 1 and Phase 2 security associations are created, and this usually only occurs after traffic is flowing. The associations then get torn down after a timeout period. It is always best to pass traffic over the tunnel to activate them. An ICMP ping check is a good way to test this.
[root@***2 tmp]# ipsec auto --status ... ... 000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192 000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448 ... ... 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192 000 algorithm IKE hash: id=2, name=OAKLEY_SHA, hashsize=20 ... ... 000 "net-to-net": IKE algorithms wanted: 5_000-1-5, 5_000-1-2, 5_000-2-5, 5_000-2-2, flags=-strict 000 "net-to-net": IKE algorithms found: 5_192-1_128-5, 5_192-1_128-2, 5_192-2_160-5, 5_192-2_160-2, 000 "net-to-net": IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536 000 "net-to-net": ESP algorithms wanted: 3_000-1, 3_000-2, flags=-strict 000 "net-to-net": ESP algorithms loaded: 3_000-1, 3_000-2, flags=-strict 000 "net-to-net": ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=<Phase1> ... ... 000 #4: "net-to-net" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3635s; newest IPSEC; eroute owner 000 #4: "net-to-net" esp.aca08f86@192.168.1.100 esp.7b90ea53@192.168.1.1 tun.0@192.168.1.100 tun.0@192.168.1.1 000 #12: "net-to-net" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 1153s; newest ISAKMP [root@***2 tmp]#
It is important to know the status of your ××× as it can provide valuable troubleshooting clues when there are problems. This can be especially important when establishing a ××× between your Linux firewall and a non-Linux device. The IKE and ESP timers, and encryption, hash and key exchange algorithms must match at both ends to have success. This command allows you to see the value combinations Openswan is using and help you configure the ××× device on the other end to have compatible settings.
==Testing ××× Connectivit==y
You can test the ××× connectivity by sending a simple ping from one private network to the other. In this case, the ping goes to the Windows server 10.0.0.105, which protected by ***2, from server 172.16.1.1, which is protected by ***1.
If the tunnel is up but ICMP pings don't work, then you need to check that the servers at both ends of the tunnel have routes pointing to the ××× firewalls. Also, check for additional network access controls between the servers and the ××× firewall. There may be additional firewalls in the way or the servers themselves may be running firewall software:
C:\>ping 10.0.0.105
Pinging 10.0.0.105 with 32 bytes of data:
Reply from 10.0.0.105: bytes=32 time=20ms TTL=253
Reply from 10.0.0.105: bytes=32 time<10ms TTL=253
Reply from 10.0.0.105: bytes=32 time=10ms TTL=253
Reply from 10.0.0.105: bytes=32 time<10ms TTL=253
Ping statistics for 10.0.0.105:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 20ms, Average = 7ms
C:\>
Check The Routes
You'll need to check the routes after the ××× tunnel is up as well. As you can, see there is an additional route to the 172.16.1.0 network on firewall ***2. Incorrect routing on the firewalls can cause problems, check your leftnexthop and rightnexthop values in your /etc/ipsec.conf file.
[root@***2 tmp]# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 6.25.232.0 0.0.0.0 255.255.255.248 U 40 0 0 eth0 172.16.1.0 97.158.253.25 255.255.255.0 UG 40 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 6.25.232.6 0.0.0.0 UG 40 0 0 wlan0 [root@***2 tmp]#
Using TCPdump
If the tunnel doesn't appear to become established, use the tcpdump command as explained in Chapter 4, "
Simple Network Troubleshooting", to determine whether the traffic is being seen at both ends of the tunnel. You need to know whether the IPSec packets are even reaching your ××× firewall. Check routing and your Openswan configuration if not.
Protected Interface TCPDUMP Output From "***2"
Here the TCPdump is done on server2 where you see unencrypted ICMP ping traffic successfully passing back and forth between the two servers.
[root@***2 tmp]# tcpdump -n -i eth1 icmp 03:05:53.971308 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 89 03:05:53.995297 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 89 03:05:54.972759 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 90 03:05:54.972789 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 90 03:05:55.972985 IP 172.16.1.1 > 10.0.0.105: icmp 64: echo request seq 91 03:05:55.972999 IP 10.0.0.105 > 172.16.1.1: icmp 64: echo reply seq 91 ^C [root@***2 tmp]#
Unprotected Interface TCPDUMP Output From "***2"
Here the encrypted ESP traffic is encapsulating the pings passing back and forth between the two ××× boxes. The true source and destination IP addresses (10.0.0.105 and 172.16.1.1) are hidden.
[root@***2 tmp]# tcpdump -n -i eth1 host 97.158.253.25 02:08:23.637149 IP 6.25.232.1 > 97.158.253.25: ESP(spi=0xf4909a7e,seq=0x73) 02:08:24.635302 IP 97.158.253.25 > 6.25.232.1: ESP(spi=0x808e9a87,seq=0x74) 02:08:24.637988 IP 6.25.232.1 > 97.158.253.25: ESP(spi=0xf4909a7e,seq=0x74) 02:08:25.638015 IP 97.158.253.25 > 6.25.232.1: ESP(spi=0x808e9a87,seq=0x75) ^C [root@***2 tmp]#
Check Syslog Error Messages
As always, check your /var/log/messages file for any messages that may provide clues as to the source of your problems.
"Invalid Key" Messages
If your left and right public keys were incorrectly applied to your /etc/ipsec.conf file or your regenerated keys were not updated in your /etc/ipsec.secrets file, then you will get messages stating that the keys are invalid and that information is being ignored.
003 "net-to-net" #1: ignoring informational payload, type INVALID_KEY_INFORMATION 003 "net-to-net" #1: received and ignored informational message 003 "net-to-net" #1: discarding duplicate packet; already STATE_MAIN_I3 031 "net-to-net" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message
Conclusion
×××s are increasingly becoming an everyday part of life on the Internet. Many people use them to gain access to many of the systems in their offices, such as e-mail and intranets. This trend is certain to become more popular as many companies are finding it cheaper for their employees to work from home, relieving them of the need to lease additional office space.
Site-to-site ×××s will also continue to be deployed as companies, both small and large find it increasingly necessary to share access to their business systems. One notable area is in the realm of IP telephony, where ×××s enable all remote offices to use a single IP switchboard at the center of a ××× hub and spoke network. Intra-office communication is therefore encrypted and the use of a single switchboard saves costs.
Knowledge of ×××s is now indispensable for systems administrators.
转载于:https://blog.51cto.com/enchen/158324
扫一扫
4028
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
