https://www.161616.top/tags/kubernetes-network/ Recent content in Kubernetes Network on Cylon's Collection Hugo -- 0.125.7 zh Sat, 22 Feb 2025 23:00:36 +0800 https://www.161616.top/deep-dive-k8s-network-cni/ Sun, 02 Feb 2025 00:00:00 +0000 https://www.161616.top/deep-dive-k8s-network-cni/ 本文是关于深入理解Kubernetes网络原理系列第3章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 概述 这是我在 kubernetes 网络之旅中的中的第4部分，主要学习 CNI 规范（5要素，旧版本是4要素）。要深深记住这些，在后面旅程中常常被用到。 Notes 本文讲解均按照 1. https://www.161616.top/calico-cni-deplyment/ Wed, 21 Jun 2023 00:00:00 +0000 https://www.161616.top/calico-cni-deplyment/ 开始前的实验环境 Resources controller worker-1 worker-2 OS CentOS 7.9 CentOS 7.9 CentOS 7.9 Storage 20GB 20GB 20GB vCPU 2 2 2 RAM 4GB 4GB 4GB NIC 10.0.0.4 10.0.0.4 10.0.0.4 Kubernetes Version 1.19.10 1.19.10 1.19.10 选择匹配 Kubernetes 版本的 Calico 版本 通常情况下，查看 Calico 所支持的 Kubernetes 版本，可以通过路径 Install Calico ==> Kubernetes ==> System requirements 可以找到自己的 Kubernetes 集群所支持的 Calico 版本。 例如在实验环境中，Kubernetes 1.19 版本所支持的版本有 Calico 3.20，这个时候直接 apply 这个版本提供的资源清单即可 如何开启纯 BGP 模式 默认情况下下，Calico 使用的是 full mesh 和 IPIP， 如果想通过在部署时就修改关闭 IPIP 模式，可以通过修改资源清单中的环境变量来关闭 CALICO_IPV4POOL_IPIP: Never。 https://www.161616.top/network-stack/ Fri, 28 Oct 2022 00:00:00 +0000 https://www.161616.top/network-stack/ Linux 架构概述 [1] 本章节简单阐述Linux系统的结构，并讨论子系统中的模块之间以及与其他子系统之间的关系。 Linux内核本身鼓励无用，是作为一个操作系统的一部分参与的，只有为一个整体时他才是一个有用的实体，下图展示了Linux操作系统的分层 图：Linux子系统分层图 Source：https://docs.huihoo.com/linux/kernel/a1/index.html 由图可以看出Linux操作系统由四部分组成： 用户应用 OS服务，操作系统的一部分（例如shell）内核编程接口等 内核 硬件控制器，CPU、内存硬件、硬盘和NIC等都数据这部分 Linux内核阐述 Linux内核将所有硬件抽象为一致的接口，为用户进程提供了一个虚拟接口，使用户无需知道计算机上安装了哪些物理硬件即可编写进程，并且Linux支持用户进程的多任务处理，每个进程都可以视作为操作系统的唯一进程独享硬件资源。内核负责维护多个用户进程，并协调其对硬件资源的访问，使得每个进程都可以公平的访问资源，并保证进程间安全。 Linux内核主要为五个子系统组成： 进程调度器(SCHED)， 控制进程对 CPU 的访问。调度程序执行策略，确保进程可以公平地访问 CPU。 内存管理器 (MM)， 允许多个进程安全地共享操作系统的内存 虚拟文件系统 (VFS)，向所有设备提供通用文件接口来抽象出各种硬件设备 网络接口 (NET)，提供对多种网络标准与各种网络硬件的访问 进程间通信 (IPC)，在单个操作系统上的多种机制进程间通信机制 网络子系统架构 [2] 网络子系统功能主要是允许 Linux 系统通过网络连接到其他系统。支持多种硬件设备，以及可以使用的多种网络协议。网络子系统抽象了这两个实现细节，以便用户进程和其他内核子系统可以访问网络，而不必知道使用什么物理设备或协议。 子系统模块包含 网络设备驱动层 (Network device drivers)，网络设备驱动程序与硬件设备通信。每个硬件设备都有对应的设备驱动程序模块。 独立设备接口层(device independent interface)，设备独立接口提供了所有硬件设备的统一视图，因此在网络子系统之上的级别无需了解硬件信息 网络协议层 (network protocol)，网络协议实现了网络传输的协议 协议独立/无关接口层 (protocol independent interface)，提供了独立于硬件设备的网络接口，为内核内其他子系统访问网络时不依赖特定的协议和硬件接口。 系统调用层 (system call) 用于限制用户进程导出资源的访问 网络子系统的结构图如下图所示， 图：网络子系统中的上下文 Source：https://docs.huihoo.com/linux/kernel/a1/index.html 当网络子系统转换为网络栈时，如下图所示 图：ISO Stack与TCP/IP Stack Source：https://www.washington.edu/R870/Networking.html 当然Linux网络子系统是类似于TCP/IP栈的一种结构，当发生一个网络传输时，数据包会按照所经过的层进行封装。例如应用层应用提供了REST API，那么应用将要传输的数据封装为HTTP协议，然后传递给向下的传输层。传输层是TCP协议就会被添加对应的TCP包头。整个封装过程原始包保持不变，会根据所经过层的不同增加固定格式的包头。 图：数据包传输在每层被封装的过程 Source：http://www.embeddedlinux.org.cn/linux_net/0596002556/understandlni-CHP-13-SECT-1.html 对于Linux来说TCP/IP 的五层结构则是构成网络子系统的的核心组件，下图是Linux网络栈结构图 图：Linux网络栈的结构图 Source：https://medium.com/geekculture/linux-networking-deep-dive-731848d791c0 图中橙色部分是位于TCP/IP的五层结构中的应用层，应用层向下通讯通过 system call 与 socket接口进行交互 蓝色部分是位于内核空间，socket向下则是传输层与网络层 最底层是物理层包含网卡驱动与NIC 通过图可以看出，NIC是发送与接收数据包的基本单位，当系统启动时内核通过驱动程序向操作系统注册网卡，当数据包到达网卡时，被放入队列中。内核通过硬中断，运行中断处理程序，为网络帧分配内核数据结构(sk_buff)，并将其拷贝到缓冲区中，此为内核与网卡交互的过程。 https://www.161616.top/network-unit-in-osi/ Fri, 28 Oct 2022 00:00:00 +0000 https://www.161616.top/network-unit-in-osi/ Overview [1] 协议数据单元 Protocol Data Unit (PDU) 是应用于OSI模型中的数据结构，在OSI模型中每一层都会被添加一个header，tailer进行封装，header, tailer加原始报文的组合就是PDU。 在每层中，PDU的名称都是不同的，这也是很多人的疑问，一会数据报文称为数据包，一会数据报文成为数据帧，该文介绍网络中的单元，以了解之间的区别 物理层 物理层数据的呈现方式是以 “位” (bit) 为单位的，即0 1，在该层中数据以二进制形式进行传输 数据链路层 [2] 到达数据链路层，实际上可以说进入了TCP/IP栈对底层，而该层的单位为 ”帧“ (frame)，该层中，MAC地址会被封装到数据包中，比如以太网帧，PPP帧都是指该层的数据包 该层中数据帧包含： 源MAC 目的MAC 数据，由网络层给出的 数据的总长度 校验序列 网络层 [3] 在网络层中协议数据单元被称为数据 “包" (package) ，是网络间节点通讯的基本单位。该层中IP地址会被封装到数据包内。 该层中数据包包含： 标头：源IP，目的IP，协议，数据包编号，帮助数据包匹配网络的位 payload：数据包的主体 标尾：包含几个位，用于告知已到达数据包的末尾与错误检查（循环冗余检查 (CRC)） 图：数据包组成 Source：https://computer.howstuffworks.com/question525.htm 例如一个电子邮件，假设电子邮件大小尾3500bit，发送时使用1024的固定大小数据包进行发送，那么每个数据包标头为 96bits，标尾为 32bit，剩余 896bits 将用于实际的数据大小。这里为3500bits，会被分为4个数据包，前三个数据包为 896bits，最后一个数据包大小为 812bits。接收端会根据包编号进行解包重组 传输层 Segment 在传输层TCP协议的协议数据单元被称为 ”段“ (Segment) ，上面讲到，IP数据包会以固定大小的数据包进行发送，如果超出大小的会被划分为多个数据包，每个数据包的碎片就被称之为Segment。 数据包分割通常会发生在该层，当发生下列场景时会需要分段 数据包大于网络支持的最大传输单元 (MTU) 网络不可靠，将数据包分为更小的包 datagram [4] 在传输层UDP协议的协议数据单元被称为 ”数据报“ (datagram) ，datagram是一种逐层增加的设计，用于无连接通讯 下图是一个UDP数据报被封装位一个IP数据包：IPv4字段值位17 表示udp协议 图：udp的IP包 Source：https://notes.shichao.io/tcpv1/ch10 对于udp数据报的组成包含header与payload，udp的header大小为固定的8字节 源端口：可选 目的端口：识别接收信息的进程 Length：udp header + udp payload的长度，最小值为8 checksum：与lenght一样其实是多余的，因为第三层包含了这两个信息 图：udp数据报组成 Source：https://notes. https://www.161616.top/pod-network-troubleshooting/ Wed, 17 Aug 2022 00:00:00 +0000 https://www.161616.top/pod-network-troubleshooting/ 本文是关于深入理解Kubernetes网络原理系列第4章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将引入一个思路：“在Kubernetes集群发生网络异常时如何排查”。文章将引入Kubernetes 集群中网络排查的思路，包含网络异常模型，常用工具，并且提出一些案例以供学习。 Pod常见网络异常分类 网络排查工具 Pod网络异常排查思路及流程模型 CNI网络异常排查步骤 案例学习 Pod网络异常 网络异常大概分为如下几类： https://www.161616.top/kubernetes-network-model-part1/ Wed, 17 Aug 2022 00:00:00 +0000 https://www.161616.top/kubernetes-network-model-part1/ 本文是关于深入理解Kubernetes网络原理系列第4章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 概述 本文将简述探讨 Kubernetes 中常见的网络模型，以及对这些网络模型的 route path 进行分析。本章节是作为CNI 原理的前置条件，也为后续的练习提供一些基础知识。 https://www.161616.top/calico-network-policy/ Mon, 15 Feb 2021 00:00:00 +0000 https://www.161616.top/calico-network-policy/ 什么是网络策略 在Kubernetes平台中，要实现零信任网络的安全架构，Calico与istio是在Kubernetes集群中构建零信任网络必不可少的组件。 而建立和维护整个集群中的“零信任网络”中，网络策略的功能在操作上大致可以总结为使用资源配置模板来管理控制平面数据流。说白了讲网络策略就是用来控制Pod间流量的规则。 在Calico中如何编写网络策略 要使用网络策略就需要先了解Calico功能**：NetworkPolicy和GlobalNetworkPolicy**。 NetworkPolicy资源，简称np；是命名空间级别资源。规则应用于与标签选择器匹配的endpoint的集合。 GlobalNetworkPolicy资源，简称 gnp/gnps与NetworkPolicy功能一样，是整个集群级别的资源。 GlobalNetworkPolicy 与 NetworkPolicy资源的管理也与calico的部署方式有关，使用etcd作为存储时，资源的管理只能使用 calicoctl进行管理 NetworkPolicy与GlobalNetworkPolicy的构成 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: allow-tcp-90 spec: selector: app == 'envoy' # 应用此策略的endpoint types: # 应用策略的流量方向 - Ingress - Egress ingress: # 入口的流量规则 - action: Allow # 流量的行为 protocol: ICMP # 流量的协议 notProtocol: TCP # 匹配流量协议不为 值 的流量 source: # 流量的来源 src与dst的匹配关系为 与，所有的都生效即生效 nets: # 有效的来源IP selector: # 标签选择器 namespaceSelector: # 名称空间选择器 ports: # 端口 - 80 # 单独端口 - 6040:6050 # 端口范围 destination: # 流量的目标 egress: # 出口的流量规则 - action: Allow serviceAccountSelector: # 使用与此规则的serviceAccount NetworkPolicy使用 实例：允许6379流量可以被 role=frontend的pod访问 https://www.161616.top/calico-deploy-on-hybrid-cloud/ Mon, 15 Feb 2021 00:00:00 +0000 https://www.161616.top/calico-deploy-on-hybrid-cloud/ 开始前准备 确定calico数据存储 Calico同时支持kubernetes api和etcd数据存储。官方给出的建议是在本地部署中使用K8S API，仅支持Kubernetes模式。而官方给出的etcd则是混合部署（Calico作为Kubernetes和OpenStack的网络插件运行）的最佳数据存储。 使用etcd作为calico数据存储的好处： 允许多平台混用calico，如Kubernetes OpenStack上运行Calico Kubernetes资源与Calico资源分离 一个Calico群集，该群集不仅仅包含一个Kubernetes群集，如可与多个kubernetes集群互通。 坏处： 安装步骤繁琐 无法使用Kubernetes RBAC对calico资源的控制 无法使用Kubernetes资源对calico进行管理 下载calico部署清单 text 1 curl https://docs.projectcalico.org/manifests/calico-etcd.yaml -o calico.yaml 修改Pod CIDR Calico默认的Pod CIDR使用的是192.168.0.0/16，这里一般使用与controller-manager中的--cluster-cidr 保持一,取消资源清单内的 CALICO_IPV4POOL_CIDR变量的注释，并将其设置为与所选Pod CIDR相同的值。 calico的IP分配范围 Calico IPAM从ipPool分配IP地址。修改Pod的默认IP范围则修改清单calico.yaml中的CALICO_IPV4POOL_CIDR 配置Calico的 IP in IP 默认情况下，Calico中的IPIP已经禁用，这里使用的v3.17.2 低版本默认会使用IPIP 要开启IPIP mode则需要修改配置清单内的 CALICO_IPV4POOL_IPIP 环境变量改为 always 修改secret yaml 1 2 3 4 5 6 7 8 9 10 11 # Populate the following with etcd TLS configuration if desired, but leave blank if # not using TLS for etcd. https://www.161616.top/calico-network-cni/ Mon, 18 Jan 2021 00:00:00 +0000 https://www.161616.top/calico-network-cni/ Calico针对容器、虚拟机的开源网络和网络安全解决方案。是纯三层的数据中心网络方案。 Calico在每一个计算节点利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播。（小规模部署可以直接互联 BGP full mesh，大规模下可通过指定的BGP route reflector来完成）。 这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。 Calico还基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。 calico组件 在Kubernetes平台之上calico/node容器会通过DaemonSet部署到每个节点，并运行三个守护程序： Felix：用于管理路由规则，负责状态上报。 BIRD：BGP的客户端，用于将Felix的路由信息加载到内核中，同时负责路由信息在集群中的分发。 confd：用于监视Calico存储（etcd）中的配置变更并更新BIRD的配置文件。 calicoctl使用问题 text 1 Failed to create Calico API client: invalid configuration: no configuration has been provided 默认情况下，calicoctl 将使用位于的默认KUBECONFIG从 Kubernetes APIServer 读取$(HOME)/.kube/config 。 如果默认的 KUBECONFIG 不存在，或者想从指定的存储访问信息，则需要单独配置。 bash 1 2 3 export DATASTORE_TYPE=kubernetes export DATASTORE_TYPE=etcdv3 export KUBECONFIG=~/.kube/config reference for calico 安装配置 开始前准备 确定calico数据存储 Calico同时支持kubernetes api和etcd数据存储。官方给出的建议是在本地部署中使用K8S API，仅支持Kubernetes模式。而官方给出的etcd则是混合部署（Calico作为Kubernetes和OpenStack的网络插件运行）的最佳数据存储。 使用kubernetes api作为数据存储的安装 text 1 2 curl https://docs.projectcalico.org/manifests/calico.yaml -O kubectl apply -f calico. https://www.161616.top/virtual-networking/ Mon, 18 Jan 2021 00:00:00 +0000 https://www.161616.top/virtual-networking/ 本文是关于深入理解Kubernetes网络原理系列第2章 深入理解Kubernetes Pod网络原理 - 网络名称空间 深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术 深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理 深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将介绍Kubernetes中使用的相关虚拟网络功能，目的是为了任何无相关网络背景经历的人都可以了解这些技术在kubernetes中式如何应用的。 VLAN VLAN (Virtual local area networks)是逻辑上的LAN而不受限于同一物理网络交换机上。同样的VLAN也可以将同一台交换机/网桥下的设备/划分为不同的子网。 https://www.161616.top/ensp-calico-bgp/ Mon, 18 Jan 2021 00:00:00 +0000 https://www.161616.top/ensp-calico-bgp/ 实验文件： [calico BGP.zip](https://cdn.jsdelivr.net/gh/cylonchau/blogs@img/img/calico BGP.zip) R1 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 system-view sysname R1 interface l0 ip address 1.1.1.1 32 interface g0/0/0 ip address 10.1.0.1 24 interface g0/0/1 ip address 10.3.0.1 24 bgp 100 router-id 1.1.1.1 peer 10.1.0.2 as-number 123 peer 10.3.0.2 as-number 456 dis this dis ip interface b R2 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 system-view sysname R2 interface l0 ip address 2. https://www.161616.top/network-tunnel-technology/ Mon, 18 Jan 2021 00:00:00 +0000 https://www.161616.top/network-tunnel-technology/ 隧道技术概要 隧道技术（Tunneling）是网络基础设置在网络之间传递数据的方式，使用隧道技术传递可以是不同协议的数据包，隧道协议将这些其他协议的数据包重新封装在新的包头中发送。被封装的数据包在隧道的两个端点之间通过网络进行路由，被封装数据包在网络上传递时所经历的逻辑路径称为隧道。 简单来说，隧道技术是一类网络协议，是将一个数据包封装在另一个数据包中进行传输的技术；**使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。**通过网络隧道技术，可以使隧道两端的网络组成一个更大的内部网络。（把不支持的协议数据包打包成支持的协议数据包之后进行传输）。 隧道协议 要创建隧道，隧道的客户机和服务器双方必须使用相同的隧道技术，隧道协议有二层隧道协议与三层隧道协议两类。 二层隧道协议对应OSI模型中数据链路层，使用 帧 作为数据交换单位，PPTP、L2TP、L2F都属于二层隧道协议。是将数据封装在点对点协议的帧中通过互联网络发送。 三层隧道协议对应OSI模型中网络层，使用 包 作为数据交换单位，GRE、IPSec 都属于三层隧道协议。都是数据包封装在附加的IP包头中通过IP网络传送。 在例如VxLAN，工作在传输层和网络层之间。具体来说，将运行在用户数据报协议 (UDP) 和网络数据报协议 (IP) 之间，以便在网络中建立安全的通信通道。 网络隧道技术应用 隧道在Linux 中应用 IP隧道是指一种可在两网络间进行通信的通道。在该通道里，会先封装其他网络协议的数据包，之后再传输信息。 Linux原生共支持5种IPIP隧道： ipip: 普通的IPIP隧道，就是在报文的基础上再封装成一个IPv4报文 gre: 通用路由封装（Generic Routing Encapsulation），定义了在任意一种网络层协议上封装其他任意一种网络层协议的机制，所以对于IPv4和IPv6都适用 sit: sit模式主要用于IPv4报文封装IPv6报文，即IPv6 over IPv4 isatap: 站内自动隧道寻址协议（Intra-Site Automatic Tunnel Addressing Protocol），类似于sit也是用于IPv6的隧道封装 vti: 即虚拟隧道接口（Virtual Tunnel Interface），是一种IPsec隧道技术 像IPVS/LVS中的 Virtual Server via IP Tunneling，就是使用了IPIP隧道 SSH隧道技术 SSH提供了一个重要功能，称为转发 forwarding 或者称为隧道传输tunneling，它可以通过加密频道将明文流量导入隧道中，在创建SSH隧道时， SSH客户端要设置并转交一个特定本地端口号到远程机器上；一旦SSH隧道创建，用户可以连到指定的本地端口号以访问网络服务。本地端口号不用与远地端口号一样。 SSH隧道主要使用场景一般为 规避防火墙、加密网络流量 规避防火墙，SSH隧道可以使一个被防火墙阻挡的协议可被包在另一个没被防火墙阻挡的协议里，这技巧可用来逃避防火墙政策。而这种操作符合“数据包封装在另一个数据包中进行传输的技术”，故称为SSH隧道技术。 SSH隧道类型 在ssh连接的基础上，指定 ssh client 或 ssh server 的某个端口作为源地址，所有发至该端口的数据包都会透过ssh连接被转发出去；至于转发的目标地址，目标地址既可以指定，也可以不指定，如果指定了目标地址，称为定向转发，如果不指定目标地址则称为动态转发： 定向转发 定向转发把数据包转发到指定的目标地址。目标地址不限定是ssh client 或 ssh server，既可以是二者之一，也可以是二者以外的其他机器。