CoreDNS用于集群内部Service名称解析。coreDNS服务监视kubernetes api , 为每一个service创建dns记录,用于域名解析;这样访问pod资源时只需要访问service名即可，而不需要关心pod容器的ip地址的变化。[root@master ~]# cat coredns.yamlapiVersion: v1kind: ServiceAccountmetadata:  name: coredns  namespace: kube-system  labels:      kubernetes.io/cluster-service: "true"      addonmanager.kubernetes.io/mode: Reconcile---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: Reconcile  name: system:corednsrules:- apiGroups:  - ""  resources:  - endpoints  - services  - pods  - namespaces  verbs:  - list  - watch---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  annotations:    rbac.authorization.kubernetes.io/autoupdate: "true"  labels:    kubernetes.io/bootstrapping: rbac-defaults    addonmanager.kubernetes.io/mode: EnsureExists  name: system:corednsroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: system:corednssubjects:- kind: ServiceAccount  name: coredns  namespace: kube-system---apiVersion: v1kind: ConfigMapmetadata:  name: coredns  namespace: kube-system  labels:      addonmanager.kubernetes.io/mode: EnsureExistsdata:  Corefile: |    .:53 {        errors        health        kubernetes cluster.local in-addr.arpa ip6.arpa {            pods insecure            upstream            fallthrough in-addr.arpa ip6.arpa        }        prometheus :9153        proxy . /etc/resolv.conf        cache 30        loop        reload        loadbalance    }---apiVersion: apps/v1kind: Deploymentmetadata:  name: coredns  namespace: kube-system  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    addonmanager.kubernetes.io/mode: Reconcile    kubernetes.io/name: "CoreDNS"spec:  # replicas: not specified here:  # 1. In order to make Addon Manager do not reconcile this replicas parameter.  # 2. Default is 1.  # 3. Will be tuned in real time if DNS horizontal auto-scaling is turned on.  strategy:    type: RollingUpdate    rollingUpdate:      maxUnavailable: 1  selector:    matchLabels:      k8s-app: kube-dns  template:    metadata:      labels:        k8s-app: kube-dns      annotations:        seccomp.security.alpha.kubernetes.io/pod: 'docker/default'    spec:      serviceAccountName: coredns      tolerations:        - key: node-role.kubernetes.io/master          effect: NoSchedule        - key: "CriticalAddonsOnly"          operator: "Exists"      containers:      - name: coredns        image: lizhenliang/coredns:1.2.2        imagePullPolicy: IfNotPresent        resources:          limits:            memory: 170Mi          requests:            cpu: 100m            memory: 70Mi        args: [ "-conf", "/etc/coredns/Corefile" ]        volumeMounts:        - name: config-volume          mountPath: /etc/coredns          readOnly: true        ports:        - containerPort: 53          name: dns          protocol: UDP        - containerPort: 53          name: dns-tcp          protocol: TCP        - containerPort: 9153          name: metrics          protocol: TCP        livenessProbe:          httpGet:            path: /health            port: 8080            scheme: HTTP          initialDelaySeconds: 60          timeoutSeconds: 5          successThreshold: 1          failureThreshold: 5        securityContext:          allowPrivilegeEscalation: false          capabilities:            add:            - NET_BIND_SERVICE            drop:            - all          readOnlyRootFilesystem: true      dnsPolicy: Default      volumes:        - name: config-volume          configMap:            name: coredns            items:            - key: Corefile              path: Corefile---apiVersion: v1kind: Servicemetadata:  name: kube-dns  namespace: kube-system  annotations:    prometheus.io/port: "9153"    prometheus.io/scrape: "true"  labels:    k8s-app: kube-dns    kubernetes.io/cluster-service: "true"    addonmanager.kubernetes.io/mode: Reconcile    kubernetes.io/name: "CoreDNS"spec:  selector:    k8s-app: kube-dns  clusterIP: 10.0.0.2   ports:  - name: dns    port: 53    protocol: UDP  - name: dns-tcp    port: 53    protocol: TCP[root@master ~]# [root@master ~]# kubectl apply -f coredns.yamlserviceaccount/coredns createdclusterrole.rbac.authorization.k8s.io/system:coredns createdclusterrolebinding.rbac.authorization.k8s.io/system:coredns createdconfigmap/coredns createddeployment.apps/coredns createdservice/kube-dns created查看生成的pod:kubectl get pods -n kube-system NAME                          READY   STATUS    RESTARTS   AGEcoredns-5ffbfd976d-j6shb      1/1     Running   0          32sDNS解析测试：kubectl run -it --rm dns-test --image=busybox:1.28.4 shIf you don't see a command prompt, try pressing enter./ # nslookup kubernetesServer:10.0.0.2Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.localName:kubernetesAddress 1: 10.0.0.1 kubernetes.default.svc.cluster.local地址解析没有问题。

