By

问题与解释

我在PREROUTING上做了一个REDIRECT端口改写，相应的服务处理请求后会返回应答。

按照我以往的认识，认为回包的流量应该先后经过OUTPUT和POSTROUTING，所以我利用iptables -t nat -nvL去查看NAT表在OUTPUT链和POSTROUTING链上的packge计数器，结果发现没有上涨，这让我陷入了沉思。

经过谷歌后找到了完美的解释：linux-netfilter-how-does-connection-tracking-track-connections-changed-by-nat。

阅读更多

By

前提条件

  • iptables已开启并激活

步骤 1: 标记要跟踪的数据包

DNS端口示例

1
2
3
4
5
6
7
PORT=53
which sudo || alias sudo='$@'

sudo iptables -t raw -A OUTPUT     -p udp --dport $PORT -j TRACE
sudo iptables -t raw -A OUTPUT     -p tcp --dport $PORT -j TRACE
sudo iptables -t raw -A PREROUTING -p udp --dport $PORT -j TRACE
sudo iptables -t raw -A PREROUTING -p tcp --dport $PORT -j TRACE

阅读更多

By

基础概念

BPF(CBPF) 说明文档

BPF 的全称是 Berkeley Packet Filter, 即伯克利报文过滤器，它的设计思想来源于 1992 年的一篇论文“The BSD packet filter: A New architecture for user-level packet capture” （《BSD数据包过滤器：一种用于用户级数据包捕获的新体系结构》）。最初，BPF是在 BSD 内核实现的， 后来，由于其出色的设计思想，其他操作系统也将其引入, 包括 Linux。tcpdump 使用的libpcap是基于BPF的，在使用tcpdump或者libpcap时传入的“host 192.168.1.1”、“tcp and port 80”等是过滤表达式。

阅读更多

By

手册

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# man iptables
 
...
 
-j, --jump target
              This  specifies  the  target  of  the  rule; i.e., what to do if the packet matches it.  The target can be a user-
              defined chain (other than the one this rule is in), one of the special builtin targets which decide  the  fate  of
              the  packet  immediately,  or an extension (see EXTENSIONS below).  If this option is omitted in a rule (and -g is
              not used), then matching the rule will have no effect on the packet's fate, but the counters on the rule  will  be
              incremented.
 
-g, --goto chain
              This specifies that the processing should continue in a user specified chain. Unlike the --jump option return will
              not continue processing in this chain but instead in the chain that called us via --jump.

阅读更多

By

本文将基于cURL命令简单演示如何以REST的方式使用Kubernetes API，方便您使用开发语言原生的HTTPS方式操作Kubernetes集群。演示包括创建和删除Pod，创建和修改Deployment。

获取集群访问凭证KubeConfig

  1. 登录容器服务管理控制台。
  2. 在控制台左侧导航栏中，单击集群。
  3. 在集群列表页面中，单击目标集群名称或者目标集群右侧操作列下的详情。
  4. 单击连接信息页签，查看集群访问凭证（KubeConfig），将KubeConfig文件保存到本地。
  5. 从KubeConfig文件中提取ca、key和apiserver信息，命令如下。
1
2
3
cat  ./kubeconfig |grep client-certificate-data | awk -F ' ' '{print $2}' |base64 -d > ./client-cert.pem
cat  ./kubeconfig |grep client-key-data | awk -F ' ' '{print $2}' |base64 -d > ./client-key.pem
APISERVER=`cat  ./kubeconfig |grep server | awk -F ' ' '{print $2}'`

阅读更多

By

写在前面

感谢zhile大神及其开发的ja-netfilter项目，本文主要基于ja-netfilter介绍两种我认为目前最好的破解方式

方法1：基于power插件（推荐）

这个方法十分的简单粗暴并且快捷，激活之后就不需要找再辛苦去找注册码了，所以后续升级也都是没问题的，被zhile大神成为非对称加密的屠龙刀

阅读更多

By

Introduction

本次演講主要是探討封包基於 Docker Container 的預設環境下，不同走向實際上對應到 iptables/ebtables 的實際流向。
演講中主要針對三個方向進行探討，分別是

  • Host to Container
  • Container to Container
  • Container to WAN

每個方向都包含了雙向來回，譬如
Host to Container 其實也包含了 Container to Host
Container to WAN 也包含了 WAN to Containe
主要差別在於誰發起了連線，這中間差異不大 (WAN to Container 可能會有 DNAT)

阅读更多

By

最近线上的一个项目遇到了内存泄露的问题，查了heap之后，发现 http包的 dialConn函数竟然占了内存使用的大头，这个有点懵逼了，后面在网上查询资料的时候无意间发现一句话

10次内存泄露，有9次是goroutine泄露。

结果发现，正是我认为的不可能的goroutine泄露导致了这次的内存泄露，而goroutine泄露的原因就是 没有调用 response.Body.Close()

阅读更多