现在 iptables 这个工具的应用似乎是越来越广了。不仅仅是在传统的防火墙、NAT 等功能出现，在今天流行的的 Docker、Kubernets、Istio 项目中也经常能见着对它的身影。正因为如此，所以深入理解 iptables 工作原理是非常有价值的事情。
在数据的发送过程中，从上至下依次是“加头”的过程，每到达一层数据就被会加上该层的头部；与此同时，接受数据方就是个“剥头”的过程，从网卡收上包来之后，在往协议栈的上层传递过程中依次剥去每层的头部，最终到达用户那儿的就是裸数据了。
Linux内核网络 UDP 协议层通过调用 ip_send_skb 将 skb 交给 IP 协议层，本文通过分析内核 IP 协议层的关键函数来分享内核数据包发送在 IP 协议层的处理，并分享了监控IP层的方法。
在《Netfilter & iptables 原理》一文中，我们介绍了 Netfilter 和 iptables 的原理，而本文主要通过源码分析来介绍一下 Netfilter 与 iptables 的实现过程。
转载链接1：http://www.arrowapex.cn/archives/66.html
Below is an example which does exactly what you need: hook received TCP packets and print their payloads. If you want to print some other information from received packet (like binary data), you just need to modify a bit the section under this comment:
在网络包的发送和接收过程中，绝大部分的工作都是在内核态完成的。那么问题来了，我们常用的运行在用户态的程序 tcpdump 是那如何实现抓到内核态的包的呢？有的同学知道 tcpdump 是基于 libpcap 的，那么 libpcap 的工作原理又是啥样的呢。如果让你裸写一个抓包程序，你有没有思路？
Netfilter （配合 iptables）使得用户空间应用程序可以注册内核网络栈在处理数据包时应用的处理规则，实现高效的网络转发和过滤。很多常见的主机防火墙程序以及 Kubernetes 的 Service 转发都是通过 iptables 来实现的。
本文介绍连接跟踪（connection tracking，conntrack，CT）的原理，应用，及其在 Linux 内核中的实现。
本文作者 / yogazhao 爱自然科学，赞叹于大师级码农高超的艺术境界；爱生命科学，诚服于古圣先贤的天地气象。 可能大多数瓜农都对《艺伎回忆录》比较熟悉，作为一个IT界的码农，当然也有自己类似的经历，该文分为上篇和下篇，此篇为《OVS BUG撸码回忆录•上篇》 回忆录缘起 以前为排查ovs的某个bug，无奈撸了把相关内核流程。当时因为调用链太多，脑袋栈溢出，处理不过来，所以临时用txt比较零散的记录了下关键点，做完了就丢了。后面想起来，无奈用everything找了好久才找到， 再读之，发现忘了很
关于 netfilter 的介绍文章大部分只描述了抽象的概念，实际上其内核代码的基本实现不算复杂，本文主要参考 Linux 内核 2.6 版本代码（早期版本较为简单），与最新的 5.x 版本在实现上可能有较大差异，但基本设计变化不大，不影响理解其原理。
信息安全课程——窃取密码 一、 一、 安装ubantu16-64 Desktop版本 通过XShell连接虚拟机。 sudo apt install openssh-server sudo apt-get install vim #安装vim，使用上下左右键 sudo apt-get install gcc-multilib 代码如下： //getpass.c #include <sys/types.h> #include <stdio.h> #include <stdlib.h> #include <
本实验窃取密码的前提是要明文传输，先必须找到一个登录页面是采用http协议（非https）的站点，一般的163邮箱都有相应的防御机制，建议使用自己学校的邮箱或门户，随意输入用户名和密码。
前言： 互联网后台的服务器上，通常需要运行多达数百个进程，甚至更多。 有一天，运维兄弟突然找上门，说：xx服务器上为什么要访问yy服务（例如yy服务使用UDP的12345端口）？ 开发一脸懵逼：没有呀！并不是我部署的服务访问的。。。 运维兄弟：我不管，这台机器分配给你了，你要负责，要不你抓包看看？ 开发兄弟娴熟的一手tcpdump -iany -Xnnls0 udp port 12345：哎呦我去，还真有进程在访问，but，是哪个进程呢？UDP无连接，netstat是没有办法了，tcpdump只能证明有包发
BPF (Berkeley Packet Filter) 最早是用在 tcpdump 里面的，比如 tcpdump tcp and dst port 80 这样的过滤规则会单独复制 tcp 协议并且目的端口是 80 的包到用户态。整个实现是基于内核中的一个虚拟机来实现的，通过翻译 BPF 规则到字节码运行到内核中的虚拟机当中。最早的论文是这篇，这篇论文我大概翻了一下，主要讲的是原本的基于栈的过滤太重了，而 BPF 是一套能充分利用 CPU 寄存器，动态注册 filter 的虚拟机实现，相对于基于内存的实现更高效，不过那个时候的内存比较小才几十兆。bpf 会从链路层复制 pakcet 并根据 filter 的规则选择抛弃或者复制，字节码是这样的，具体语法就不介绍了，一般也不会去直接写这些字节码，然后通过内核中实现的一个虚拟机翻译这些字节码，注册过滤规则，这样不修改内核的虚拟机也能实现很多功能。
导言｜nettrace工具自上线以来，受到了业界的广泛关注。特别是复杂的云原生网络环境中，nettrace 工具通过报文跟踪、网络诊断的方式为用户解决了多次疑难网络问题。今天就以OpenCloudOS为例，介绍在云原生场景中nettrace如何快速进行网络故障诊断。 工具简介 1）背景 在一些场景下（特别是云原生场景），Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接，从客户端到服务端，中间可能要经过复杂的 NAT、GRE、IPVS 等过程，网络报文在节点（主机）上的处理路径也变得越来越长
这周帮朋友用 eBPF/SystemTap 这样的动态 tracing 工具做了一些很有趣的功能。这篇文章算是一个总结
在一些场景下（特别是云原生场景），Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接，从客户端到服务端，中间可能要经过复杂的 NAT、GRE、IPVS 等过程，网络报文在节点（主机）上的处理路径也变得越来越长。在发生网络故障（比如网络丢包）时，如何快速、有效地定位出网络问题成为了一个难题。目前常规的网络故障定位手段，如 tcpdump、dropwatch、ftrace、kprobe 等存在一定的短板：
Linux 具有功能丰富的网络协议栈，并且兼顾了非常优秀的性能。但是，这是相对的。单纯从网络协议栈各个子系统的角度来说，确实做到了功能与性能的平衡。不过，当把多个子系统组合起来，去满足实际的业务需求，功能与性能的天平就会倾斜。
在开源 Linux 操作系统 OpenCloudOS 8.6 中，增加了内核对网络工具 nettrace 的支持，允许开发者通过 bpf 进行网络丢包原因跟踪，内核也同时回合相关的丢包跟踪点。今天，就以 nettrace 为典型，介绍如何在 OpenCloudOS 中利用 nettrace 进行网络故障诊断。 一、工具简介 1. 背景 在一些场景下（特别是云原生场景），Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接，从客户端到服务端，中间可能要经过复杂的 NAT、GRE、IPVS 等过程，网
已经多久没有编程了？很久了吧…其实我本来就不怎么会写代码，时不时的也就是为了验证一个系统特性，写点玩具而已，工程化的代码，对于我而言，实在是吃力。
本文翻译自 2020 年 Quentin Monnet 的一篇英文博客：Understanding tc “direct action” mode for BPF[1]。
本文作者：sivenzhang，腾讯 IEG 测试开发工程师 1. 前言 本文主要对 Linux 系统内核协议栈中网络层接收，发送以及转发数据包的流程进行简要介绍，同时对 Netfilter 数据包过滤框架的基本原理以及使用方式进行简单阐述。 内容如有理解错误而导致说明错误的地方，还请指正。如存在引用而没有添加说明的，也请及时告知，非常感谢！ 2. 基础网络知识 2.1 网络分层模型 OSI 模型中将网络划分为七层，但在目前实际广泛使用的 TCP/IP 协议框架体系内，我们一般将网络划分为五层，从
1.首先指出，NF_HOOK系列宏的outdev参数的传递方式(直接传递一个net_device结构体指针)是不正确的 正确的方式要么是不传递，要么是传递指针的地址，即地址的地址。
在分享这篇文章之前，先简单和大家说下背景。在之前的文章中作者分享了一些关于Service Mesh微服务架构的文章，在Service Mesh架构中需要通过SideCar代理的方式对应用容器流量进行劫持，并以此实现微服务治理相关的各种能力。但这种SideCar方式在微服务数量过多时会造成系统性能的降低，因为SideCar本质上来说，也是通过用户代码实现的网络代理来进行流量管控的。而eBPF则是一种替代SideCar的新式解决方案，它存在于操作系统的内核层级，在性能上表现更优。 因此目前关于Service Mesh微服务架构的技术方案开始逐步趋向于使用eBPF来替代原先的像Envoy这样的SideCar代理。本文的内容将详细介绍eBPF的前世今生，具体如下：
sk_buff 是一个贯穿整个协议栈层次的结构，在各层间传递时，内核只需要调整 sk_buff 中的指针位置就行。
wireshark或tcpdump相信大家都用过，这些工具看起来都很酷，因为我们平时都是在界面看到应用层的数据，这些工具居然可以让我们看到tcp/ip协议栈每层的数据。本文介绍一下查看tcp/ip协议栈数据的方法。并实现一个简陋的sniffer，通过nodejs暴露出来使用。我们先看实现。
内核显然需要一个数据结构来表示报文，这个结构就是 sk_buff ( socket buffer 的简称)，它等同于在<TCP/IP详解 卷2>中描述的 BSD 内核中的 mbuf。
Linux 中的 veth 是一对儿能互相连接、互相通信的虚拟网卡。通过使用它，我们可以让 Docker 容器和母机通信，或者是在两个 Docker 容器中进行交流。参见《轻松理解 Docker 网络虚拟化基础之 veth 设备！》。
接前面这个写起，比较过linux kernel vxlan device和ovs vxlan的性能，很好奇ovs vxlan是怎么实现的，linux kernel vxlan device是用如下命令创建的。
伯克利数据包过滤器（BPF）机制自2014年被重写和扩展(eBPF)以来，一直在各种内核子系统中发挥作用。事实证明，通过在内核虚拟机，允许在不编写内核自身代码的情况下实现任意策略的方式，存在着巨大的价值。最近一个将BPF推向网络驱动程序的补丁集显示了这种机制的一些潜力—以及集成一种经得起时间考验的方式的设计难度。如果成功的话，它可能会改变Linux系统上的实现高性能网络方式。
在上一篇文章中，我们主要介绍了 LVS 的原理，接下来我们将会介绍 LVS 的代码实现。
忽然想起的回忆，那是2007上周五在冬季，我看我的老湿调试Linux堆IP层，只看到他改变路由查找的逻辑，然后直接make install上的立竿见影的效果有点，我只知道，，这种逻辑必须再次更改编译内核。再一次，他没有编译，就像刚才编译的文件…时又无聊的工作阻碍了我对Linux内核的探索进度，直到今天，我依旧对编译内核有相当的恐惧，不怕出错，而是怕磁盘空间不够，initrd的组装拆解之类，太繁琐了。我之所以知道2007年的那天是周五，是由于第二天我要加班。没有谁逼我。我自愿的，由于我想知道师父是怎么做到不又一次编译内核就能改变非模块的内核代码处理逻辑的。第二天的收获非常多，不但知道了他使用了“镜像协议栈”。还额外赚了一天的加班费。我还记得周六加完班我和老婆去吃了一家叫做石工坊的羊排火锅。人家赠送了一仅仅绿色的兔子玩偶。
下面以udp为例看看什么时候会发送destination unreachable包。我们从收到一个udp包开始分析，具体函数是udp_rcv。
3。1 module编程 module可以说是 Linux 的一大革新。有了 module 之后，写 device driver 不再是一项恶梦，修改 kernel 也不再是一件痛苦的事了。因为你不需要每次要测试 driver 就重新 compile kernel 一次。那简直是会累死人。Module 可以允许我们动态的改变 kernel，加载 device driver，而且它也能缩短我们driver development 的时间。在这篇文章里，我将要跟各位介绍一下 module 的原理，以及如何写一个 module。
Linux 的 网桥 是一种虚拟设备（使用软件实现），可以将 Linux 内部多个网络接口连接起来，如下图所示：
这里深度理解一下在Linux下网络包的接收过程，为了简单起见，我们用udp来举例，如下：
本文翻译自 2016 年 Daniel Borkman 在 NetdevConf 大会上的一篇文章：On getting tc classifier fully programmable with cls_bpf[1]。
近日的工作多多少少和Linux的流控有点关系。自打几年前知道有TC这么一个玩意儿而且多多少少理解了它的原理之后，我就没有再动过它，由于我不喜欢TC命令行，实在是太繁琐了。iptables命令行也比較繁琐，可是比TC命令行直观，而TC命令行则太过于技术化。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务，所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发，要理解性能开销，会进行性能优化。而很多时候，如果你对Linux底层的理解不深的话，遇到很多线上性能瓶颈你会觉得狗拿刺猬，无从下手。
标题党勿喷，内核可以搞的鬼很多，本文只分析其中一种。 现网问题中，我们经常会遇到一种场景，带宽明明没超限，但是tcp传输性能却不符合预期，而且时快时慢？本文展开分析其中一种常见原因——tcp内存使用太高搞的鬼。
这篇是Network Policy最后一篇，主题是关于eBPF。前面两篇，我们聊完了Network Policy的意义和iptables实现，今天我们聊聊如何借助eBPF来摆脱对iptables的依赖，并实现Network Policy。
IP协议 是网络的最重要部分，毫不夸张地说，正是因为有 IP协议 才有了互联网。而 IP协议 最重要的是 IP地址，IP地址 就好像我们的家庭住址一样，用于其他人方便找到我们的位置。
因为要对百万、千万、甚至是过亿的用户提供各种网络服务，所以在一线互联网企业里面试和晋升后端开发同学的其中一个重点要求就是要能支撑高并发，要理解性能开销，会进行性能优化。而很多时候，如果你对网络底层的理解不深的话，遇到很多线上性能瓶颈你会觉得狗拿刺猬，无从下手。
kubernetes作为云原生不可或缺的重要组件，在编排调度系统中一统天下，成为事实上的标准，如果kubernetes出现问题，那将是灾难性的。而我们在容器化推进的过程中，就遇到了很多有意思的故障，今天我们就来分析一个“雪崩”的案例。
ICMP和ICMPv6是Internet的主要协议。这些协议设计用于在数据包未到达目的地时进行连接测试和错误信令。接收ICMP消息让应用程序了解故障原因：数据包太大，没有可用路由等。
在linux系统中为了更好的实现网络流量的管理，使用了内核的mark来标识网络流量。这样造成了用户层再使用mark来标记多线负载，两种mark会互相覆盖，达不到想要的结果。在此种情况下，通过研究发现可以扩展mark模块来解决这种冲突。 1 Iptables的结构和命令格式分析 1.1 Iptables的结构分析 Iptables是linux系统为用户提供的一个配置防火墙的工具。它提供一个命名规则集。在linux中iptables防火墙实现的核心模块是netfilter，它负责维护防火墙的规则链表，实现防火墙安全防御能力。Netfilter主要有三种功能：数据包过滤、网络地址转换（nat）以及数据包处理（mangle）。数据包过滤模块的功能是过滤报文，不作任何修改，或者接受，或者拒绝。Nat是网络地址转换，该模块以connection tracking模块为基础，仅对每个连接的第一个报文进行匹配和处理，然后交由connection tracking模块将处理结果应用到该连接之后的所有报文。Mangle是属于可以进行报文内容修改的ip tables，可供修改的报文内容包括mark、tos、ttl等。同时该模块带有用户空间和内核交流的接口。 1.2 Iptables命令格式分析 一个最简单的规则可以描述为拒绝所有转发报文，用iptables命令表示就是：iptables -A FORWORD -j DROP。Iptables应用程序将命令行输入转换为程序可读的格式，然后再调用libiptc库提供的iptc_commit（）函数向核心提交该操作请求。它根据请求设置了一个struct ipt_replace结构，用来描述规则所涉及的表和HOOK点等信息，并在其后附接当前这条规则，一个struct ipt_entry结构。组织好这些数据后，iptc_commit（）调用setsockopt（）系统调用来启动核心处理这一请求。 2 Netfilter的结构分析 Netfilter是linux系统中的内核防火墙框架，主要进行包过滤，连接跟踪，地址转换的功能，是防火墙的基础。其主要通过表、链实现。在netfilter中，每种网络协议都有自己的一套hook函数。数据报经过协议栈的几个关键点时调用hook函数，hook函数标号和协议栈数据报作为参数，传递给netfilter框架。其主要框架如图1所示： 3 Netfilter和 Iptables相关模块属性分析 3.1 与netfilter有关的结构 Netfilter一个重大修正思想就是将netfilter作为一个协议无关的框架，表现在内核结构树中单独建立net/netfilter目录，在net/netfilter下的匹配和目标模块文件名称以“xt_”开头。 为了和iptables兼容，这些文件中增加了一个新的宏定义：module_alias，来表示模块的别名。所有扩展程序的名称也是以xt开头。 Netfilter扩展的程序框架： Xt_kzmark.c： Static unsigned int kzmark_tg（struct sk_buff *skb， const struct xt_action_param *par） Static int kzmark_tg_check（const struct xt_tgchk_param *par） Static void kzmark_tg_destroy（const struct xt_tgdtor_param *par） Static boool kzmark_mt（const struct sk_buff *skb， struct xt_action_param *par） Static int kzmark_mt_check（const struct xt_mtchk_param *par） Static void kzmark_mt_destroy（const struct xt_mtdtor_param *par） Static struct xt_target kzmark_tg_reg __read_mostly = {} Static struct xt_match kzmark_mt_reg __read_mostly = {} Static int __init kzmark_mt_init（void） {Int ret； Need_ipv4_conntrack（）； Ret = xt_register_target（&kzmark_tg_reg）； Ret = xt_register_match（&kzmark_mt_reg）；} Static void_exi
安装yum install dropwatch -y 两条命令[root@VM-80-27-centos ~]# dropwatch -l kas # 命令1Initalizing kallsyms dbdropwatch> start # 命令2Enabling monitoring...Kernel monitoring activated.Issue Ctrl-C to stop monitoring1 drops at skb_queue_purge+18 (0xffffffff92a4286
许庆伟：龙蜥社区eBPF技术探索SIG组 Maintainer & Linux Kernel Security Researcher
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