【关 键 词】：登录报错账户或密码错误，排查正常【问题现象】：局点无法远程，客户登录虚拟机时，提示6009报错，用户名或密码错误，在客户AD上修改了密码之后登录还是报错，VNC可以登录。出现报错后，重启虚拟机，可以概率性成功登陆。【问题分析】：1、查看日志，提示用户名或密码错误。2、查看FA上配置的主备AD，在主备AD上执行repadmin /showreps检查主备AD的同步状态，同步均正常。3、从VNC登陆进去之后，使用nslookup解析域名，发现域名对应有四个IP，而FA上只配置了两个IP。4、出排查指导文档，让一线按照指导检查，检查SRV记录正常，但发现客户的DNS记录里面，配置有条件转发，且转发的域名和该域的域名一致，导致用户登录鉴权时，概率性的被转发了，关闭该条件转发后，登录正常。

【故障类型】：DNS解析概率性失败【关 键 词】： AD【适用版本】：所有AD、DNS版本【问题现象】：客户搭建环境时在备AD的管理网卡中勾选了管理网卡的“在DNS中注册此连接的地址（R）”，然后去掉勾选，并删除DNS中对应记录，但是告警还会是不是的出现【告警信息】：虚拟机随机性脱域【问题分析】：检查ITA到AD的网络及端口，正常检查主备DNS中的记录，同时删除多余的记录，主备AD同步正常检查主备DNS的网卡配置，配置正常使用ipconfig /renew更新本地的DNS记录，过段时间还会出现删除” C:\Windows\System32\dns\CACHE.DNS”的DNS缓存【解决方法】：删除DNS的缓存文件” C:\Windows\System32\dns\CACHE.DNS”【总结&建议】：删除DNS的缓存文件” C:\Windows\System32\dns\CACHE.DNS”

【故障类型】：局点版本Access 6.5.0，FA上每天凌晨1点的定时备份任务，AD、DNS、DHCP备份到BackupServer失败，报错“50073请检查该备份组件与FTP连接状态是否正常”，其他Linux组件备份正常。经检查失败组件在本地D盘已经备份，上传失败，修改backupserver里的require_ssl_reuse=no并重启vsftpd服务后备份正常。【关 键 词】：WI配置失败，50073【适用版本】：FusionAccess6.5.0【问题现象】：AD_DNS_DHCP组件本地备份正常，上传到BackupServer失败，报错“50073请检查该备份组件与FTP连接状态是否正常”，其他Linux组件备份正常。【告警信息】：AD、DNS、DHCP备份失败【问题分析】：1、检查备份失败的组件，本地有备份文件，说明本地备份脚本执行成功。2、检查AD上的monitor日志，已经收到备份任务请求，但备份时报错“522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page”。3、vsftpd.conf配置文件里，require_ssl_reuse默认是YES，表明数据与控制流使用相同的ssl通道，当数据流和控制流各是一个ssl通道时需要改成no。【解决方法】：1、修改BackupServer里vsftpd的配置文件 /etc/vsftpd/vsftpd.conf，添加一行 require_ssl_reuse=NO2、重启vsftpd服务，再次手动执行备份成功。【总结&建议】：无

>随着网络入侵的不断发展，网络安全变得越来越重要，于是网络入侵取证系统的研究也变得日益重要。在网络入侵取证系统中，对网络上传送的数据包进行有效的监听即捕获包是目前取证的关键技术，只有进行高效的数据包捕获，网络管理员才能对所捕获的数据进行一系列的分析，从而进行可靠的网络安全管理。 ## 1.ARP协议验证分析 >地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址 打开WireShark，并设置过滤器为arp ARP请求报文、ARP响应报文：  可以通过信息清楚的看到， 请求：who has 192.168.1.101 tell 192.168.1.1 返回了该ip的物理地址。 ## 2.DNS协议验证分析 >域名系统（Domain Name System，缩写：DNS）是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。 使用nslookup命令，使用默认的DNS服务器，进行DNS查询，语法如下(查询百度的ip地址)： nslookup www.baidu.com  使用nslookup命令，使用指定的DNS服务器，进行DNS查询，语法如下： nslookup www.baidu.com 114.114.114.114 打开WireShark，并设置过滤器为arp 从捕获的DNS请求响应数据包中查看各层数据封装信息： DNS请求、响应数据包：  ## 3.HTTP协议验证分析 >超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应 打开抓包软件，登录某网站（如教务网），验证用户名、密码明文传输。 查找“POST”数据包，查看原始数据：   **可以看到，由于该网站是http而不是https，因此用户名和密码都被解析出来了！！**

