• [技术干货] DNS污染检测方法 教你一招轻松验证DNS
    DNS污染,又称为域名服务器缓存污染(DNS cache pollution)或者域名服务器快照侵害(DNS cache poisoning)DNS污染,又称为域名服务器缓存污染(DNS cache pollution)或者域名服务器快照侵害(DNS cache poisoning)。DNS污染是指一些刻意制造或无意中制造出来的域名服务器分组,把域名指往不正确的IP地址。一般来说,网站在互联网上一般都有可信赖的域名服务器,但为减免网络上的交通,一般的域名都会把外间的域名服务器数据暂存起来,待下次有其他机器要求解析域名时,可以立即提供服务。一旦有相关网域的局域域名服务器的缓存受到污染,就会把网域内的电脑导引往错误的服务器或服务器的网址。某些网络运营商为了某些目的,对DNS进行了某些操作,导致使用ISP的正常上网设置无法通过域名取得正确的IP地址。某些国家或地区为出于某些目的防止某网站被访问,而且其又掌握部分国际DNS根目录服务器或镜像,也可以利用此方法进行屏蔽。这和某些运营商利用DNS劫持域名发些小广告不同,DNS污染则让域名直接无法访问了,非得修改DNS服务器不可。如果你想检测网络时候收到DNS的污染所影响,可以通过以下三个步骤:1、点“开始”-“运行”-输入CMD,再输入 ipconfig /all ,在下“DNS SERVER”(中文:DNS服务器)里找到你使用的DNS服务器地址。2、再输入 nslookup www.xxxxxxx.com(你的域名)+【空格】+【你的DNS服务器IP 】,来查看是否能解析。3、再输入 nslookup www.xxxxxxx.com 8.8.8.8 使用Google的DNS服务器验证。
  • [技术干货] 银河麒麟v10操作系统配置dns
    在银河麒麟桌面操作系统V10 SP1 中修改DNS信息,直接修改/etc/resolv.conf文件中的DNS信息,不能生效。应该参考如下步骤:一、首先修改 /etc/systemd/resolved.conf文件,在其中添加DNS信息在终端中执行以下命令:sudo vim /etc/systemd/resolved.conf/etc/systemd/resolved.conf文件大致内容如下:[Resolve]#DNS=#FallbackDNS=#Domains=#LLMNR=no#MulticastDNS=no#DNSSEC=allow-downgrade#DNSOverTLS=no#Cache=yes#DNSStubListener=yes#ReadEtcHosts=yes取消DNS项的注释并在其中添加DNS的信息,如下所示:[Resolve]DNS=114.114.114.114#FallbackDNS=#Domains=#LLMNR=no#MulticastDNS=no#DNSSEC=allow-downgrade#DNSOverTLS=no#Cache=yes#DNSStubListener=yes#ReadEtcHosts=yes然后保存并退出。二、重启服务,启用配置在终端中执行以下命令:sudo systemctl daemon-reloadsudo systemctl restart systemd-resolved然后再查看/etc/resolv.conf文件就可以看到新的DNS信息已经写入其中了。
  • [需求建议] error_msg":"Incorrect IAM authentication information:换新密码无法更新DNS
    修改了华为账号的密码 我把解析dns的脚本里的华为账号密码也更新了 更换新密码导致不能更新脚本报错经过测试发现用新的密码却不能更新 我把脚本里华为账号密码换回之前的旧的密码竟然还可以更新  为什么新改的密码不能用旧的反而可以  求大佬帮忙解决一下错误代码{"error_msg":"Incorrect IAM authentication information: x-auth-token not found","error_code":"APIGW.0301","request_id":"f4cbdcf0b940fa8b2584f634724b1a69"}./huaweicloud_ddns.sh: line 106: logger: command not found
  • [使用指南] 线上线下混合DNS配置流程
    **使用场景**线下IDC与云上VPC打通后,可能会有在线下IDC解析云上自定义的内网域名的需求,也有可能有在云上解析线下IDC的某些域名的需求。可以在云上VPC内用虚拟机做DNS代理,实现线上线下DNS互访(如果不需要云上解析线下IDC的某些域名,可以忽略云上解析xx域名转发给线下DNS的步骤)。**DNS配置流程**1. 登录线下IDC节点192.168.10.179服务器2. 执行yum install bind,安装bind作为线下DNS服务器3. 安装完成后,配置转发规则,线下解析不了的域名统一都转发到线上内网DNS解析。执行vim /etc/named.conf,配置如下图,(1) 增加监听IP,192.168.10.179(2) 增加默认forward配置,指向10.231.96.23(线下dns服务器没有的域名都forward到线上内网dns解析) !(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120057naiujdnxlgdycx3o.png)(3) 增加a.com zone的本地配置,zone文件路径为/opt/dns/zones/a.com.z !(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120114v8xqb5chacmjffmf.png)4. 如下图,执行vim /opt/dns/zones/a.com.z (线下DNS配置自己的域名a.com) !(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120127gbwvxkmrmvtldhvu.png)5. 登录线上VPC 服务器10.231.96.236. 执行yum install bind,安装完成bind配置dns服务7. 如下图,执行vim /etc/named.conf(1) 增加监听IP,10.231.96.23(2) 增加默认forward配置,指向内网DNS IP 100.125.1.25和100.125.1.250 !(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120139qdjrcrtlkoo3bw1l.png)(3) 增加zone forward配置,将a.com指向192.168.10.179,其他域名默认转发到内网DNS解析。 !(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120210sr2d7jmkzrsglh3i.png)8. 线上VPC服务器默认dns都设置成10.231.96.23,10.231.96.23作为中转节点,线下域名例如a.com会forward线下idc的DNS解析,其他域名会forward到内网DNS解析。到此可以实现线上内网DNS和线下IDC的DNS互相访问示意图,如下:!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202108/06/120233pp78qta7pmur1e2x.png)
  • [技术干货] k8s部署CoreDNS
    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地址解析没有问题。
  • [典型案例] DNS条件转发域名与原域名相同导致6009报错
    【关 键 词】:登录报错账户或密码错误,排查正常【问题现象】:局点无法远程,客户登录虚拟机时,提示6009报错,用户名或密码错误,在客户AD上修改了密码之后登录还是报错,VNC可以登录。出现报错后,重启虚拟机,可以概率性成功登陆。【问题分析】:1、查看日志,提示用户名或密码错误。2、查看FA上配置的主备AD,在主备AD上执行repadmin /showreps检查主备AD的同步状态,同步均正常。3、从VNC登陆进去之后,使用nslookup解析域名,发现域名对应有四个IP,而FA上只配置了两个IP。4、出排查指导文档,让一线按照指导检查,检查SRV记录正常,但发现客户的DNS记录里面,配置有条件转发,且转发的域名和该域的域名一致,导致用户登录鉴权时,概率性的被转发了,关闭该条件转发后,登录正常。
  • [典型案例] 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”
  • [典型案例] FA定时备份任务AD_DNS_DHCP组件备份失败,报错50073
    【故障类型】:局点版本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服务,再次手动执行备份成功。【总结&建议】:无
  • [实例分享] 使用WireShark完成网络协议(ARP、DNS、http)分析
    >随着网络入侵的不断发展,网络安全变得越来越重要,于是网络入侵取证系统的研究也变得日益重要。在网络入侵取证系统中,对网络上传送的数据包进行有效的监听即捕获包是目前取证的关键技术,只有进行高效的数据包捕获,网络管理员才能对所捕获的数据进行一系列的分析,从而进行可靠的网络安全管理。## 1.ARP协议验证分析>地址解析协议,即ARP(Address Resolution Protocol),是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机,并接收返回消息,以此确定目标的物理地址打开WireShark,并设置过滤器为arpARP请求报文、ARP响应报文:!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202105/28/205657d7zkxvohlpd6xjro.png)可以通过信息清楚的看到,请求: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!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202105/28/210146ppx1y02wsshpofmt.png)使用nslookup命令,使用指定的DNS服务器,进行DNS查询,语法如下:nslookup www.baidu.com 114.114.114.114打开WireShark,并设置过滤器为arp从捕获的DNS请求响应数据包中查看各层数据封装信息:DNS请求、响应数据包:!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202105/28/210231uwityphpfcnc3huo.png)## 3.HTTP协议验证分析>超文本传输协议(Hypertext Transfer Protocol,HTTP)是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应打开抓包软件,登录某网站(如教务网),验证用户名、密码明文传输。查找“POST”数据包,查看原始数据:!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202105/28/210415cwm5wskce7exktzh.png)!(https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202105/28/210419byzkfumz7dehijfj.png)**可以看到,由于该网站是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)
  • [Atlas500] 【智能小站】【DNS功能】容器运行一段时间后, dns失败,重启docker服务可恢复正常
    【功能模块】智能小站中, 多个容器,使用自定义的network。【操作步骤&问题现象】1、开始一段时间,工作正常,ping 其他容器名正常2、运行一定时间后,ping 其他容器名不通, ping ip能通3、重启docker服务, 恢复正常,一段时间后回到步骤1同样一套系统在ubuntu上运行正常【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [体验官] ubuntu 部署一个dns服务器
    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了。
  • [体验官] dockers遇到的坑
    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 已经跑起来了!
  • [应用开发] 通过Linux网卡转发配置MDC连接外网,无法ping通www.huawei.com
    问题背景:通过删除网关的方式,在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 种场景下的 3 种工具
    在开发、调试为生产环境下 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/
总条数:31 到第
上滑加载中