iptables

开篇 Istio 流量劫持的文章其实目前可以在servicemesher社区找到一篇非常详细的文章，可查阅： Istio 中的 Sidecar 注入及透明流量劫持过程详解 。特别是博主整理的那张“流量劫持示意图”，已经可以很清晰的看出来劫持流程。这里我借着那张图片解释一版该图片的文字版本。在开始文字版前如果对 iptables 命令如果不是非常了解的话建议先重点看下下面的两篇文章，深入浅出的解释了该命令的概念及用法： iptables概念 - 以通俗易懂的方式描述iptables的相关概念 iptables指南 - iptables命令用法指南 这里引用iptables的一张报文流向图(版权归原博主所有) 当客户端访问服务器的web服务时，客户端发送报文到网卡，而tcp/ip协议栈是属于内核的一部分，所以，客户端的信息会通过内核的TCP协议传输到用户空间中的web服务中，而此时，客户端报文的目标终点为web服务所监听的套接字（IP：Port）上，当web服务需要响应客户端请求时，web服务发出的响应报文的目标终点则为客户端，这个时候，web服务所监听的IP与端口反而变成了原点。 -- 引用自 zsythink 上面这部分描述相当重要，它是理解sidecar在进行流量劫持的基础之一。 下面我们分析下昨天 istio-init 启动时执行的 istio-iptables 命令

wsl默认为内部网络，外部无法访问，通过配置nat转发可以直接访问docker的内部网络，无需其他复杂的配置。 首先需要知道wsl2的内部ip地址和docker内部的网络地址。例如我的网络是这样的系统Ubuntu wsl2的ip地址 inet 192.168.119.0/20 brd 192.168.127.255 scope global eth0 docker内部的ip地址 inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 进入Ubuntu # 允许路由转发 sudo iptables -P FORWARD ACCEPT 以管理员身份运行cmd #启用路由转发服务 任务管理器->服务->打开服务 -> Routing and Remote Access 或者执行下面的命令 sc start RemoteAccess # 添加路由表 route add -P 172.17.0.0 mask 255.255.0.0 192.168.119.0 # ping docker内部网关就可以ping通了 ping 172.17.0.1 然后就可以直接在windows下ping wsl2中docker的内部网络了 方便调试 来源： oschina 链接： https://my.oschina.net/microxdd

写于2013/12/08 万恶的心跳！只是证明自己还活着... 为何不能到有事情来的时候再做，没事情时就休息呢？何必一直保持心跳呢？ 上帝按照自己的形象，造出了人，人按照自己的喜好，造出了计算机，计算机也都有心跳。操作系统靠时钟中断这种心跳来推进机器的时间，然而后来Linux实现了NOHZ，即没有事情的时候，不再无谓地触发时钟中断，而是彻底halt，有事请来的时候，其它的中断会将机器唤醒，继续心跳。这种nohz机制节省了资源，最小化了bug触发率。 IPSec UOM完全是按需连接的，隧道模式下，如果数据包过来，匹配到了加密策略，那么就看加密隧道有没有建立，如果还没有建立，则触发IKE协商，如果已经建立了，则直接通过隧道传输数据，当然IPSec也可以使用万恶的心跳... 心跳保持的UOM长连接有几个问题，第一，如果收不到心跳，隧道就要被迫断开一次，这种断开事件会被审计为一次异常事件，因为按照正常看来，既然要保持长连接，那它就不应该断开，现在断开了，那是不应该的。第二，对于那种带宽属于稀缺资源的环境，心跳报文会占用可观的资源，比如3G用户，在没有实际数据传输的情况下，发送的心跳报文将是完全的浪费。 UOM为何要保持长连接呢？难道随用随连不好吗？隧道的长连接难道仅仅为了展示自己是一个基础设施吗？对于网到网拓扑来讲，这可能是真实的，但是对于终端用户而言，长连接基础设施反而意味着压力

https://archive.org/ 可以查看几年前已经下线的网站，主要是通过网站的cache. CPU-Z 中的SPD选项可以方便的查看内存参数。 solarwinds network topology mapper 14天试用 自动发现网络中的设备并自动画出网络结构图 jv16 PowerTools 用于注册表优化 DriverView 可以用来隐藏microsoft drivers，剩下的就是别的可疑的drivers http://tcpmonitor.altervista.org 的security autorun 查看启动程序 chntpw http://www.chntpw.com/download/ 下载 破解修改windows 10登陆密码 BinText 文件文本扫描工具, 扫描文本中的特殊字符 UPX 它被用来给***和病毒加壳，躲避杀毒软件的查杀。 ollydbg 一款Windows平台下的32/64位调试器,是一款反汇编工作的常用工具软件 IDA (Interactive Disassembler Professional) 交互式反汇编器专业版 www.virustotal.com Free Online Virus, Malware and URL Scanner ProxySwitcherStandard 可以从网上自动下载代理列表