对于网络管理员来说，熟悉与掌握路由排错的思路和技巧是非常必要的。面试中经常会问到此问题DNS服务概述：DNS（Domain Name System）域名系统，在TCP/IP 网络中有非常重要的地位，能够提供域名与IP地址的解析服务。DNS 是一个分布式数据库，命名系统采用层次的逻辑结构，如同一棵倒置的树，这个逻辑的树形结构称为域名空间，由于DNS 划分了域名空间，所以各机构可以使用自己的域名空间创建DNS信息。DNS 相关概念（1）DNS 服务器运行DNS 服务器程序的计算机，储存DNS 数据库信息。DNS 服务器会尝试解析客户机的查询请求。在解答查询时，如果DNS 服务器能提供所请求的信息，就直接回应解析结果，如果该DNS 服务器没有相应的域名信息，则为客户机提供另一个能帮助解析查询的服务器地址，如果以上两种方法均失败，则回应客户机没有所请求的信息或请求的信息不存在。（2）DNS 缓存DNS 服务器在解析客户机请求时，如果本地没有该DNS 信息，则可以会询问其他DNS 服务器，当其他域名服务器返回查询结果时，该DNS 服务器会将结果记录在本地的缓存中，成为DNS 缓存。当下一次客户机提交相同请求时，DNS 服务器能够直接使用缓存中的DNS 信息进行解析。AD的全称是Active Directory：活动目录域（Domain）:1)域是Windows网络中独立运行的单位，域之间相互访问则需要建立信任关系(即Trust Relation)。信任关系是连接在域与域之间的桥梁。当一个域与其他域建立了信任关系后2)两个域之间不但可以按需要相互进行管理，还可以跨网分配文件和打印机等设备资源，使不同的域之间实现网络资源的共享与管理，以及相互通信和数据传输域控制器（DC）：域控制器就是一台服务器，负责每一台联入网络的电脑和用户的验证工作。组织单元（OU）用户名服务器名（CN）

【功能模块】智能小站中， 多个容器，使用自定义的network。【操作步骤&问题现象】1、开始一段时间，工作正常，ping 其他容器名正常2、运行一定时间后，ping 其他容器名不通， ping ip能通3、重启docker服务， 恢复正常，一段时间后回到步骤1同样一套系统在ubuntu上运行正常【截图信息】【日志信息】（可选，上传日志内容或者附件）

apt-get updateapt-get install bind9之后可以设置/etc/bind/named.conf.local 本地网络域，这里不用略过；root@ecs-385f:~# vi /etc/bind/named.conf.options options {        directory "/var/cache/bind";        // If there is a firewall between you and nameservers you want        // to talk to, you may need to fix the firewall to allow multiple        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113        // If your ISP provided one or more IP addresses for stable        // nameservers, you probably want to use them as forwarders.        // Uncomment the following block, and insert the addresses replacing        // the all-0's placeholder.         forwarders {              8.8.8.8;         };        //这里修改为8.8.8.8,开放dns转到外网       //========================================================================        // If BIND logs error messages about the root key being expired,        // you will need to update your keys.  See https://www.isc.org/bind-keys        //========================================================================        dnssec-validation auto;        auth-nxdomain no;    # conform to RFC1035        listen-on-v6 { any; };};重启进程，使配置生效。/etc/init.d/bind9 restart测试使用笔记本，设置dns为ECS的EIP，发现开始排障：在服务器上测试root@ecs-385f:/etc/bind# dig @127.0.0.1 www.sina.com; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @127.0.0.1 www.sina.com; (1 server found);; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9334;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 13, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: f43778f78a9331bb40b5f28960866d501ce9b34d41877cdc (good);; QUESTION SECTION:;www.sina.com.                  IN      A;; ANSWER SECTION:www.sina.com.           2       IN      CNAME   spool.grid.sinaedge.com.spool.grid.sinaedge.com. 59     IN      A       123.126.55.41spool.grid.sinaedge.com. 59     IN      A       123.125.104.150;; AUTHORITY SECTION:.                       85716   IN      NS      m.root-servers.net..                       85716   IN      NS      g.root-servers.net..                       85716   IN      NS      e.root-servers.net..                       85716   IN      NS      f.root-servers.net..                       85716   IN      NS      c.root-servers.net..                       85716   IN      NS      i.root-servers.net..                       85716   IN      NS      b.root-servers.net..                       85716   IN      NS      k.root-servers.net..                       85716   IN      NS      d.root-servers.net..                       85716   IN      NS      l.root-servers.net..                       85716   IN      NS      a.root-servers.net..                       85716   IN      NS      h.root-servers.net..                       85716   IN      NS      j.root-servers.net.;; Query time: 367 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Mon Apr 26 15:35:44 CST 2021;; MSG SIZE  rcvd: 346说明本地服务是可用的。接下来就是要在服务器上抓包，来分析dns的请求是否已经发送到了ecs上。抓包没有问题。/etc/bind/named.conf.options中尝试添加allow-query {0.0.0.0/0;}; 放通所有的请求源地址。再次测试，OK了。

