Linux 网络是一个巨大的领域。 在过去的几十年里，已经有无数关于 Linux 网络管理内部结构的书籍和参考文献。 有时，对于新手和高级用户来说，仅仅是吸收基本概念可能是压倒性的。 本章对 Linux 网络进行了相对简洁的概述，重点介绍了网络通信层、套接字和端口、网络服务和协议、虚拟专用网络(vpn)以及网络安全。
我们希望本章的内容既能让新手轻松地了解基本的 Linux 网络原理，也能让高级 Linux 管理员轻松地复习一下。
在本章中，我们将涵盖以下主题:
- 探索基本的网络——集中于计算机网络，网络模型，协议，网络地址和端口。 我们还讨论了使用命令行终端配置 Linux 网络设置的一些实际方面。
- 使用网络 services-introducing 常见的网络服务器运行在 Linux 上,如域主机配置协议(DHCP)服务器、域名系统(DNS)服务器、文件共享服务器、远程接入服务器,等等。 *** 理解网络安全—特别强调 vpn。**
**# 技术要求
在本章中，我们将在一定程度上使用 Linux 命令行。 强烈推荐安装在虚拟机(VM)或桌面平台上的 Linux 发行版。 如果你还没有一个，第 1 章安装 Linux 和设置环境将指导你完成安装过程。 本章中的大多数命令和示例使用 Ubuntu 和 CentOS，但同样适用于任何其他 Linux 平台。
今天，几乎无法想象一台计算机没有连接到某种网络或互联网。 我们不断增长的在线状态、云计算、移动通信、和**物联网(物联网)不会可能没有高度分散,高速、和可伸缩网络服务的底层数据流量, 然而，现代互联网背后的基本网络原理已经有几十年的历史了。 显然，网络和通信模式将继续发展，但一些原始的基本概念和概念仍将在塑造未来通信的构建模块方面产生持久的影响。**
**本节将向您介绍一些网络的基本要素，并希望激发您进一步探索的好奇心。 让我们从计算机网络开始。
计算机网络是由两台或两台以上的计算机(或节点)组成的一组，这些计算机(或节点)通过物理介质(电缆、无线、光学)连接起来，并通过一套标准的公认通信协议彼此通信。 在非常高的层次上，网络通信基础设施包括计算机、设备、交换机、路由器、以太网或光缆、无线环境以及各种网络设备。
除了物理的连接和安排，网络还通过逻辑布局通过网络拓扑、层和相关的数据流来定义。 逻辑上的网络层次结构的一个例子是非军事区(DMZ)、防火墙和内部网络的三层结构。 DMZ 是一个组织的面向外部的网络，具有针对公共互联网的额外安全层。 防火墙控制 DMZ 和内部网络之间的网络流量。
网络设备由网络地址和主机名标识。 网络地址协助定位节点在网络上使用的通信协议,如互联网协议(IP)(看到更多的 IP*部分,TCP / IP 协议在本章后面)。 主机名是与设备相关联的用户友好标签，比网络地址更容易记住。*****
一种常见的分类标准着眼于计算机网络的规模和扩展。 接下来我们将介绍局域网*(局域网)和广域网(广域网)。
LAN 表示一组连接并位于单一物理位置的设备，如私人住宅、学校或办公室。 局域网可以是任何规模的，从只有少量设备的家庭网络到拥有数千用户和计算机的大型企业网络。
不管网络大小如何，局域网的基本特征是它将单个有限区域内的设备连接起来。 局域网的例子包括单户住宅的家庭网络或当地咖啡店的免费无线服务。
关于局域网的更多信息，请参考https://www.cisco.com/c/en/us/products/switches/what-is-a-lan-local-area-network.html。
当计算机网络跨越多个区域或多个互连的局域网时，广域网就发挥作用了。
广域网通常是一个由多个或分布式局域网相互通信的网络组成的网络。 从这个意义上说，我们认为互联网是世界上最大的广域网。
广域网的一个例子是跨国公司按地理位置分布在世界各地办事处的计算机网络。 有些广域网路是由服务提供商建造的，可以出租给世界各地的各种企业和机构。
广域网路有几种变体，这取决于它们的类型、范围和用途。 典型广域网的例子包括个人区域网络****(锅)、市区网络【显示】(芒)和云或互联网区域网络【病人】题材影片。****
**更多关于广域网的信息，请参考https://www.cisco.com/c/en/us/products/switches/what-is-a-wan-wide-area-network.html。
我们认为，对基本网络原理的充分介绍应该包括对一般网络通信的理论模型的简要介绍。 让我们接下来看看这个。
开放系统互连(OSI)模型是计算机系统之间通过网络交互的多层通信机制的理论表示。 OSI 模型由国际标准化组织(ISO)于 1983 年引入，为不同的计算机系统之间的通信提供一个标准。
我们可以把 OSI 模型看作是网络通信的通用框架。 如下截图所示，OSI 模型定义了一个 7 层的堆栈，指导通信流:
图 7.1 - OSI 模型
在上图所示的分层视图中，通信流从上到下移动(在发送端)或从下到上移动(在接收端)。 让我们来看看这些层，并描述它们在塑造网络通信中的功能。
物理层(或第一层)由连接各设备并为通信服务的网络设备或基础设施组成，如电缆、无线或光学环境、连接器、交换机等。 这一层处理原始比特流和通信媒体之间的转换，同时调节相应的比特率控制。 (通信介质包括电信号、无线电信号或光信号。)
例子在物理层协议的操作包括以太网,通用串行总线(USB),和数字用户线(DSL【显示】)。
**### 数据链路层
数据链路层(或层 2)之间建立一个可靠的数据流两个直接连接设备在一个网络中,相邻节点在 WAN 或为局域网内的设备。 数据链路层的职责之一是流量控制，以适应物理层的通信速度。 在接收设备上，数据链路层负责纠正由物理层引起的通信错误。 数据链路层由以下子系统组成:
- 媒体访问控制(MAC)-这个子系统使用 MAC 地址识别并连接网络上的设备。 它还控制设备在网络上传输和接收数据的访问权限。
- 逻辑链路控制(LLC)-这个子系统识别并封装网络层协议，在传输或接收数据时执行错误检查和帧同步。
由数据链路层控制的协议数据单元又称为帧。 帧是一种数据传输单元，它充当单个网络数据包的容器。 网络数据包在下一个 OSI 级别(网络层)进行处理。 当多个设备同时访问同一物理层时，可能会发生帧冲突。 数据链路层协议可以检测和恢复这种冲突，并进一步减少或防止它们的发生。
数据链路协议的一个例子是点对点协议(PPP)，这是一种用于高速宽带通信网络的二进制组网协议。
网络层(或第三层)发现网络中设备之间的最佳通信路径(或路由)。 该层使用基于参与数据交换的设备 IP地址的路由机制，将数据包从源端移动到目的端。
*在传输端，网络层将起源于传输层(第 4 层)的数据段拆解成网络数据包。 在接收端，数据帧从下一层(数据链路层)重新组装成数据包。
运行在网络层的协议是Internet 控制消息协议(ICMP)。 ICMP 被网络设备用来检查网络上其他设备(或 IP 地址)的可用性。 当请求的端点不可用时，ICMP 会报告一个错误。
传输层(或第 4 层)与数据片段或数据报操作。 这一层是，主要负责将数据从数据源传输到目的地，并保证特定的服务质量(QoS)。 在传输端，来自上一层(会话层)的数据被分解成段。 在接收端，传输层将从下一层(网络层)接收到的数据包重新组装成段。
传输层通过流量控制和错误控制功能来维护数据传输的可靠性。 流量控制功能可以调整不同连接速度的端点之间的数据传输速率，以避免发送端压倒接收端。 当接收到的数据不正确时，错误控制函数可能请求重新传输数据。
传输层协议的例子包括传输控制协议(TCP),的用户数据报协议(UDP【显示】)。****
****### 会话层
会话层(或第五层)控制网络上通信设备之间的连接通道(或会话)的生命周期。 在这一层，会话或网络连接通常由网络地址、套接字和端口定义。 我们将在本章后面解释这些概念。 会话层负责通信通道或会话内数据传输的完整性。 例如，如果会话被中断，数据传输将从先前的检查点恢复。
一些典型的会话层协议是远程过程调用(RPC)协议进程间通信使用的,网络基本输入/输出系统(【显示】NetBIOS),这是一个文件共享和名称解析协议。
表示层(或第 6 层)充当上面的应用层和下面的会话层之间的数据转换层。 在传输端，这一层在通过网络发送数据之前，将格式化成与系统无关的表示形式。 在接收端，表示层将数据转换为应用友好的格式。 此类转换的示例包括加密和解密、压缩和解压缩、编码和解码以及序列化和反序列化。 通常，表示层和应用层之间没有实质上的区别，主要是因为不同的数据格式与使用它们的应用之间存在相对紧密的耦合。 标准数据表示格式包括美国标准信息交换(【t16.1】ASCII),可扩展标记语言(XML),JavaScript 对象表示法(JSON),联合摄影专家组(JPEG),邮政,等等。****
****### 应用层
在 OSI 模型中，应用层(或第 7 层)最接近最终用户。 第 7 层以某种有意义的方式收集或提供应用数据的输入或输出。 这一层并不包含或运行应用本身。 相反，第 7 层充当应用之间的抽象，实现通信组件和底层网络。 应用与应用层交互的典型例子是 web 浏览器和电子邮件客户端。
7 层协议中的少数实例是 DNS 协议; 超文本传输协议(HTTP); 文件传输协议(FTP); 和【病人】邮局协议(流行),【t16.1】互联网信息访问协议(**IMAP),简单邮件传输协议(**SMTP)电子邮件消息协议。
在结束之前，我们应该指出 OSI 模型是网络通信层的通用表示，并提供了网络通信如何工作的理论指导方针。 一个类似但更实际的网络堆栈演示是 TCP/IP 模型，我们将在下一节中探讨它。
当涉及到网络设计、实现、故障排除和诊断时，这两种模型都很有用。 OSI 模型使网络运营商对整个网络堆栈(从物理介质到应用层)有一个很好的理解，每一层都有其协议数据单元(pdu)和内部通信。 TCP/IP 模型在某种程度上被简化了，一些 OSI 模型层被压缩为一个，它采用了一种以协议为中心的方法来进行网络通信。
TCP/IP 模型是 OSI 网络堆栈的四层解释，其中一些等效的 OSI 层出现合并，如下截图所示:
图 7.2 - OSI 和 TCP/IP 模型
从时间上看，TCP/IP 模型比 OSI 模型早。 是由美国首先提出国防部(国防部)作为互联网络项目的一部分开发的国防高级研究计划局(DARPA**【显示】)。 这个项目最终成为现代互联网。**
**TCP/IP 模型层封装了与它们的对等 OSI 层相似的功能。 下面是对 TCP/IP 模型中每一层的简要总结。
网络接口层负责在物理介质(如有线、无线、光学)上传送数据。 在这一层运行的网络协议包括以太网、令牌环和帧中继。 这一层映射到 OSI 模型中物理层和数据链路层的组成。
*### 网络层
互联网层提供无连接网络节点之间的数据传输。 无连接协议描述了一种网络通信模式，其中发送方在没有事先安排的情况下将数据传输给接收方。 这一层负责在发送端将数据分解成网络数据包，在接收端重新组装。 internet 层使用路由功能来识别网络节点之间的最优路径。 这一层映射到 OSI 模型中的网络层。
传输层(也称为传输层或主机到主机层)负责维护连接的网络节点之间的通信会话。 传输层实现了端点之间可靠数据传递的错误检测和校正机制。 这一层映射到 OSI 模型中的传输层。
应用层提供软件应用与底层网络之间的数据通信抽象。 这一层映射到 OSI 模型中会话层、表示层和应用层的组成。
TCP/IP 模型是以协议为中心的网络堆栈表示。 该模型通过逐渐定义和发展互联网通信所需的网络协议，成为互联网的基础。 这些协议统称为IP 套件。
下面的部分描述一些最常见的网络协议。
在本节中，我们将描述一些广泛使用的网络协议。 这里的参考不应该被认为是一个包罗万象的指南。 有大量的 TCP/IP 协议，全面的研究超出了本章的范围。 尽管如此，在日常网络通信和管理工作流中仍有一些协议值得研究。
下面的部分简要描述了每个 TCP/IP 协议及其相关的Request for Comments(RFC)标识符，以获得更多信息。 RFC 代表协议的详细技术文档，在我们的例子中，通常是由Internet 工程任务组(IETF)编写的。 更多关于 RFC 的信息，请参考https://www.ietf.org/standards/rfcs/。
IP(RFC 791)基于固定长度的地址(也称为 IP 地址)来标识网络节点。 IP 地址将在本章后面的中详细描述。 IP 协议使用数据报作为数据传输单元，并提供大数据报的碎片化和重组能力，以适应小数据包网络(并避免传输延迟)。 IP 协议还提供路由功能，以找到网络节点之间的最佳数据路径。 IP 操作在 OSI 模型的网络层(3)。
地址解析协议(ARP**)(RFC 826*)使用 IP 协议 IP 映射网络地址(具体来说,IP 版本 4【显示】****(IPv4)【病人】设备的 MAC 地址使用的数据链路协议。 ARP 操作在 OSI 模型的数据链路层(2)。***
*### 民主党
的邻居发现协议(**民主党)*(RFC 4861)就像 ARP 协议,并控制【T7 IP 版本 6】【显示】(***IPv6)地址映射。 NDP 在 OSI 模型的数据链路层(2)中运行。
ICMP(RFC 792)是的一种支持的基于 IP 地址的网络设备可用性检测协议。 当设备或节点在给定的超时时间内无法到达时，ICMP 会报告一个错误。 ICMP 工作在 OSI 模式下的网络层(3)。
TCP(RFC 793)是一种面向连接的、高度可靠的通信协议。 在开始数据交换之前，TCP 需要节点之间的逻辑连接(例如握手)。 TCP 在 OSI 模型中运行在传输层(4)。
UDP(rfc768)是无连接通信协议。 UDP 没有握手机制(与 TCP 相比)。 因此，使用 UDP 无法保证数据传输。 UDP 使用数据报作为数据传输单元，适用于不需要进行错误检查的网络通信。 UDP 操作在 OSI 模型的传输层(4)。
DHCP(RFC 2131)为 TCP/IP 网络上的设备请求和传递主机配置信息提供了一个框架。 DHCP 允许自动(动态)分配可重用的 IP 地址和其他配置选项。 DHCP 被认为是 OSI 模型中的一个应用层(7)协议，但最初的 DHCP 发现机制运行在数据链路层(2)。
DNS(RFC 2929)是一种作为网络地址簿的协议，其中网络中的节点是通过人类可读的名称而不是 IP 地址来标识的。 根据 IP 协议，网络中的每个设备都由一个唯一的 IP 地址来标识。 当网络连接在连接建立之前指定了远端设备的主机名(或域名)时，DNS 将域名(如dns.google.com)转换为 IP 地址(如8.8.8.8)。 DNS 协议操作在 OSI 模型的应用层(7)。
HTTP(RFC 2616)是互联网的车载语言。 HTTP 是一种无状态应用层协议，基于客户端应用(例如浏览器)和服务器端点(例如 web 服务器)之间的请求和响应。 HTTP 支持各种各样的数据格式，从文本到图像和视频流。 HTTP 操作在 OSI 模型的应用层(7)。
FTP(RFC 959)是一个标准协议，用于传输 FTP 客户端从 FTP 服务器请求的文件。 FTP 操作在 OSI 模型的应用层(7)。
终端网络协议(TELNET)(RFC 854)是一个应用层协议提供一个双向种面向文本的网络客户端和服务器之间的通信,使用虚拟终端连接。 TELNET 操作在 OSI 模型的应用层(7)。
Secure Shell(SSH)(RFC 4253)是一个安全应用层协议，封装了强加密和加密主机认证。 SSH 使用客户机和服务器之间的虚拟终端连接。 SSH 操作在 OSI 模型的应用层(7)。
SMTP(RFC 5321)是一种应用层协议，用于在电子邮件客户端(如 Outlook)和电子邮件服务器(如 Exchange server)之间收发电子邮件。 SMTP 支持强加密和主机身份验证。 SMTP 行为在 OSI 模型的应用层(7)。
简单网络管理协议(SNMP)(RFC 1157)用于设备的远程管理和监控。 SNMP 运行在 OSI 模型的应用层(7)上。
网络时间协议(NTP)(*RFC 5905)*是一个 internet 协议，用于通过网络同步多台机器的系统时钟。 NTP 运行在 OSI 模型的应用层(7)。
以前列举的大多数互联网协议使用 IP 协议来识别参与通信的设备。 网络中的设备由一个 IP 地址唯一标识。 让我们仔细检查一下这些网络地址。
IP 地址是网络中设备的固定长度唯一标识(UID)。 设备通过 IP 地址定位并进行通信。 IP 地址的概念非常类似于住宅的邮政地址，邮件或包裹将根据其地址发送到该目的地。
最初，IP 将 IP 地址定义为一个 32 位的数字，即 IPv4 地址。 随着互联网的发展，网络中 IP 地址的数量已经耗尽。 为了解决这个问题，IP 协议的一个新版本为 IP 地址设计了一个 128 位的编号方案。 128 位的 IP 地址也被称为 IPv6 地址。
在下一节中，我们将进一步研究在 IP 地址中扮演重要角色的网络结构，例如 IPv4 和 IPv6 地址格式、网络类、子网和广播地址。
IPv4 地址是一个 32 位的数字(4 字节)，通常用表示为 4 组 1 字节(8 位)的数字，由一个点(.)分隔。 这四组中的每个数字都是一个介于0和255之间的整数。 下面是一个 IPv4 地址的例子:
192.168.1.53下图显示了 IPv4 地址的二进制表示形式:
图 7.3 -网络类
IPv4 地址的空间限制为 4294967296(232)个地址(约 40 亿)。 在这些地址中，大约有 1800 万个保留用于特殊用途(例如，私有网络)，大约 2.7 亿个是多播地址。
组播地址是一组 IP 地址的逻辑标识符。 有关组播地址的更多信息，请参考RFC 6308(https://tools.ietf.org/html/rfc6308)。
在互联网的早期阶段，IPv4 地址中最高阶字节(第一组)表示网络号。 随后的字节进一步表示网络层次结构和子网络，最低阶的字节标识设备本身。 这种方案很快被证明不适合网络层次结构和隔离，因为它只允许 256(28)个网络，用 IPv4 地址的前导字节表示。 随着附加网络的加入，每个网络都有自己的标识，IP 地址规范需要一个特殊的修订来适应一个标准模型。 1981 年引入的有类网络规范解决了这个问题，它根据地址的前 4 位将 IPv4 地址空间划分为 5 个类，如下图所示:
图 7.4 -网络类
有关网络类的更多信息，请参考RFC 870(https://tools.ietf.org/html/rfc870)。 在上表中，最后一列指定了这些网络类的默认子网掩码。 下面我们来看看子网(或子网络)。
子网(或子网)是 IP 网络的逻辑细分。 子网被引入的目的是识别属于到同一网络的设备。 同一网络中设备的 IP 地址具有相同的最有效组。 子网定义在两个字段中对 IP 地址进行了逻辑划分:网络标识符和主机标识符。 子网的数字表示法称为子网掩码或子网掩码。 下面的表给出了一个网络标识符和终端标识符的例子:
图 7.5 -带有网络和主机标识符的子网
使用我们的 IPv4 地址(192.168.1.53)，我们可以设计一个网络标识符192.168.1和主机标识符53。 得到的子网掩码如下:
192.168.1.0我们去掉了子网掩码中最不重要的组，即表示主机标识符(53)，并将其替换为0。 本例中的0表示子网中的起始地址。 也就是说，该子网允许在0~255范围内的任何主机标识符值。 例如，192.168.1.92的 IP 地址是192.168.1.0网络中的一个有效(且被接受的)IP 地址。
另一种备选的子网表示法是所谓的无分类域间路由(CIDR)表示法。 CIDR 将 IP 地址表示为网络地址(前缀)，后跟一个斜杠(/)和前缀的位长。 在我们的例子中，192.168.1.0子网的 CIDR 表示法如下:
192.168.1/24网络地址的前三组组成了3 x 8 = 24位，因此有了/24表示法。
通常，子网的规划以主机标识符地址为起点。 回到我们的示例，假设我们希望网络中的主机标识符地址以100开始，以125结束。
192.168.1.100的二进制表示是:
11000000.10101000.00000001。 01100100
前面序列中的最后一组(高亮显示)表示主机标识符(100)。 最接近保留的 99 个地址的二进制值是96 = 64 + 32。 等价的二进制值如下:
11100000换句话说，主机标识符中三个最重要的位是保留的。 子网表示法中的保留位显示为1。 这些位将被加到网络地址(192.168.1)的 24 个已经保留的位上，总计为27 = 24 + 3位。 这里是等价的表示:
11111111.11111111.11111111.11100000因此，最终的 netmask 是这样的:
255.255.255.224对应子网的 CIDR 表示法如下:
192.168.1.96/27主机标识符组的其余 5 位表示子网中从97开始的 25 = 32 个可能的地址。 这将限制最大主机标识符值为127 = 96 + 32 - 1。 (我们减去 1 来表示总共 32 个中的 97 个)。 在 32 个地址范围内，最后一个 IP 地址被保留为广播地址，如下所示:
192.168.1.127在适用的情况下，广播地址(T0)作为网络或子网中的最高数量保留。 回到我们的例子，不包括广播地址，子网中的最大主机 IP 地址是:
192.168.1.126您可以在RFC 1918(https://tools.ietf.org/html/rfc1918)中了解更多关于子网的信息。 既然我们提到了广播地址，让我们快速浏览一下。
广播地址是网络或子网络中的保留 IP 地址，用于向该网络中的所有设备发送集合消息(数据)。 广播地址是网络或子网中的最后一个 IP 地址。
*例如:192.168.1.0/24网络的广播地址为192.168.1.255。 在上一节的示例中，192.168.1.96/27子网的广播地址为192.168.1.127(127 = 96 + 32 - 1)。
详情请浏览https://en.wikipedia.org/wiki/Broadcast_address。
一个 IPv6 地址是一个 128 位(16 字节)的数字，通常表示为 8 组 2 字节(16 位)的数字，由一列(:)分隔。 这 8 组中的每个数字都是十六进制数，其值在0000和FFFF之间。 下面是一个 IPv6 地址的例子:
2001:0b8d:8a52:0000:0000:8b2d:0240:7235前面的 IPv6 地址的等价表示显示在这里:
2001:b8d:8a52::8b2d:240:7235/64在第二种表示法中，省略前导零，将全零组(0000:0000)合并为空组(::)。 最后的/64符号表示 IPv6 地址的前缀长度。 IPv6 前缀长度相当于 IPv4 子网的 CIDR 表示法。 对于 IPv6，前缀长度为1~128之间的整数值。
在我们的例子中，前缀长度为 64 位(4 x 16)，子网看起来像这样:
2001:b8d:8a52::子网代表四个前导组(2001，0b8d，8a52，0000)，共4 × 16 = 64 位。 在 IPv6 子网的简化表示中，前导的零被省略，全零组被折叠为::。
IPv6 的子网划分与 IPv4 非常相似。 由于相关的概念已经在 IPv4 一节中介绍，所以我们在这里不深入讨论细节。 更多关于 IPv6 的信息，请参考RFC 2460(https://tools.ietf.org/html/rfc2460)。
在熟悉了 IP 地址之后，应该介绍一些相关的网络构造—套接字和端口—为 IP 地址的软件实现服务。
套接字是一种软件数据结构，表示用于通信的网络节点。 虽然是一个编程概念，但在 Linux 中，网络套接字最终是一个通过网络应用编程接口(API)控制的文件描述符。 套接字是应用进程用来传输和接收数据的。 应用可以创建和删除套接字。 在创建套接字的进程的生命周期之后，套接字不能处于活动状态(发送或接收数据)。
网络套接字在 OSI 模型的传输层级别上操作。 套接字连接有两个端点——发送端和接收端。 发送方和接收方都有自己的 IP 地址。 因此，套接字数据结构中的关键信息是拥有套接字的端点的IP 地址。
两个端点通过使用这些套接字的网络进程来创建和管理它们的套接字。 发送方和接收方可以同意使用多个连接来交换数据。 其中一些连接甚至可以并行运行。 我们如何区分这些套接字连接? IP 地址本身是不够的，这是端口发挥作用的地方。
网络端口是一个逻辑结构，用于识别主机上运行的特定进程或网络服务。 端口的取值范围为065535。 通常，01024范围内的端口被分配给系统中使用最多的服务。 这些端口也称为知名端口。 下面是一些知名端口的例子以及它们各自的相关网络服务:
25-smtp21-ftp22-ssh53-dns67，68-DHCP (client =68，server =67)80-http443-HTTP 安全(HTTPS)
除1024外的端口号是通用的，也被称为临时端口。
一个端口总是与一个 IP 地址相关联。 最终，套接字是 IP 地址和端口的组合。 有关网络套接字的更多信息，您可以参考RFC 147(https://tools.ietf.org/html/rfc147)。 关于知名端口，请参见RFC 1340(https://tools.ietf.org/html/rfc1340)。
接下来，让我们看看如何在 Linux 中配置本地网络堆栈，从而应用到目前为止所获得的知识。
本节描述 Ubuntu 和 CentOS 平台的 TCP/IP 网络配置，使用的是他们最新发布的版本。 相同的概念适用于大多数 Linux 发行版，尽管其中涉及的一些网络配置实用程序和文件可能有所不同。
我们使用ip命令行实用程序来检索系统的当前 IP 地址，如下所示:
ip addr这里显示了一个输出示例:
图 7.6 -使用 IP 命令检索当前的 IP 地址
我们突出显示了一些相关信息，例如网络接口 ID(2: ens33)和带子网前缀的 IP 地址(172.16.146.133/24)。
接下来让我们看看 Ubuntu 的网络配置。 在撰写本文时，Ubuntu 当前发布的版本是 20.04。
Ubuntu 20.04 提供了netplan命令行实用程序，便于网络配置。 netplan使用YAML Ain't Markup Language(YAML)配置文件生成网络接口绑定。 netplan配置文件位于/etc/netplan/目录中，如下代码片段所示:
ls /etc/netplan/在我们的例子中，配置文件是00-installer-config.yaml，如下所示:
图 7.7 -检索网络规划配置文件
更改网络配置涉及到编辑netplanYAML 配置文件。 作为一种良好的实践，在进行更改之前，我们应该始终对当前配置文件进行备份。
我们先来看看动态 IP 地址。
要启用动态(DHCP) IP 地址，我们编辑netplan配置文件，并将我们选择的网络接口(本例中为ens33)的dhcp4属性设置为true，如下所示:
sudo nano /etc/netplan/00-installer-config.yaml下面是相关的配置摘录，相关的要点突出显示:
图 7.8 - netplan 配置中启用 DHCP
保存配置文件后，我们可以使用以下命令测试相关的更改:
sudo netplan try我们得到以下响应:
图 7.9 -测试和接受网络计划配置更改
netplan验证新配置并提示接受更改。 将当前的更改应用到系统中:
sudo netplan apply接下来，我们使用netplan配置一个静态 IP 地址。
要设置网络接口的静态 IP 地址，我们首先编辑netplan配置 YAML 文件，如下所示:
sudo nano /etc/netplan/00-installer-config.yaml下面是一个静态 IP 地址为172.16.146.100/24的配置示例:
图 7.10 -使用 netplan 的静态 IP 配置示例
在保存配置之后，我们可以测试和接受，然后应用更改，就像我们在Dynamic IP部分所做的那样，使用以下命令:
sudo netplan try
sudo netplan apply有关netplan命令行实用程序的更多信息，请参阅netplan --help或相关的系统手册(man netplan)。
接下来我们将在 CentOS 的网络配置中查看。 在撰写本文时，当前发布的Red Hat Enterprise Linux(RHEL)/CentOS 版本是 CentOS 8。
在 CentOS 8 中有两种配置和管理网络接口的方法，概述如下:
- 手动编辑
/etc/sysconfig/network-scripts/中的网络接口文件 - 使用
nmcli命令行实用程序
网络配置文件位于/etc/sysconfig/networks-scripts/目录中，如下面的代码片段所示。 它们根据相应的网络接口 ID 命名，前缀为ifcfg。 在我们的例子中，我们使用以下命令检索配置文件:
ls /etc/sysconfig/networks-scripts/输出如下:
图 7.11 -检索网络配置文件
唯一的网络配置文件是ifcfg-ens33，它对应于ens33网络接口。
让我们先看看动态 IP 地址。
以下是针对ifcfg-ens33的 DHCP 配置示例:
图 7.12 -动态 IP 配置
动态 IP 地址启用BOOTPROTO="dhcp"。 BOOTPROTO可能的值如下:
dhcp-使用 DHCP 协议设置动态 IP 地址bootp-使用Bootstrap(BOOTP)协议来设置动态 IP 地址none-使用静态 IP 地址
要应用这些更改，我们需要重新启动(down和up)相关的网络接口(ens33)，代码如下:
sudo nmcli connection down ens33
sudo nmcli connection up ens33为了使用ncmli配置动态 IP 地址，我们运行如下命令:
sudo nmcli connection modify ens33 IPv4.method autoIPv4.method auto指令使能 DHCP。
接下来让我们配置一个静态 IP 地址。
下面是ifcfg-ens33的静态 IP 配置示例:
图 7.13 -静态 IP 配置
相关的变化被突出显示。 BOOTPROTO="none"禁用 DHCP。 IPADDR、PREFIX设置静态 IP 地址172.16.146.136/24。 我们还指定了网关和 DNS 服务器。
更改用以下代码保存:
sudo nmcli connection down ens33
sudo nmcli connection up ens33要使用ncmli执行等效的静态 IP 地址更改，我们需要运行多个命令。 首先，我们设置静态 IP 地址，如下:
sudo nmcli connection modify ens33 IPv4.address 172.16.146.136/24如果我们没有配置以前的静态 IP 地址，我们建议在继续下一步之前保存之前的更改。 使用以下代码保存更改:
sudo nmcli connection down ens33
sudo nmcli connection up ens33接下来，我们设置网关和 DNS IP 地址，如下所示:
sudo nmcli connection modify ens33 IPv4.gateway 172.16.146.2
sudo nmcli connection modify ens33 IPv4.dns 8.8.8.8最后，我们用以下代码禁用 DHCP:
sudo nmcli connection modify ens33 IPv4.method manual在这些改变之后，我们需要重新启动ens33网络接口，代码如下:
sudo nmcli connection down ens33
sudo nmcli connection up ens33接下来，我们将看看如何更改 Linux 机器的主机名。
要检索 Linux 机器上的当前主机名，我们可以使用hostname或hostnamectl命令，如下所示:
hostname在我们的例子中，响应是这样的:
图 7.14 -获取当前主机名
更改主机名最方便的方法是使用hostnamectl命令。 我们可以用以下代码将主机名更改为jupiter:
sudo hostnamectl set-hostname jupiter这次让我们用hostnamectl命令验证主机名的更改，如下所示:
hostnamectl与hostname命令相比，hostnamectl命令的输出提供了更详细的信息，如下所示:
图 7.15 -使用 hostnamectl 命令获取当前主机名
或者，可以使用hostname命令临时更改主机名*，如下所示:*
sudo hostname jupiter但是，除非我们也改变了/etc/hostname和/etc/hosts文件中的主机名，否则将无法在重新引导后存活，如下所示:
图 7.16 - /etc/hostname 和/etc/hosts 文件
在重新配置主机名之后，注销然后登录通常会反映更改。
在本节中，我们列举了一些在 Linux 上运行的最常见的网络服务。 在您所选择的 Linux 平台上，并不是这里提到的所有服务都是默认安装或启用的。 第八章,配置 Linux 服务器、【显示】和第 9 章,获得 Linux【病人】,进入如何安装和配置其中的一些。 本节的重点仍然是这些网络服务是什么，它们是如何工作的，以及它们用于通信的网络协议。
网络服务通常是为数据通信目的实现应用层(OSI 第 7 层)功能的系统进程。 网络服务通常设计为点对点或客户机-服务器架构。
在点对点网络中，多个网络节点在共享和交换公共数据集的同时，各自运行它们自己的具有同等特权的网络服务实例。 以一个 DNS 服务器网络为例，所有服务器都共享和更新它们的域名记录。
客户机-服务器网络通常涉及网络上的一个或多个服务器节点，以及多个客户机与任何这些服务器通信。 客户机-服务器网络服务的一个例子是 SSH。 SSH 客户端通过安全终端会话连接到远程 SSH 服务器，可能是出于远程管理的目的。
下面的每一小节都简要描述了一个网络服务，我们鼓励您进一步探索感兴趣的相关主题。 让我们从 DHCP 服务器开始。
DHCP 服务器使用 DHCP 协议使网络中的设备能够请求动态分配的 IP 地址。 本章前面的TCP/IP 协议一节简要描述了 DHCP 协议。
请求 DHCP 服务的计算机或设备在网络上发送广播消息(或查询)来定位 DHCP 服务器，DHCP 服务器提供所请求的 IP 地址和其他信息。 DHCP 客户端(设备)与服务器之间使用 DHCP 协议进行通信。
DHCP 协议在客户端和服务器之间的初始发现工作流在 OSI 模型中的数据链路层(2)上运行。 由于第二层使用网络帧作为 pdu，因此 DHCP 发现报文不能跨越本地网络边界。 即 DHCP 客户端只能向本地DHCP 服务器发起通信。
在最初的握手(在第 2 层)之后，DHCP 使用数据报套接字(第 4 层)转向 UDP 作为其传输协议。由于 UDP 是无连接协议，DHCP 客户端和服务器无需事先安排就可以交换消息。 因此，两个端点(客户机和服务器)都需要一个众所周知的 DHCP 通信端口来进行来回的数据交换。 这些是众所周知的端口68(对于 DHCP 服务器)和67(对于 DHCP 客户端)。
*DHCP 服务器为网络中请求 DHCP 服务的每个设备维护 IP 地址和其他客户端配置数据(如 MAC 地址和域服务器地址)。
DHCP 服务器采用leasing机制动态分配 IP 地址。 租赁 IP 地址受租赁时间的限制，可以是有限的，也可以是无限的。 当 IP 地址的租期到期时，DHCP 服务器可能会根据请求将其重新分配给其他客户端。 设备通过定期向 DHCP 服务器请求租约更新来保持其动态 IP 地址。 否则，可能导致设备动态 IP 地址丢失。 如果先前的地址已经被 DHCP 服务器分配，一个迟来的(或租期后的)DHCP 请求可能会导致一个新的 IP 地址被获取。
在 Linux 机器上查询 DHCP 服务器的一个简单方法是调用以下命令:
ip route这是前一个命令的输出:
图 7.17 -查询 DHCP 信息的 IP 路由
输出的第一行提供 DHCP 服务器(172.16.146.2)。
第八章，配置 Linux 服务器，将进一步深入到安装和配置 DHCP 服务器的实际细节。
更多关于 DHCP 的信息，请参考RFC 2131(https://tools.ietf.org/html/rfc2131)。
域名服务器(DNS**),也称为名称服务器【显示】,提供了一个名称解析机制,将主机名(如wikipedia.org)到一个 IP 地址(如208.80.154.224)。 名称解析协议是 DNS，在本章前面的TCP/IP 协议section 中有简要描述。 在 dns 管理的 TCP/IP 网络中，计算机和设备也可以通过主机名(而不仅仅是 IP 地址)来识别和相互通信。**
作为一个合理的类比，DNS 非常类似于地址簿。 主机名比 IP 地址更容易记忆。 即使在一个只有几台计算机和设备连接的本地网络中，也很难通过简单地使用 IP 地址来识别(或记忆)任何主机。 互联网依赖全球分布的 DNS 服务器网络。
有四个不同类型的 DNS 服务器:递归服务器、根服务器、**顶级域名(TLD)**服务器【显示】,和权威服务器。 所有这些 DNS 服务器类型一起工作，为您带来互联网，因为您体验它在您的浏览器。
一个递归 DNS 服务器是一个解析器，它可以帮助你找到你搜索的网站的目的地(IP)。 当你做一个查找操作时，一个递归 DNS 服务器连接到不同的其他 DNS 服务器，以找到你正在寻找的 IP 地址，并以网站的形式返回给你。 由于缓存了执行的每个查询，递归 DNS 查找速度更快。 在递归类型的查询中，DNS 服务器调用自身并进行递归，同时仍向其他 DNS 服务器发送请求以寻找答案。 还有一种迭代类型的 DNS 查找。
每个 DNS 服务器直接执行迭代 DNS查找，而不使用缓存。 例如，在迭代查询中，每个 DNS 服务器都响应另一个 DNS 服务器的地址，直到其中一个服务器具有与所讨论的主机名匹配的 IP 地址并响应客户机。 有关 DNS 服务器类型的详细信息，请查看以下 Cloudflare 学习解决方案:https://www.cloudflare.com/learning/dns/what-is-dns/。
DNS 服务器维护(并可能共享)一组数据库文件，也称为区域文件—通常是简单的纯文本 ASCII 文件，存储名称和 IP 地址映射。 在 Linux 中，一个这样的 DNS 解析器文件是/etc/resolv.conf。
要查询管理本机的 DNS 服务器，我们可以通过运行以下代码来查询/etc/resolv.conf文件:
cat /etc/resolv.conf | grep nameserver输出产生以下代码:
图 7.18 -使用/etc/resolv.conf 查询 DNS 服务器
查询网络上任意主机名称服务器数据的一种简单方法是使用nslookup工具。 如果您的系统上没有安装nslookup实用程序，您可以使用下面列出的命令来安装。
在 Ubuntu/Debian 上执行如下命令:
sudo apt-get install dnsutils在 CentOS 操作系统上运行如下命令:
sudo yum install bind-utils例如，要查询本地网络中名为neptune.local的计算机的名称-服务器信息，我们运行以下命令:
nslookup neptune.local输出如下所示:
图 7.19 -使用 nslookup 查询名称-服务器信息
我们还可以交互地使用nslookup工具。 例如，要查询wikipedia.org的名称-服务器信息，我们可以简单地运行以下命令:
nslookup然后在交互提示中输入wikipedia.org:如下所示:
图 7.20 -交互式地使用 nslookup 工具
按Ctrl+C退出交互式 shell 模式。 下面是对前面输出中显示的信息的简要解释:
- 服务器(地址):本地运行的 DNS 服务器的环回地址(T0)和端口(T1)
- 名称:我们正在查询的互联网域名(wikipedia.org)
- 地址:IPv4(
208.80.154.224)和 IPv6(2620:0:861:ed1a::1)地址对应于查找域(wikipedia.org)
nslookup在提供 IP 地址时也可以进行反向 DNS 搜索。 下面的命令检索 IP 地址8.8.8.8对应的名称服务器(dns.google):
nslookup 8.8.8.8该命令输出如下:
图 7.21 -使用 nslookup 进行反向 DNS 搜索
有关nslookup工具的更多信息，您可以参考nslookup系统参考手册(man nslookup)。
或者，我们可以使用dig命令行实用程序。 如果您的系统上没有安装dig实用程序，您可以通过在 Ubuntu/Debian 上安装dnsutils包或在 CentOS 平台上安装bind-utils来实现。 安装包的相关命令在前面用nslookup显示。
例如，下面的命令检索本地网络中名为jupiter.local.localdomain的计算机的名称-服务器信息:
dig jupiter.local.localdomain这是结果(参见高亮显示的ANSWER SECTION):
图 7.22 -使用 dig 查询名称-服务器信息
要使用dig执行反向 DNS 查找，我们指定-x选项，在后面加上一个 IP 地址(例如8.8.4.4)，如下所示:
dig -x 8.8.4.4该命令产生以下输出(请参阅突出显示的ANSWER SECTION):
图 7.23 -使用 dig 进行反向 DNS 查找
有关dig命令行实用程序的更多信息，请参考相关的系统手册(man dig)。
DNS 协议运行在 OSI 模型的应用层(7)。 标准 DNS 服务知名端口为53。
第八章，配置 Linux 服务器，将进一步深入到 DNS 服务器的安装和配置的实际细节。 有关 DNS 的更多信息，请参考RFC 1035(https://www.ietf.org/rfc/rfc1035.txt)。
DHCP 和 DNS 网络服务可以说是最接近 TCP/IP 网络堆栈的，当计算机或设备连接到网络时，它们扮演着至关重要的角色。 毕竟，没有正确的 IP 地址和名称解析，就没有网络通信。
显然，分布式网络和相关的应用服务器不仅仅是 DNS 和 DHCP 服务器执行的严格的纯网络管理堆栈。 在下面几节中，我们将快速浏览一下在分布式 Linux 系统上运行的一些最相关的应用服务器。
独立 Linux 系统通常使用默认的身份验证机制，其中用户凭据存储在本地文件系统中(例如/etc/passwd，/etc/shadow)。 我们在本书前面的第 4 章、管理用户和组中探讨了相关的用户认证内部机制。 但是，当我们将身份验证边界扩展到本地机器之外时——例如，访问文件或电子邮件服务器——在远程主机和本地主机之间共享用户凭据将成为一个严重的安全问题。
理想情况下，我们应该在网络上有一个集中式的身份验证端点，由安全的身份验证服务器处理。 在用户可以访问远程系统资源之前，应该使用可靠的加密机制验证用户凭据。
让我们考虑一下对任意文件服务器上的网络共享的安全访问。 假设访问需要活动目录(AD)用户身份验证。 在用户的客户机机器上本地创建相关的挂载(共享)将提示输入用户凭据。 身份验证请求由文件服务器(代表客户端)向身份验证服务器发出。 如果认证成功，客户端可以使用服务器共享。 下图展示了使用轻量级目录访问协议(LDAP)身份验证端点在客户端和服务器之间的简单远程身份验证流程:
图 7.24 -使用 LDAP 的身份验证工作流
标准安全身份验证平台(适用于 Linux)的示例包括:
- Kerberos(https://en.wikipedia.org/wiki/Kerberos_(protocol)
- LDAP(T2】https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)
- 远程认证拨号用户业务(RADIUS)(https://en.wikipedia.org/wiki/RADIUS)
- 直径(https://en.wikipedia.org/wiki/Diameter_(protocol)
- 终端接入控制器接入控制系统(TACACS+)(https://datatracker.ietf.org/doc/rfc8907/)
我们就去/安装和配置 Linux 的 LDAP 身份验证服务器(使用 OpenLDAP**)在配置 LDAP 服务器【显示】的第 9 章【病人】,获得 Linux。**
在本节中，我们通过一个使用文件服务器的示例说明了身份验证工作流。 为了继续这个话题，让我们接下来看看网络文件共享服务。
在通常的网络术语中，文件共享表示客户机机器能够装入并访问属于服务器的远程文件系统，就好像它是本地的一样。 在客户端机器上运行的应用将直接访问服务器上的共享文件。 例如，文本编辑器可以加载和修改远程文件，然后将其保存回相同的远程位置，这一切都是无缝和透明的操作。 底层的远程处理进程——作为本地文件系统的远程文件系统的外观——通过文件共享服务和协议得以实现。
对于每个文件共享网络协议，都有一个相应的客户机-服务器文件共享平台。 尽管大多数网络文件服务器(和客户机)具有跨平台实现，但一些操作系统平台更适合于特定的文件共享协议，正如我们将在以下小节中看到的那样。 选择不同的文件服务器实现和协议归根结底是兼容性、安全性和性能的问题。
下面是一些最常见的文件共享协议，并对每个协议进行了简要描述。
服务器消息块(SMB)协议提供网络发现、文件和打印机共享服务。 SMB 还支持通过网络进行进程间通信。 SMB 是一个比较老的协议，由International Business Machines Corporation(IBM)于 20 世纪 80 年代开发。 最终，微软接手并通过多个版本(SMB 1.0、2.0、2.1、3.0、3.0.2 和 3.1.1)对当前版本进行了相当大的修改。
Common Internet File System(CIFS)协议是 SMB 协议的一种特殊实现。 由于底层协议的相似性，SMB 客户机将能够与 CIFS 服务器通信，反之亦然。 虽然 SMB 和 CIFS 在习惯上是相同的，但它们在文件锁定、批处理和最终性能方面的内部实现有很大的不同。 除了遗留系统，CIFS 目前很少使用。 SMB 应该总是优先于 CIFS，特别是对于 SMB 2 或 SMB 3 的最新版本。
与 CIFS 一样，Samba是 SMB 协议的另一个实现。 Samba 为各种服务器平台上的 Windows 客户机提供文件和打印共享服务。 换句话说，Windows 客户机可以无缝地访问 Linux Samba 服务器上的目录、文件和打印机，就好像它们在与 Windows 服务器通信一样。
从第 4 版开始，Samba 本地支持 Microsoft AD 和 Windows NT 域。 实际上，Linux Samba 服务器可以充当 Windows AD 网络上的域控制器。 因此，Windows 域中的用户凭据可以透明地在 Linux 服务器上使用，而不需要重新创建，然后手动地与 AD 用户保持同步。
网络文件系统(NFS)协议是由 Sun Microsystems 开发的，本质上在与 smb 相同的前提下通过网络访问文件，就好像它们是本地文件一样。 NFS 不兼容 CIFS 或 SMB, NFS 客户端不能直接与 SMB 服务器通信，反之亦然。
大多数时候，NFS 是 Linux 网络中选择的文件共享协议。 对于混合的网络环境(例如 Windows、Linux 和 macOS 互操作性)，samba 和 SMB 最适合于文件共享。
Apple Filing Protocol(AFP)是 Apple 设计的文件共享协议，仅在 macOS 网络环境下运行。 我们应该注意，除了 AFP 之外，macOS 系统还支持标准的文件共享协议，比如 SMB 和 NFS。
一些文件共享协议(如 SMB)也支持打印共享，并被打印服务器使用。 接下来让我们仔细看看印刷品共享。
打印机服务器(或打印服务器)使用打印协议将打印机连接到网络上的客户机机器(计算机或移动设备)。 打印协议在网络上负责以下远程打印任务:
- 发现打印机或打印服务器
- 查询打印机的状态
- 正在发送、接收、排队或取消打印作业
- 查询打印作业状态
常见的打印协议包括:
- Line Printer Daemon(LPD)协议
- 通用协议:SMB; Telnet
- 无线打印协议(如苹果AirPrint)
- Internet打印协议(如谷歌 Cloud Print)
在通用打印协议中，SMB(也是一种文件共享协议)已经在文件共享一节中介绍过。 TELNET 通信协议在远程访问部分介绍。
文件和打印机共享服务主要是关于在网络上的计算机之间共享文件，数字或打印的文件。 当涉及到交换文档时，额外的网络服务将发挥作用，例如文件传输和电子邮件服务。 接下来让我们看看文件传输。
FTP 是一种标准的网络协议，用于在网络上的计算机之间传输文件。 FTP 运行在一个客户端-服务器环境中，其中 FTP 客户端发起一个远程连接到 FTP 服务器，文件正在中向任意一个方向传输。 FTP 在客户端和服务器之间维护一个控制连接和一个或多个数据连接。 控制连接通常建立在 FTP 服务器的端口21上，用于在客户端和服务器之间交换命令。 数据连接专门用于数据传输，并在客户端和服务器之间协商(通过控制连接)。 数据连接通常涉及入站流量的临时端口，它们只在实际数据传输期间保持打开状态，在传输完成后立即关闭。
FTP 以以下两种模式之一*协商数据连接:
- 活动模式—FTP 客户端向 FTP 服务器发送
PORT命令，通知客户端活动提供入站端口号用于数据连接。 - 被动模式- FTP 客户端向 FTP 服务器发送
PASV命令，表示客户端被动地等待服务器为入站数据连接提供端口号。
由于所涉及的数据连接的动态特性，当涉及到防火墙配置时，FTP 是一个相对“混乱”的协议。 控制连接的端口通常是众所周知的(如港口21不安全的 FTP)但数据连接是起源于不同的端口(通常是20),在接收端入站套接字被打开在一个预先配置的短暂的范围(1024-65535)。
FTP 通常通过以下两种方法之一以安全的方式实现:
- FTP over SSL(FTPS)-SSL /TLS-encryptedFTP 连接。 缺省情况下，FTPS 控制连接端口为“
990”。 - SSH 文件传输协议(SFTP)-FTPoverSSH。 默认 SFTP 控件连接端口为
22。 有关 SSH 协议和客户端-服务器连接的更多信息，请参考本章后面的远程访问部分中的SSH。
第九章，保护 Linux，详细介绍了 Linux FTP 服务器的实际实现。
接下来，我们将研究邮件服务器和底层的电子邮件交换协议。
一个邮件服务器(或邮件服务器)负责通过网络发送邮件。 邮件服务器可以在同一网络(域)上的客户端(用户)之间交换电子邮件(在公司或组织内)，也可以将电子邮件发送到其他邮件服务器(可能超出本地网络，如 internet)。
电子邮件交流通常涉及以下参与者:
- 电子邮件客户端应用(如 Outlook 或 Gmail)
- 一个或多个邮件服务器(交换; Gmail 服务器)
- 邮件交换中涉及的收件人—一个发件人和一个或多个收件人
- 一个电子邮件协议控制电子邮件客户端和邮件服务器之间的通信
最常用的电子邮件协议是POP3、IMAP和SMTP。 让我们仔细看看每一个协议。
POP 版本 3(POP3)是一个标准的电子邮件协议，用于从远程邮件服务器接收和下载电子邮件到本地电子邮件客户端。 使用 POP3，电子邮件可以离线阅读。 下载后，邮件通常从 POP3 服务器删除，从而节省空间。 现代 POP3 邮件客户端-服务器实现(Gmail; Outlook)也有在服务器上保留电子邮件副本的选项。 当用户从多个位置(客户端应用)访问电子邮件时，在 POP3 服务器上持久化电子邮件变得非常重要。
默认的 POP3 端口概述如下:
110-用于不安全的(未加密的)POP3 连接995-用于使用 SSL/TLS 加密的安全 POP3
POP3 是一个相对较旧的电子邮件协议，并不总是适合现代电子邮件通信。 当用户从多个设备访问电子邮件时，IMAP 是一个更好的选择。 接下来让我们看看 IMAP 电子邮件协议。
IMAP 是一个标准的电子邮件协议，用于在远程 IMAP 邮件服务器上访问电子邮件。 使用 IMAP，电子邮件总是保留在邮件服务器上，而 IMAP 客户机可以使用电子邮件的副本。 用户可以在多个设备上访问电子邮件，每个设备都有其 IMAP 客户端应用。
这里列出了默认的 IMAP 端口:
143-用于不安全(未加密)的 IMAP 连接993-用于使用 SSL/TLS 加密的安全 IMAP
POP3 和 IMAP 都是接收邮件的标准协议。 要发送电子邮件，SMTP 开始发挥作用。 接下来让我们看看 SMTP 电子邮件协议。
SMTP 是一个标准的电子邮件协议，用于通过网络或互联网发送电子邮件。
默认的 SMTP 端口概述如下:
25-用于不安全的(未加密的)SMTP 连接465或587表示使用 SSL/TLS 加密的安全 SMTP
在使用或实现本节中描述的任何标准电子邮件协议时，如果可能，总是建议使用带有最新 TLS 加密的相应安全实现。 POP3、IMAP 和 SMTP 还支持用户身份验证，这是一种额外的安全层——在商业或企业级环境中也是推荐的。
为了了解 SMTP 协议是如何操作的，让我们通过一些初始步骤来启动与谷歌的 Gmail SMTP 服务器的 SMTP 握手。
我们通过连接到 Gmail SMTP 服务器，通过openssl命令使用安全(TLS)连接，如下所示:
openssl s_client -starttls smtp -connect smtp.gmail.com:587我们调用openssl命令，模拟客户端(s_client)，启动 TLS SMTP 连接(-starttls smtp，并在端口587``(-connect smtp.gmail.com:587上连接到远程 SMTP 服务器 Gmail。
Gmail SMTP 服务器响应一个相对较长的 TLS 握手块，以以下内容结束:
图 7.25 -与 SMTP 服务器 Gmail 的初始 TLS 握手
接下来，我们使用HELO命令(精确拼写为 T0)发起 SMTP 通信。 谷歌期待以下HELO问候:
HELO hellogoogle接下来是另一次握手，以250 smtp.gmail.com at your service结束，如下所示:
图 7.26 - Gmail SMTP 服务器已准备好进行通信
接下来，Gmail SMTP 服务器需要通过AUTH LOGINSMTP 命令进行身份验证。 我们不会深入讨论细节，但这里要说明的关键问题是，SMTP 协议遵循客户机和服务器之间的明文命令序列。 采用一个安全的(加密的)SMTP 通信通道，使用 TLS 是非常重要的。 这同样适用于任何其他电子邮件协议(POP3; IMAP)。
到目前为止，我们已经覆盖了几种网络服务，其中一些跨越多个网络甚至互联网。 网络数据包在有效载荷内携带数据和目标地址，但是在通信端点之间也有同步信号，主要用于识别发送和接收工作流。 网络报文的同步是基于时间戳的。 如果没有网络节点之间高度精确的时间同步，就不可能实现可靠的网络通信。 接下来我们将讨论网络计时器。
NTP 是用于网络上计算机之间的时钟同步的标准网络协议。 NTP 尝试在协调世界时的几毫秒内同步参与计算机上的系统时钟(UTC)——世界时间参考。
NTP 协议实现通常采用客户机-服务器模型。 NTP 服务器作为网络上的时间源，通过广播或发送更新的时间戳数据报给客户端。 NTP 服务器根据全球知名的精确时间服务器不断调整其系统时钟，使用专门的算法来减少网络延迟。
在我们选择的 Linux 平台上，检查 NTP 同步状态的一种相对简单的方法是使用ntpstat实用程序。 ntpstat可能不是我们系统上默认安装的。 在 Ubuntu 上，我们可以用以下命令安装它:
sudo apt-get install ntpstat在 CentOS 上，我们用以下命令安装ntpstat:
sudo yum install ntpstatntpstat需要一个本地运行的 NTP 服务器。 使用实例查询 NTP 同步状态。
ntpstat下面是输出:
图 7.27 -使用 ntpstat 查询 NTP 同步状态
ntpstat提供国家结核控制规划服务器的 IP 地址系统同步(74.6.168.72),同步保证金(17毫秒),和 time-update 轮询间隔1024(s),找到更多关于国家结核控制规划服务器,我们可以dig其 IP 地址下面的代码:
dig -x 74.6.168.72它看起来像是雅虎的时间服务器之一(t1.time.gq1.yahoo.com)，如图所示:
图 7.28 -使用 ntpstat 查询 NTP 同步状态
NTP 客户端-服务器通信使用 UDP 作为端口123上的传输协议。 第八章，配置 Linux 服务器，有专门的一节用于安装和配置 NTP 服务器。 有关 NTP 的详细信息，请参考https://en.wikipedia.org/wiki/Network_Time_Protocol。
我们在网络服务器和协议之间的简短旅程将在此结束。 每天的 Linux 管理任务通常需要对系统进行某种类型的远程访问。 有许多方法可以远程访问和管理计算机。 我们的下一节描述一些最常见的远程访问设施和相关的网络协议。
大多数 Linux 网络服务提供一个相对有限的远程管理接口,与他们管理命令行界面(CLI)公用事业公司主要经营本地的同一系统上运行服务。 因此，相关的管理任务承担本地终端访问。 通过控制台直接访问系统有时是不可能的。 此时，远程访问服务器开始发挥作用，启用与远程机器的虚拟终端登录会话。
接下来让我们看看一些最常见的远程访问服务和应用。
SSH 可能是用于远程访问的最流行的安全登录协议。 SSH 使用强加密，结合用户身份验证机制，在客户机和服务器机器之间实现安全通信。 SSH 服务器相对容易安装和配置，第八章，配置 Linux 服务器有专门的章节描述了相关步骤。
SSH 的默认网口为22。
SSH 支持以下两种认证方式:
- 公共密钥身份验证
- 基于主机的认证
- 密码身份验证
- Keyboard-interactive 身份验证
下面几节简要描述了这些 SSH 身份验证表单。
公钥(或 SSH-key)认证可以说是最常见的 SSH 认证类型。
重要提示
本节将交替使用术语公钥和SSH-key，主要是为了反映 Linux 社区中相关的 SSH 身份验证术语。
SSH-key 认证机制使用证书/密钥对-公钥密钥(证书)和私钥密钥。 SSH 证书/密钥对通常用ssh-keygen创建的工具,使用标准加密算法如Rivest-Shamir-Adleman 算法(RSA【病人】)或数字签名算法(【t16.1】DSA)。****
SSH 公钥认证支持基于用户的认证和基于主机的认证两种模式。 这两个模型所涉及的证书/密钥对的所有权不同。 通过客户端身份验证，每个用户都有自己的证书/密钥对用于 SSH 访问。 另一方面，主机身份验证涉及每个系统(主机)的单个证书/密钥对。
这两种 SSH-key 身份验证模型将在下面几节中进行说明和解释。 这两个模型的基本 SSH 握手和身份验证工作流是相同的。 首先，SSH 客户端生成一个安全的证书/密钥对，并与 SSH 服务器共享其公钥。 这是用于启用公钥身份验证的一次性操作。
当客户机发起 SSH 握手时，服务器请求客户机的公钥，并根据其允许的公钥验证它。 如果匹配，则 SSH 握手成功，服务器将其公钥共享给客户端，SSH 会话建立。
进一步的客户机-服务器通信遵循标准的加密/解密工作流。 客户机用它的私钥加密数据，而服务器用客户机的公钥解密数据。 当响应客户机时，服务器用自己的私钥加密数据，客户机用服务器的公钥解密数据。
SSH 公钥身份验证也称为无密码身份验证，它经常用于自动化脚本中，其中在多个远程 SSH 连接上执行命令时不提示输入密码。
接下来让我们进一步了解基于用户和基于主机的公钥身份验证机制。
基于用户的认证是最常见的 SSH 公钥认证机制。 根据该模型，每个连接到远程 SSH 服务器的用户都有自己的 SSH 密钥。 同一主机(或域)上的多个用户帐户将有不同的 SSH 密钥，每个密钥都有自己对远程 SSH 服务器的访问，如下图所示:
图 7.29 -基于用户的密钥认证
基于用户的 SSH 密钥身份验证的一种类似方法是基于主机的身份验证机制，下面将介绍。
基于主机的身份验证是 SSH 公钥身份验证的另一种形式，涉及到连接到远程 SSH 服务器的每个系统(主机)的单个 SSH 密钥，如下图所示:
图 7.30 -基于主机的密钥认证
使用基于主机的身份验证，底层 SSH 密钥只能验证来自单个客户机主机的 SSH 会话。 基于主机的身份验证允许多个用户从同一主机连接到远程 SSH 服务器。 如果用户试图从不同的机器使用基于主机的 SSH 密钥，而不是 SSH 服务器所允许的机器，那么访问将被拒绝。
有时，混合使用两种公钥身份验证——基于用户和基于主机的身份验证——这种方法为 SSH 访问提供了更高的安全级别。
当安全性不是很重要时，更简单的 SSH 身份验证机制可能更合适。 密码身份验证就是这样一种机制。
密码验证需要来自 SSH 客户端的一组简单凭据，作为用户名和密码。 SSH 服务器根据本地用户帐户(在/etc/passwd中)或选择在 SSH 服务器配置(/etc/ssh/sshd_config中定义的用户帐户验证用户凭据。 在第 8 章，配置 Linux 服务器中介绍了 SSH 服务器的配置，进一步阐述了这个主题。
除了本地身份验证，SSH 还可以利用 Kerberos、LDAP、RADIUS 等远程身份验证方法。 在这种情况下，SSH 服务器将用户身份验证委托给远程身份验证服务器，如本章前面的身份验证服务器部分所述。
密码身份验证需要用户交互或某种自动方式来提供所需的凭据。 另一种类似的身份验证机制是键盘交互身份验证，将在下文中介绍。
键盘交互认证是基于 SSH 客户端(用户)和 SSH 服务器之间的多个挑战-响应序列的对话。 对话框是问题和答案的纯文本交换，其中服务器可以提示用户提出任意数量的挑战。 在某些方面，密码认证是一种单挑战交互式认证机制。
这种身份验证方法的交互性的内涵可以让我们认为用户交互对于相关实现来说是强制性的。 不是真的。 事实上，键盘交互身份验证还可以用于基于自定义协议的身份验证机制的实现，其中底层消息交换将被建模为身份验证协议。
在讨论其他远程访问协议之前，我们应该再次指出 SSH 由于其安全性、通用性和性能而得到了广泛的应用。 但是 SSH 连接在特定场景中可能并不总是可行或足够。 在这种情况下，TELNET可能会起到挽救作用。 下面我们来看一看。
TELNET是应用层协议，用于与远端主机使用明文 CLI 进行双向网络通信。 从历史上看，TELNET 是最早的远程连接协议之一，但它总是缺乏安全实现。 SSH 最终成为从一台计算机登录到另一台计算机的标准方式，但在排除各种应用层协议(如 web 或电子邮件服务器通信)的故障时，TELNET 比 SSH 有自己的优势。
让我们看一个示例来了解 TELNET 是如何工作的。 我们将使用 TELNET 模拟一个简单的 HTTP 请求/响应连接到 Apache web 服务器。 TELNET 的一般语法如下所示:
telnet HOST PORT在我们的例子中，Apache 运行在主机jupiter.local和端口80上，如下所示:
telnet jupiter.local 80我们得到以下响应:
图 7.31 -通过 TELNET 连接到远程 web 服务器
接下来，通过输入以下命令，我们启动一个遵循HTTP/1.1协议的 web 通信:
GET / HTTP/1.1HTTP/1.1协议需要一个强制性的HostHTTP 报头，所以我们继续下面的代码:
Host: localhost在前面的每一行之后，我们按下Enter(新行)，在Host标题之后按下Enter两次。 Apache web 服务器的响应如下:
图 7.32 -使用 TELNET 的 HTTP 请求/响应
为了简洁起见，我们截断了响应。 我们刚刚运行的 TELNET 会话显示了一个 web 客户端(我们的本地终端窗口)和一个远程 Apache web 服务器(jupiter.local)之间的交互式循序渐进的 HTTP 通信。
TELNET 和 SSH 是命令行驱动的远程接入接口。 有些情况下需要通过图形用户界面(GUI)与远程机器进行直接桌面连接。 下面我们来看看桌面共享。
Virtual Network Computing(VNC)是一个桌面共享平台，允许用户访问并控制远程计算机的 GUI。 VNC 是一个跨平台的客户机-服务器应用。 例如，在 Linux 机器上运行的 VNC 服务器允许桌面访问运行在 Windows 或 macOS 系统上的多个 VNC 客户机。 VNC 网络通信使用远程 Framebuffer(RFB)协议，由RFC 6143定义。
设置 VNC 服务器相对简单。 VNC 假设存在一个图形桌面系统。 你可以参考安装 Linux 图形用户界面在第一章,安装 Linux,设立一个 GNOME 或者【显示】K 桌面环境(KDE)在 Linux 桌面【病人】。 让我们以带有 GNOME 桌面的 RHEL/CentOS 8 系统为例，配置 VNC。 我们首先安装 VNC 服务器，如下所示:
sudo dnf install tigervnc-server tigervnc-server-module -y接下来，我们为当前用户创建一个 VNC 密码，像这样:
vncpasswdvncpasswd实用程序提示输入密码，并询问是否希望在view-only模式下使用 VNC。 我们选择完全控制访问。 下面是vncpasswd命令的输出:
图 7.33 -设置 VNC 密码
在接下来的步骤中，我们通过运行以下代码指定 GNOME 作为我们选择的 VNC 桌面:
printf 'gnome-session &\ngnome-terminal &' > ~/.vnc/xstartup~/.vnc/xstartup文件保存了当前的 VNC 配置。 或者，我们可以通过 VNC，在客户端和服务器之间启用剪贴板共享，并在~/.vnc/xstartup文件中添加以下一行:
vncconfig -iconic &以下是~/.vnc/xstartup文件的最终内容:
gnome-session &
gnome-terminal &
vncconfig -iconic &现在我们已经准备好启动 VNC 服务器，所以我们运行以下命令:
vncserver -geometry 1920x1080在vncserver命令中，我们为 VNC 会话指定了一个屏幕分辨率(1920x1080)。 该命令输出如下:
图 7.34 -启动 VNC 服务器
在vncserver命令的输出中，我们应该注意到 VNC 桌面 ID(jupiter:1)。 这个 ID 将用作 VNC 客户机主机名。 VNC 服务器的默认网络端口范围以5901开始。 多个 VNC 客户端连接增量端口。
使用 VNC 客户端应用，如VNC Viewer(通过RealVNC)在 Mac OS x 上，我们现在可以远程访问我们的 CentOS 8 Linux 机器，如下截图所示:
图 7.35 -使用 VNC 客户端
为了简单和空间考虑，我们描述了一种运行 VNC 的相对原始和直接的方法。 显然，我们可以更有创造性地控制 VNC 进程的生命周期。 本章的补充源代码展示了这样一个脚本。
这篇总结了我们关于网络服务和协议的部分。 我们试图涵盖关于通用网络服务器和应用的最常见概念，它们主要以客户机-服务器或分布式方式进行操作。 对于每个网络服务器，我们描述了相关的网络协议和涉及的一些内部方面。 第八章,配置 Linux 服务器、【显示】和第 9 章,保护 Linux【病人】,将展示实际的实现其中的一些网络服务器。
在下一节中，我们的重点转向网络安全的内部机制。
网络安全表示防止、监视和保护未经授权的访问计算机网络的过程、操作和策略。 网络安全范例跨越了大量的技术、工具和实践。 以下是一些重要的建议:
- 访问控制-基于用户认证和授权机制选择性地限制访问。 访问控制的示例包括用户、组和权限。 一些相关的概念已经在第四章、用户和组管理中介绍过。
- 应用安全-保护并保护服务器和终端用户应用(电子邮件、web 和移动应用)。 应用安全的例子包括安全增强 Linux(SELinux)、强加密连接、反病毒和反恶意软件程序。 我们将在第 9 章，Securing Linux中介绍SELinux。
- 端点安全-保护并保护网络上的服务器和终端用户设备(智能手机、笔记本电脑和台式机)。 端点安全的例子包括防火墙和各种入侵检测机制。 我们将在第 9 章，保护 Linux中查看防火墙。
- 网络分割-将计算机网络划分为更小的网段或虚拟局域网(vlan)。 这是，不要与子网混淆，子网是通过寻址对网络进行逻辑划分。
- vpn-通过安全加密隧道从公网或 internet 接入企业网络。 我们将在第 9 章，保护 Linux中讨论 vpn。
在日常的 Linux 管理中，设置网络安全边界应该始终遵循前面列举的范例，大致按照列出的顺序。 从访问控制机制开始，到 vpn 结束，保护网络采用从内到外的方法，从本地系统和网络到防火墙、vlan 和 vpn。 下一节将探讨 vpn。
*## VPNs
VPN 是一种网络技术，通过在公共互联网连接上创建一个私有网络，为用户提供在线安全性、私密性和匿名性。 vpn 一般用于以下场景:
- 在设备与私有网络或公司网络之间建立安全加密的连接
- 允许访问受地区限制的网站(防止地理封锁)
- 保护互联网活动不被窥探
vpn 本质上是在网络(通常是互联网)中创建一个数据隧道，远程安全地访问网络资源，绕过互联网审查，掩码 IP 地址，等等。
让我们来看看 vpn 是如何工作的。
VPN 基于客户端-服务器架构，通过 VPN 服务器路由客户端设备的网络通信。 VPN 服务器提供与客户端设备的加密通信隧道，充当客户端与 internet 或私有(或公司)网络之间的中介。 VPN 实现通常使用 OSI 第 2 层和第 3 层网络扩展与 SSL/TLS 协议。
商用或企业级 VPN 解决方案通常提供一个专用的 VPN 客户端应用，用户可以将其安装在自己的电脑和移动设备上。 VPN 客户端被配置为使用特定的 VPN 端点配置的应用。著名的商业 VPN 产品包括ExpressVPN、NordVPN,Surfshark,诺顿安全 VPN和【显示】IPVanish。
大多数操作系统都集成了对通用 VPN 的客户端支持。 在下面的章节中，我们将描述使用开放 VPN(一种开源 VPN 解决方案)的 VPN 环境的配置。
在这一节中，我们将引导你在 Ubuntu Server 20.04Long-Term Support(LTS)上设置 OpenVPN 的过程。 我们将为 VPN 端点使用一个虚拟专用服务器(VPS)，它具有公共网络接口。 主要原因 VPS 环境驻留在【病人】公共云(如亚马逊网络服务(AWS【t16.1】)/弹性计算云(EC2**),DigitalOcean, Linode,等等)的商品是通过互联网直接访问公共 IP 地址。 另外,我们可以使用任意主机在一个私有网络,与所需的网络地址转换(NAT)防火墙或路由器配置设置,让它从公共网络访问。******
****建立 VPN 的一种快速方法是使用一个开源实用程序来辅助 OpenVPN 配置，可以在https://git.io/vpn中找到。 下面的步骤将帮助您在几分钟内建立一个 VPN。 以下是我们将遵循的步骤:
- 标识用于 VPN 连接的网络接口
- 下载并运行 VPN 安装脚本
- 使用 Linux 客户端连接 VPN
让我们从第一步开始。
作为 VPN 服务器的典型的主机具有以下网络配置之一:
- 在 NAT/路由器/防火墙后面的私有静态 IP 地址，带有一个公网 IP 地址。 例如，AWS/EC2 实例或通用路由器背后的家庭网络计算机。
- 一个公网静态 IP 地址，可从 internet 路由。 这样的例子包括 DigitalOcean、Linode 和其他公司的 VPS 实例。
在我们的示例中，我们使用 DigitalOcean VPS 实例。 让我们看看系统上可用的网络接口，如下所示:
ip addr这是前一个命令的输出:
图 7.36 -识别网络接口
在我们的案例中，eth0接口有一个面向公共的 IP 地址138.68.19.158和一个对应的本地(内部)IP 地址10.46.0.5。 这些网络地址与我们使用 VPN 安装程序脚本配置 VPN 的下一步相关。
我们从开始，通过运行以下命令来确保系统是最新的:
sudo apt-get update
sudo apt-get upgrade接下来，我们下载并使用以下命令运行 VPN 安装脚本:
wget https://git.io/vpn -O vpnsetup && bash vpnsetup我们为安装程序脚本选择了vpnsetup这个任意名称。 该脚本提供了一步一步的指导帮助，如下面的截图所示:
图 7.37 -运行 VPN 安装程序
我们突出了的相关选择，如下:
138.68.19.158-我们专门为 VPN 连接提供的网络接口的 IP 地址UDP-推荐的 OpenVPN 协议1194- VPN 连接端口Current system resolvers—主机上的默认 DNS 子系统client- VPN 客户端实例的名称
成功运行 VPN 安装程序后，我们可以使用以下命令验证 OpenVPN 服务器的运行状态:
sudo systemctl status [email protected]我们应该得到以下active(running)状态:
图 7.38 -查询 OpenVPN 服务器状态
脚本还生成一个默认的 OpenVPN 客户端配置文件，该文件根据在 VPN 安装脚本的最后一步(即client)中选择的 VPN 客户端名称命名。 在本例中，文件为~/client.ovpn，如下所示:
cat ~/client.ovpn下面是其中的一段:
图 7.39 - OpenVPN 客户端配置文件(。 ovpn 文件)
OpenVPN 客户端配置文件与特定的 VPN 客户端共享，下面我们将看到。 通过多次运行 VPN 安装程序脚本，我们可以生成多个这样不同的客户端概要文件。 因为我们下载了 VPN 安装程序脚本，所以我们也可以在本地调用它。 我们需要使脚本可执行，首先通过运行以下命令:
chmod a+x ./vpnsetup
./vpnsetup后续的脚本运行为我们提供了以下选项:
图 7.40 - VPN 安装程序的后续调用
选择选项1)将生成一个新的客户端配置文件。 根据他们的描述，其他选择也很明显。 客户端配置文件仅与使用我们 VPN 的 OpenVPN 客户端共享。
接下来，让我们看看如何使用 OpenVPN 服务器配置 VPN 客户端。 所有主要的操作系统平台都支持 OpenVPN 客户端。 在下面的示例中，我们将展示运行在 Linux 和 Android 平台上的 OpenVPN 客户端。
本节中的说明将帮助您在 Ubuntu 和 CentOS 平台上配置 OpenVPN 客户端连接。 使用您选择的客户端平台，首先安装openvpn客户端包，如下所示:
-
在 Ubuntu 上执行以下命令:
sudo apt-get install -y openvpn
-
在 CentOS 操作系统上执行以下命令:
sudo yum install -y openvpn
接下来，我们将 OpenVPN 客户端配置文件(在配置 VPN部分中生成)复制到/etc/openvpn/client/client.conf。 我们假设client.ovpn概要文件已经复制到客户端机器(例如/home/packt/client.ovpn)，并运行以下代码:
sudo cp /home/packt/client.ovpn /etc/openvpn/client/client.conf此时，我们可以通过运行以下代码立即测试 VPN 客户端连通性:
sudo openvpn --client --config /etc/openvpn/client/client.conf下面是一个成功的 VPN 连接输出的摘录:
图 7.41 -测试 OpenVPN 客户端连通性
您可以从前面的进程中通过Ctrl+C退出。 为了在系统上启用 OpenVPN 客户端，我们启动相关的守护进程，如下所示:
sudo systemctl start openvpn-client@clientopenvpn-client守护进程的@client调用表示相关的 OpenVPN 客户端配置文件(在/etc/openvpn/client/client.conf中)。 如果配置文件的名称不一致，则需要对前面的命令进行相应的调整。
OpenVPN 客户端的状态应该显示为active，如下截图所示:
图 7.42 -查询 OpenVPN 客户端状态
成功建立 VPN 客户端连接后，您的客户端机器的公共 IP 地址应该匹配 VPN 服务器的公共 IP(138.68.19.158)。 你可以通过运行以下命令来检查:
dig TXT +short o-o.myaddr.l.google.com @ns1.google.com这是前一个命令的输出:
图 7.43 -检索客户端机器的公共 IP 地址
要停止 VPN 客户端连接，我们运行以下命令:
sudo systemctl stop openvpn-client@client我们还可以在各种其他操作系统平台上配置 OpenVPN 客户端。 接下来让我们看看移动平台。
首先，从 Android 应用商店安装OpenVPN Connect应用。 接下来，打开应用并导入 OpenVPN 客户端配置文件。 我们在前面生成了客户端概要文件，如配置 VPN部分所述。 你有两种选择导入配置文件,或者通过指定统一资源定位符(URL【显示】)文件(如谷歌驱动器直接联系,OneDrive 或 Dropbox)或者只是指向下载的文件,如果移动平台支持访问下载。
**这个过程如下图所示:
图 7.44 -使用 Android OpenVPN 客户端应用
导入 OpenVPN 客户端配置文件后，即可接入 VPN。 下面的插图说明了前面描述的步骤。 当连接到 VPN 时，我们的移动设备的公网 IP 地址成为138.68.19.158—VPN 服务器的 IP 地址。
有关 OpenVPN 项目的更多信息和相关产品下载，请访问https://openvpn.net/download-open-vpn/。
本章对基本的 Linux 网络原理进行了相对浓缩的介绍。 我们学习了网络通信层和协议、IP 地址方案、TCP/IP 配置、知名网络应用服务器和 VPN。 对网络范例的良好掌握将使 Linux 管理员更全面地了解分布式系统以及所涉及的应用端点之间的底层通信。
本章涉及的一些理论方面在第八章，配置 Linux 服务器中进行了实际的阐述，重点关注网络服务器的现实实现。 第 9 章，保护 Linux，将进一步探讨网络安全内部和实用的 Linux 防火墙。 到目前为止，我们所学的一切都将为接下来的章节奠定良好的基础。
这里有一个快速测试来概括和证明本章中涉及的一些基本概念:
- 如何 OSI 模型比较 TCP/IP 模型?
- 考虑两个 TCP/IP 协议，并尝试查看它们在您熟悉的一些网络管理任务或应用中的位置和如何操作。
- HTTP 协议在哪个网络层运行? DNS 怎么样?
- IP 地址
192.168.0.1的网络类是什么? - 网络掩码
255.255.0.0对应的网络前缀是什么? - 如何使用
nmcli实用程序配置静态 IP 地址? - 如何更改 Linux 机器的主机名?
- POP3 和 IMAP 电子邮件协议有什么区别?
- 基于主机的 SSH 认证和基于用户的 SSH 密钥认证有什么区别?
- SSH 和 TELNET 有什么区别?****************************************