iptables与firewalld防火墙 一、网卡的配置方法： 1、编辑网卡配置文件：vim /etc/sysconfig/network-scripts/ifcfg-网卡名称，ONBOOT=yes必须设置为yes，表示网卡设为开启状态，IPADDR0 =IP 地址，编辑完成后保存退出，使用systemctl restart network命令重启网络服务生效。 2、使用nmtui命令，按提示进行操作，保存后也重启网络服务生效。 3、使用nm-connection-editor命令，编辑完成，保存后也重启网络服务生效。 二、iptables、firewall配置 1、iptables在RHEL7.2版本前默认使用的是iptables防火墙管理服务来配置防火墙，大多数企业在生产环境中依然使用iptables。 2、firewall-cmd命令行管理工具，参数一般都是以长格式来提供 ，可使用TAB键补齐参数。 3、firewall-config图形化配置工具。 4、TCP_wraperse服务访问控制列表是RHEL7系统中默认启用的一款流量监控程序，它能够根据来访主机的地址与本机的目标服务程序作出允许或拒绝的操作。 来源： oschina 链接： https://my.oschina.net/hskycn/blog/4292171

原文： https://www.cnblogs.com/higkoo/articles/iptables_tunning_for_conntrack.html “连接跟踪表已满，开始丢包”！相信不少用iptables的同学都会见过这个 错误信息 吧，这个问题曾经也困扰过我好长一段时间。此问题的解决办法有四种（nf_conntrack 在CentOS 5 / kernel <= 2.6.19中名为 ip_conntrack ）： 一、关闭防火墙。 简单粗暴，直接有效 chkconfig iptables off chkconfig ip6tables off service iptables stop service ip6tables stop 切记：在防火墙关闭状态下，不要通过iptables指令（比如 iptables -nL）来查看当前状态！因为这样会导致防火墙被启动，而且规则为空。虽然不会有任何拦截效果，但所有连接状态都会被记录，浪费资源且影响性能并可能导致防火墙主动丢包！ 二、加大防火墙跟踪表的大小，优化对应的系统参数 1、状态跟踪表的最大行数的设定，理论最大值 CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32) 以64G的64位操作系统为例，CONNTRACK_MAX = 64*1024*1024*1024

前言 网上关于kubernetes网络部署的方案非常多，那为什么还要自己写这么一篇教程呢？因为这篇文章中将介绍一种较为少见的部署方式，使用kuberouter作为kubernetes系统网络组件，直接替换掉kubeproxy、flannel/calico等网络组件。使用这种部署方式的目的，是替换kube-proxy，减少iptables依赖，同时还能提供网络服务。 <!--more--> 替代分析 Kube-router替代kube-proxy kube-proxy的作用主要是用于监听API server中 service 和 endpoint的变化情况，并通过iptables等来为服务配置负载均衡（仅支持TCP和UDP）。kube-proxy 可以直接运行在物理机上，也可以以 static pod 或者 daemonset 的方式运行。 Kube-proxy主要有以下技术特点： 底层默认使用iptables进行流量的转发 通过监听api server服务中的对象变化，实现service发现功能。 而kuberouter采用了基于相同技术但增加了更多负载均衡策略的IPVS来实现流量转发，服务发现的实现与kube-proxy一致。因此可以直接替代kube-proxy。 Kube-router代替flannel/Calico等网络组件 kubernetes 对网络的要求是：容器之间

node节点flannel网络问题导致该node上的pod与其他node节点网络不通的排查思路与解决方法 一、问题发现 在部署一个replicas：4的nginx deployment之后在master节点通过curl + podIP + 端口的形式测试时，发现两次访问不到，两次可以访问得到。 二、问题排查 1、通过ping pod的ip地址，发现node1节点的pod全都ping不通，问题很有可能就出在node1节点上 2、通过ip a查看node1节点发现flannel.1没有ip地址，可能原因就出现在这。 3、刚开始以为是iptables规则可能导致节点flannel网络没起来，于是就把iptables规则全清了，重启了kubelet后发现还是没有flannel网络。 4、然后在master节点通过kubectl logs -f -n kube-system kube-flannel的Pod来查看对应node1的flannel Pod的日志发现一个错误日志，还是网络down掉了 failed to add vxlanRoute (10.244.0.0/24 -> 10.244.0.0): network is down 5、尝试将node1节点的flannel.1网络删除，在node1节点上执行 ip link delete flannel.1 6、在 /etc/sysctl