docker search mysql//查找可用的mysql版本docker pull mysql:latest//拉取镜像报错：error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/cb/cbe8815cbea8fb86ce7d3169a82d05301e7dfe1a8d4228941f23f4f115a887f2/data?verify=1618847250-lzNSpT8IswXJGeHRU1I00Xcbgr4%3D: dial tcp: lookup production.cloudflare.docker.com on 127.0.0.53:53: no such host这个是因为dns域名解析的时候，因为没有配置resolv.conf，默认为127.0.0.53，而本地环境并没有配置DNS服务，自然就出不去的了。修改/etc/resovl.conf中的nameserver 8.8.8.8之后不用重启动："resolv.conf" 8L, 363C written                                                                                                             root@ecs-385f:/etc#  docker pull mysql:latestlatest: Pulling from library/mysqlf7ec5a41d630: Pull complete 9444bb562699: Pull complete 6a4207b96940: Pull complete 181cefd361ce: Pull complete 8a2090759d8a: Pull complete 15f235e0d7ee: Pull complete d870539cd9db: Pull complete 5726073179b6: Pull complete eadfac8b2520: Downloading [====>                                              ]  11.27MB/113.1MBf5936a8c3f2b: Download complete cca8ee89e625: Download complete 6c79df02586a: Download complete 已经跑起来了！

问题背景：通过删除网关的方式，在ubuntu16.04PC机上上实现wifi上外网与有线网连接MDC300的网口(不是MTB的网口)同时进行,可通过ssh远程连接mdc，如下图所示外网配置方案选择快速入门指南中的Linux网卡转发方案已完成步骤：在PC机的Linux中配置端口转发在Linux系统中设置SNAT转发配置MDC300的DNS服务器其中DNS服务器的ip地址配置为PC机所连接wifi的DNS服务器ip地址将MDC的默认路由配置为PC机连接内网的ip地址如图，将Gateway配置为192.1698.1.1115验证MDC是否连上外网尝试ping同设置的DNS服务器或者8.8.8.8，发现无法ping通请问遇到这种情况应该怎么解决，上述配置过程是否有操作错误？

在开发、调试为生产环境下 K8s service 中的应用程序时，常常需要一些工具或者命令。本文介绍了三种不同场景下对应的解决方案以及工具。以下解释了场景的基本设置：我们有 3 个 service，service-front 通过入**露给外网。service-front 的后端服务是 service-middle，service-middle 的后端是 service-back。通信是通过 K8s service 完成的。以下是安装该设置的必要命令：kubectl create ns service-debugkubectl -n service-debug run service-back --image=erkanerol/service-back:v1 --port=8080 --expose=true --labels="app=back "kubectl -n service-debug run service-middle --image=erkanerol/service-middle:v1 --port=8081 --expose=true --labels="app=middle"kubectl -n service-debug run service-front --image=erkanerol/ service-front:v1 --port=8082 --expose=true --labels="app=front"这是这些服务的源代码：https : //github.com/erkanerol/service-examples-for-blog工具1：kubectl port-forward场景：作为开发人员，我希望 service-back 可以直接发送一些请求，并在不影响其他 service 的情况下查看结果。问题：service-back 不会暴露在外网，所以我们不能直接向其发送请求。解决方案：使用 kubectl port-forward，可以打开从本地计算机到 service-back 集群中的隧道。可参考：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#port-forward步骤：在终端中运行以下命令：$ kubectl -n service-debug port-forward service/service-back 8080:8080Forwarding from 127.0.0.1:8080 -> 8080Forwarding from [::1]:8080 -> 8080然后在另一个终端中运行以下 curl 命令，以查看是否可以访问 service-back：$ curl localhost:8080Timestamp from back:1614508193实现原理：kubectl 启动一个监听在 localhost:8080 的进程。它监控该端口并建立与 api-server 的连接，该连接将请求转发到 service-back。工具2：kubefwd场景：作为开发人员，我希望在本地计算机上运行 service-front，以便在 IDE 中设置断点来调试应用程序。问题：service-front 被设计为，在 Kubernetes 中运行并可以通过 K8s service 访问 service-middle。service 名称是硬编码的，或者很难配置的，又或者我们懒得在本地计算机上模拟依赖项。解决方案：kubefwd是解决该问题的有用工具。它可以执行批量端口转发并管理本地计算机中的 DNS 记录。可参考：https://github.com/txn2/kubefwd步骤：在终端中运行以下命令:$ sudo KUBECONFIG=$KUBECONFIG kubefwd svc -n service-debug -l app=middle请注意，kubefwd 需要 root 特权，并且必须使用 sudo 运行。事先设置 KUBECONFIG 变量，不需要任何主文件夹引用。在另一个终端中，在本地计算机上运行 front 应用程序。注意，我们也可以在调试模式下运行它并设置断点。$ cd /tmp$ git clone https://github.com/erkanerol/service-examples-for-blog.git $ cd service-examples-for-blog/front$ go run main.go再在另一个终端中，向 front 应用发送请求，以查看 front 应用在本地提供服务，并且可以在集群中访问 service-middle。$ curl localhost:8082Response from service middle:'Response from service back:'Timestamp from back:1614513901''实现原理：从 kubefwd 的日志中可以看到：...INFO[14:07:38] 'cat /etc/hosts' to see all host entries.INFO[14:07:38] Loaded hosts file /etc/hostsINFO[14:07:38] HostFile management: Original hosts backup already exists at /root/hosts.original...INFO[14:07:38] Port-Forward: 127.1.27.1 service-middle:8081 to pod service-middle:8081...它启动一个进程，监听在 127.1.27.1:8081，并配置了 service-middle 的 /etc/hosts：$ cat /etc/hosts |grep service-middle127.1.27.1       service-middle.default service-middle.default.svc service-middle.default.svc.cluster.local service-middle.default.minikube service-middle.default.svc.minikube service-middle.default.svc.cluster.minikube service-middle service-middle.service-debug service-middle.service-debug.svc service-middle.service-debug.svc.cluster.local service-middle.service-debug.minikube service-middle.service-debug.svc.minikube service-middle.service-debug.svc.cluster.minikube然后，本地 front应用程序可以像访问 K8s 集群一样访问 service-middle，而无需其他额外的工作。工具3：telepresence场景：作为开发人员，我希望在本地计算机上运行 service-middle，以便可以在 IDE 中设置断点来调试应用程序。问题：service-middle设计为可在 Kubernetes 中运行，可通过 K8s service 访问 service-back。另外，它的 service-front 正在 K8s 上运行。这些 service 在本地计算机上不可用，而且我们也很难在本地计算机上模拟这些环境。解决方案：telepresence 是解决此问题的有用工具。可参考：https://www.telepresence.io/步骤：首先从 K8s 集群中删除 service-middle。我们在本地运行：kubectl -n service-debug delete service service-middle --ignore-not-found=truekubectl -n service-debug delete pod service-middle --ignore-not-found=true为 service-middle 运行 telepresence：telepresence --namespace service-debug --new-deployment service-middle --expose 8081在另一个终端中，在本地计算机上运行 middle 应用程序。注意，我们也可以在调试模式下运行并设置断点。$ cd /tmp$ git clone https://github.com/erkanerol/service-examples-for-blog.git $ cd service-examples-for-blog/middle$ go run main.go再在另一个终端中，运行以下命令以通过集群中的临时 Pod 发送请求至 service-front ：$ kubectl -n service-debug run curl -it  --rm=true --image=curlimages/curl --restart=Never -- http://service-front:8082 Response from service middle:'Response from service back:'Timestamp from back:1614517363''pod "curl" deleted要注意，这里的请求将转到 K8s 中的 service-front，K8s 将请求发送到本地计算机中的 service-middle，本地计算机再将请求发送到集群中的 service-back。实现原理：实际上，telepresence 将 proxy、fake agent 部署到集群中，并通过该代理在本地环境和集群之间打开一条双向通道。这样一来，我们便可以在本地计算机上运行 middle service，而无需调整 consumers、dependent service。telepresence 工作原理的详细说明，详见：https://www.telepresence.io/discussion/how-it-works小结如果我们需要在不暴露 service 的情况下访问 service，kubectl port-forward就足够了。如果我们需要在本地运行 service 进行调试，并且 service 需要访问 K8s 上的其他 service ，kubefwd 可以发挥作用。它管理着本地计算机中的 DNS 记录，并为 service 依赖性打开从计算机到集群的单向通道。如果我们需要在本地运行 service 进行调试，并且应用程序在集群中有一些使用方，那就使用telepresence。它可以打开双向网络通道，并将请求从集群转发至本地实例。文章来源：K8sMeetup社区翻译：Bach原文链接：https://erkanerol.github.io/post/debugging-k8s-services/

问题：重启网卡service network restart 重启服务后，/etc/resolv.conf中配置的内容后丢失。导致无法上网域名解析不了解决办法：在 /etc/sysconfig/network-scripts/ifcfg-eth<N> 文件中加入 PEERDNS 选项和配置DNS(如下)PEERDNS=no     #这个选项可令 /etc/resolv.conf 在系统重启后不会被重写。DNS1=114.114.114.114DNS2=8.8.8.8验证：再次service network restart 后 /etc/resolv.conf中的内容不改变

磨刀不误砍柴工，在使用CDN之前，我们先来了解下与CDN相关的基本概念吧！加速域名加速域名就是您需要使用CDN加速的域名，即终端用户访问的域名。域名是便于记忆和沟通的一组服务器的地址，可以是网站，电子邮件，FTP等。Q：加速域名可以和源站域名一样吗？A：不可以，用户访问加速域名时，如果CDN节点上没有缓存对应的内容，CDN节点会回到源站获取，然后再返回给用户。如果源站域名与加速域名一致，访问请求会反复转发到CDN节点，导致CDN节点无法回源拉取请求内容，访问失败。Q：什么样的域名可以作为加速域名？A:   加速范围包含中国大陆的加速域名都需要在工信部备案，接入CDN加速的域名还需要通过内容审核，了解需要审核哪些内容请戳这里。源站源站指您的业务服务器，即被加速分发数据的来源。源站类型可以是源站域名、源站IP、OBS桶域名。Q：我的业务服务器不在国内，可以使用CDN加速吗？A：CDN加速跟您的源站服务器位置无关，无论你的服务器在中国大陆境内或者境外，都可以使用CDN加速。加速范围加速范围决定了哪些地区的用户可以使用CDN加速，华为云CDN有三种加速范围可供选择：中国大陆、中国大陆境外、全球。Q：加速域名只开通了中国大陆加速，会影响中国大陆境外用户访问域名吗？A：开通CDN后，不会影响未加速地区的访问。例如：您的源站在中国大陆，且您开通的CDN加速服务范围也在中国大陆。当中国大陆用户访问您的加速域名时会就近访问到中国大陆节点上。当中国大陆境外用户访问您的加速域名时，因您未开通中国大陆境外加速服务，中国大陆境外用户也会访问到中国大陆节点上，受跨境网络影响，加速效果不太明显，甚至无法访问。敲黑板！加速范围与源站的位置无关，无论你的源站哪里，都是可以灵活选择加速范围的！DNSDNS（Domain Name System），即域名解析服务，作用是把域名翻译成IP地址。在TCP/IP网络中域名与IP地址一一对应，域名便于记忆，但网络中的服务器间只能通过IP地址相互识别，域名和IP地址之间的转换称为域名解析，域名解析需要通过专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。有了DNS服务，用户只通过域名就可以访问对应的服务器，获取想要的内容。例如：您访问xxx.abc.com会通过DNS转换成220.xxx.xxx.xxx（资源所在服务器的IP地址）。CNAME记录CNAME记录是指域名解析中的别名记录（Canonical Name），允许将多个域名映射到同一个域名。例如：您有一台服务器存放了一些文件，可以通过file.example.com访问该资源，但是希望通过另一个域名data.example.com也能访问。那么您可以在DNS解析服务商处新增一条CNAME记录，将data.example.com指向file.example.com。添加CNAME记录后，所有访问data.example.com的请求就会指向file.example.com，获得相同内容。CNAME域名您在CDN管理控制台添加加速域名后，系统会为加速域名分配一个对应的“CNAME域名”（域名形式为：*.c.cdnhwc1.com）。您需要在域名服务商处，配置一条CNAME记录，将加速域名指向这个“CNAME域名”，记录生效后，域名解析的工作就正式转向CDN服务，该域名所有的请求都将转向CDN节点，达到加速效果。Tips：如何为CDN加速域名添加CNAME记录？请单击这里。边缘节点边缘节点也称CDN节点、Cache节点等，指距离最终用户接入具有较少的中间环节的网络节点，提高终端用户访问的响应能力和连接速度。边缘节点的作用就是缓存用户访问的内容。Q：华为云CDN有多少节点？A：华为云CDN在中国大陆境内有2000+加速节点，覆盖所有省份、自治区、直辖市，在中国大陆境外有500+加速节点，节点分布图请戳这里。回源CDN节点未缓存资源或者缓存资源已到期时，节点会回源站获取资源，返回给客户端。例如：终端用户访问某个加速域名，如果CDN节点未缓存用户访问的资源，CDN会向源站发出请求，得到该资源后返回给用户并缓存到节点。回源HOST在CDN侧配置源站的目的是为了在回源时得到源站的IP地址，而回源HOST是为了确定回源时需要访问到该IP地址的哪个站点。例1：源站为域名时，源站为www.xxx.com，回源HOST为www.abc.com，实际回源的是www.xxx.com解析到的IP站点www.abc.com。例2：源站为IP地址时，源站为1.1.1.1，回源HOST为www.abc.com，实际回源的是1.1.1.1对应主机上的站点www.abc.com。SSL/TLSSSL（Secure Sockets Layer，安全通讯协议），是一个构架于TCP之上的安全套接层，是为网络通信提供安全及数据完整性的一种安全协议。标准化之后的SSL名称为TLS（Transport Layer Security，传输层安全协议）。URL参数根据业务需要判断是否启用该项配置，对用户请求URL中“?”之后的参数进行过滤。不启用：每一个URL请求都会缓存一份文件在CDN，不同的URL对应不同的缓存。启用：只缓存一份文件在CDN节点，后续每个请求都默认命中缓存，返回同一份文件。示例：终端用户首次访问URL“http://www.example.com/1.txt”时，CDN无缓存，回源拉取资源，第二次访问“http://www.example.com/1.txt?test1”时：如果开通了“URL参数”功能，不匹配“?”之后的参数，直接命中缓存，返回“http://www.example.com/1.txt”对应的内容；如果没有开通“URL参数”功能，需要匹配“?”之后的参数，要重新回源拉取“http://www.example.com/1.txt?test1”对应的资源，返回给用户并缓存到CDN节点。Q：什么情况下可以开通URL参数呢？A：如果您的URL中“？”之后的参数代表相同的内容，可以开通此功能，提高缓存命中率。      如果您的URL中“？”之后的参数代表不相同的内容，例如：一个设计的不同版本，建议不要开启此功能。   

近日准备在中标麒麟测试一下兼容软件，发现网络连接正常但是不能上网，呐......初步怀疑是DNS的问题，但是却不知道该如何设置，百度的结果也不尽如人意，成年人的世界，只想要简简单单，接下来我会教你如何设置，超简单的，go~~1、首先鼠标点击右下角网络连接，选择“编辑连接”2、双击当前连接的以太网3、选择“IPv4设置”页签,填写“附加DNS服务器”IP,如114.114.114.114（不知道DNS是多少可以直接问环境负责人，他一定会告诉你的）4、保存。重新刷新网页就可以正常访问网页啦~

上文讲述了王牌排错的基础，接下来将详细讲解网络排错的步骤；3 网络排错详细步骤为了更好的讲述网络排错的过程和思路，假设我们有下面的一个网络环境：（说明：虽然是假设，但实际上该网络环境是通过GNS3联动虚拟机和真实网络架设起来的，所以是可以真实参考的）下面，我们就以上面这个网络环境为例子，详细介绍我们的网络排错思路，每一步要怎么做，每一步为什么要这样做以及这样做之后我们可以得到什么信息，都会做一个说明。3.1 检查物理链路是否有问题这一步是我个人认为在做网络排错时必须要做的第一步！经常会听朋友说，领导的电脑上不了网，需要过去排错，搞了老半天，还发现不了问题，最后在几经绝望之时，竟然发现网线都没接上电脑。这就真的是悲剧了，浪费了很多时间不说，这样的网络排错思路本来就是有错误的。因为也许不是每个人都可以去机房查看交换机的接线情况，所以这一步，我们排查的重点范围就应该放在如下面图所示的地方：在这一步，下面几点是需要注意排查的：1. 确认电脑本身的网卡有没有问题2.确认接的网线有没有问题3.本机所连接的交换机（如果可以去机房查看的话）如果上面这几点排查都没有问题了，那么就是该网络环境中的其他设备问题了。这一范围的排查相对比较简单，因为只涉及到物理链路的连接问题。对于这种测试，可以考虑使用测线器，但个人的建议是，拿一台配置正确的笔记本来做测试也未尝不可。3.2 查看本机IP地址、路由、DNS的设置是否有问题上面第一步，物理链路的排查没有问题了，也就是说，电脑接上网线之后，电脑有反应了，可以识别，但是网络还是不通，来到这一步，就应该先把注意的范围放在电脑的设置上面了。这一步，我们关注的重点是：1.IP地址设置如果采用的是DHCP自动获取的方法，那么这时候只需要看自己本机的设置上有没有开启自动获取IP的设置以及有没有开启相关的服务；如果用的是静态IP，那么就必须要注意IP地址的填写有没有错（一般网络管理人员给的）、IP地址的子网掩码有没有问题（这很重要，对于静态IP，很多人在这里设置错误，建议是，最好把IP地址、VLSM这方面的知识学一下）。一般可以用下面的命令查看：2.路由设置对于服务器、PC，一般是指默认网关的设置了；对于路由器本身或三层交换机，那就是静态路由或动态路由的设置问题了。3.DNS设置主要是要确保所设置的DNS服务器地址到底有没有提供域名解析服务或者是否出现了故障，至于如何判断，后面会给出方法，这里关注的是，你得设置一个正确的DNS服务器地址或可以自动获取。在windows上面你可以通过下面的命令查看：3.3 测试网关或路由器的通畅情况。先测网关然后再测路由器，一级一级地测试在上面的网络环境中，在网络通的情况下，我们在电脑上使用命令tracert -d命令，会得到下面的结果：通过这个测试结果，我们可以清楚地知道电脑在访问互联网时，数据的走向情况：根据这个数据走向，我们就可以得到一个重要的思路，就是根据数据走向来检测网络的通畅情况！因此，我们可以分两步：1.先测试电脑到网关192.168.2.254的通畅情况我们可以在自己的电脑上自己ping网关的地址，看是否有响应一般这样的判断方法是比较快的，但有时候，无论怎样ping都不能，那么则可能有以下的几种情况：a.网关设备做了禁止ping的设置b.网关接口或网关设备出现故障对于a，一般很少会在这些设备在做ping的限制操作，实在是没有太大的必要这样做，当然，网络安全等要求十分严格的除外。ping通192.168.2.254网关后，再ping一下172.16.13.1以确认电脑到整个网关设备都没有问题。对于ping不通的时候，我个人还建议在电脑上执行如下操作：即查看电脑本身有没有获取到网关的MAC的地址，显然，如果没有网关的MAC地址，那也是不可能ping通网关的，在排除了前面电脑设置的问题后，你可以猜测是网关设备出了问题，这时就可以联系网络工程师对网关设备进行测试了。2.测试到其它路由器的通畅情况前面一步没有问题了，也就是电脑到网关通信正常了，再测试网关到出口路由器的通畅情况：这里，我们使用tracert -d命令就可以了：当然，如果发现不通，那么则可能是下面的情况：a.网关设备与路由器之间的物理链路问题b.网关设备与路由器之间的设置问题，比如路由协议、接口配置之类的出现上面的情况，那就是网络工程师的问题了，当然，如果你是网络工程师，应该要马上查看一下设备的状态，看是不是设备哪里出现问题了。上面的步骤完成了，假设你的出口路由器设置是没有问题的，比如NAT与默认路由等的设置，那么我们大致可以知道，内网的一个基本通信是正常的（至少你的电脑和出口路由器的通信没问题），我们就要看看电脑到底能不能访问互联网了。3.4 测试ping公网ip的通畅情况（平时要记几个外部IP）来到这一步的时候，就说明前面三步是没有问题的，也就是说，本地局域网络的通信是正常的，这时要做的就是判断本地局域网络与外网（公网）之间的通信有没有问题了：这里采取的是直接ping公网地址的方法，是为了排除DNS的影响（万一你的DNS设置又有问题），至于要ping什么样的公网地址，个人建议是，可以ping一些没有禁止ping的公共DNS服务器地址，比如114.114.114.114和8.8.8.8的：这样之后，基本上就可以确定网络是没有问题的了。当然，这里并没有提到出口放置防火墙的情况，实际上，思路是一致的，但是，你需要考虑的是，你的访问数据有没有被防火墙给过滤掉，是数据出去的时候过滤了，还是数据回来的时候过滤了？由于还要涉及到防火墙的设置，这里就不再提及了，只是仍要注意这一点就是了。3.5 测试DNS的通畅情况，可以直接ping网站地址如题，可以直接ping网站地址，看有没有回显IP地址，至于通不通是另外一回事，只要可以回显IP地址，那么DNS就没有问题了，不过这里仍然要说一下nslookup这个命令，这是一个非常好用的命令，我平常自己在网络排错时，基本上都会用到：使用nslookup命令，作用有二：1.帮你测试你设置的DNS服务器有没有问题2.在不考虑DNS服务器是否智能的前提下，你可以根据回显IP地址速度的快慢来大致判断DNS服务器的优劣情况所以可以充分利用nslookup命令了。