目录 strongwan sa分析(二) 名词约定 rekey/reauth 机制分析 1 概述 2 reauth 3 CHILD SA rekey 4 IKE SA rekey 5 其他 strongwan sa分析(二) 名词约定 client / initiator: IKE连接的首先发起方. server / responder: IKE连接首先发起方的对方,即响应方. IKE SA: 用于对ISAKMP数据包进行加密的SA. CHILD SA / IPsec SA: 用于对传输数据(用

目录 strongwan sa分析(三) xfrm与strongswan内核接口分析 1. strongswan的实现 2. 交互机制 4. xfrm的消息通信的实现 strongwan sa分析(三) xfrm与strongswan内核接口分析 1. strongswan的实现 如下图,业务场景可以分为两类: 下发类的交互主要由包触发或用户配置动作触发. 消息类的交互主要由watcher监听socket,然后触发. 2. 交互机制 2.1 下发消息 消息名 功能定义 XFRM_MSG_ALLO

strongswan SA分析(一) 1 概念 下面主要介绍两个本文将要阐述的核心概念.他们是SA和SP.注意,这不是一篇不需要背景知识的文章.作者认为你适合阅读接下来内容的的前提是,你已经具备了一下三方面的知识: a. 什么是VPN. b. 什么是IPsec,包括IKE,ESP,strongswan都是什么等. c. 一般的linux使用方法和常见概念. 1.1 什么是SAD,SPD SAD是Security Association Database的缩写. SPD是Security Poli

history: 2019-06-05, 增加配置文件解析部分. 2019-06-05,增加plugin优先级排序部分. charon进程初始化阶段的流程图 约定: 实线代表流程图. 虚线代表调用栈,箭头方向代表自上而下. 黄线是辅助线,请自己理解. 图: netlink模块的类图 图: 从Task到内核xfrm模块的调用关系图 说明: 该图以kernel-netlink plugin为例分析了strongswan 5.7.1的主要代码架构. 该图的后续演进维护将留着这个地方,2中的文档将不会被

前言 我们知道,strongswan是基于插件式管理的.不同的插件有不同的配置文件,在这下面, 我们以netlink的插件为例:etc/strongswan.d/charon/kernel-netlink.conf 在这个文件里,提供了不同的针对插件的配置项.接下来我们将讲解,如何开发这些配置项. 配置文件结构 在开始之前,先了解一下strongswan的配置文件组织结构, strongswan的所有配置项都是层级结构组织的,如:charon.plugins.kernel-netlink.for

目录 strongswan sa 资料 编译 启动 进程信息 结构 架构图与插件 配置运行 传统配置方法 新的配置方法 其他配置方法 详细的配置文档 配置示例 用法 加密库 libgmp libcrypto libgcrypto 依赖的内核模块 child sa 构成 定义 sa信息查看与调试 证书 转发 隧道 路由 MSS/MTU VICI interface 编译DEBUG gdb 代码 接口 架构流程图 ipsec初始化 add policy的调用栈 add sa的调用栈 更多strong

前言 如前所述, 我们知道,strongswan以插件功能来提供各种各样的功能.插件之间彼此相互提供功能,同时也有可能提供重复的功能. 这个时候,便需要一个优先级关系,来保证先后加载顺序. 方法 在配置文件中,有这样一个配置项,配给每一个plugin charon.plugins.<name>.load 它的值,可以是Yes,NO,可以是数字.Yes,No代表是否启用该插件.通知默认赋予优先级的值1. 优先级值随数字增大,优先级越高.高优先级的会 更先被加载.同优先级的,按插件名字的字母表顺序

ABP是一套非常优秀的web应用程序架构,适合用来搭建集中式架构的web应用程序. 整个Abp的Infrastructure是以Abp这个package为核心模块(core)+15个模块(module).其中13个依赖于Abp这个核心包.另外两个包(FluentMigration,Web.Resources)相对独立 Abp.AutoMapper: 实现对象之间的自动映射. Abp.EntityFramework:通过EntityFramework实现数据访问层. Abp.FluentMigra

1. 引言     在红黑树--算法导论(15)中学习了红黑树的原理.本来打算自己来试着实现一下,然而在看了JDK(1.8.0)TreeMap的源码后恍然发现原来它就是利用红黑树实现的(很惭愧学了Java这么久,也写过一些小项目,也使用过TreeMap无数次,但到现在才明白它的实现原理).因此本着"不要重复造轮子"的思想,就用这篇博客来记录分析TreeMap源码的过程,也顺便瞅一瞅HashMap. 2. 继承结构 (1) 继承结构 下面是HashMap与TreeMap的继承结构: pu

nginx作为一个高性能的HTTP服务器,网络的处理是其核心,了解网络的初始化有助于加深对nginx网络处理的了解,本文主要通过nginx的源代码来分析其网络初始化. 从配置文件中读取初始化信息 与网络有关的配置命令主要有两个:listen和sever_name.首先先了解这两个命令的用法. listen listen命令设置nginx监听地址,nginx从这里接受请求.对于IP协议,这个地址就是address和port:对于UNIX域套接字协议,这个地址就是path. 一条listen指令只能

leader的实现类为LeaderZooKeeperServer,它间接继承自标准ZookeeperServer.它规定了请求到达leader时需要经历的路径: PrepRequestProcessor -> ProposalRequestProcessor ->CommitProcessor -> Leader.ToBeAppliedRequestProcessor ->FinalRequestProcessor 具体情况可以参看代码: @Override protected v

上文: zookeeper源码分析之一服务端启动过程 中,我们介绍了zookeeper服务器的启动过程,其中单机是ZookeeperServer启动,集群使用QuorumPeer启动,那么这次我们分析各自一下消息处理过程: 前文可以看到在 1.在单机情况下NettyServerCnxnFactory中启动ZookeeperServer来处理消息: public synchronized void startup() { if (sessionTracker == null) { createSe

znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的集中管理,集群管理,分布式锁等等. 知识准备: zookeeper定义的状态有: Unknown (-1),Disconnected (0),NoSyncConnected (1),SyncConnected (3),AuthFailed (4),ConnectedReadOnly (5),Sasl

转载请在页首注明作者与出处 http://www.cnblogs.com/zhuxiaojie/p/6238826.html 一:本文使用范围 此文不仅仅局限于spring boot,普通的spring工程,甚至是servlet工程,都是一样的,只不过配置一些监听器的方法不同而已. 本文经过作者实践,确认完美运行. 二:Spring boot使用websocket 2.1:依赖包 websocket本身是servlet容器所提供的服务,所以需要在web容器中运行,像我们所使用的tomcat,当然

一般来说,ASP.NET Web应用程序的第一个执行的方法是Global.asax下定义的Start方法.执行这个方法前HttpApplication 实例必须存在,也就是说其构造函数的执行必然是完成了. ABP开始的地方就是HttpApplication的构造函数. 如下图一,Abp定义了一个继承自HttpApplication的类AbpApplication.该类的构造函数里会创建AbpBootstrapper实例,然后再Application_Start方法中调用AbpBootstrapp

Abp是一种基于模块化设计的思想构建的.开发人员可以将自定义的功能以模块(module)的形式集成到ABP中.具体的功能都可以设计成一个单独的Module.Abp底层框架提供便捷的方法集成每个Module.下图是所有Abp自带的module.AbpModule是所有Module的基类,其已经拥有了IIocManager和IAbpStartupConfiguration的受保护的成员,从其派生的Module都可以直接获取并使用相关的功能(依赖注入,Configuration).: 以下以AbpWe

核心模块的配置 Configuration是ABP中设计比较巧妙的地方.其通过AbpStartupConfiguration,Castle的依赖注入,Dictionary对象和扩展方法很巧妙的实现了配置中心化.配置中心化是一个支持模块开发的框架必备功能. ABP中核心功能模块中的一些功能的运行时的行为是依赖于一些外部配置的.这一点应该不难理解. 简单解释下,比如Localization这个功能模块,最基本Abp需要知道要做哪些语言的本地化.而这些具体的配置对于Abp底层框架来说是不可预知的,那么

ABP在初始化阶段做了哪些操作,前面的四篇文章大致描述了一下. 为个更清楚的描述其脉络,做了张流程图以辅助说明.其中每一步都涉及很多细节,难以在一张图中全部表现出来.每一步的细节(会涉及到较多接口,类,调用关系,步骤流程什么的)会在后面的文章中通过其他图和文字详细描述.其实如果仔细分析Abp原代码的话,会发现每个功能模块的实现思路和手法大致基本是一致的. 返回ABP源码分析系列文章目录

ABP的依赖注入的实现有一个本质两个途径:1.本质上是依赖于Castle这个老牌依赖注入的框架.2.一种实现途径是通过实现IConventionalDependencyRegistrar的实例定义注入的约定(规则),然后通过IocManager来读取这个规则完成依赖注入.3另一种实现途径是直接IocManager的Register方法直接完成注入. 第一种途径: 下面具体分析:代码在Abp项目文件的Dependency文件夹下. 先出一张相关接口和类的关系图,然后逐个解释. IDictionar

本文主要说明Setting的实现以及Mail这个功能模块如何使用Setting. 首先区分一下ABP中的Setting和Configuration. Setting一般用于需要通过外部配置文件(或数据库)设置的简单类型数据(一般就是字符串),比如SMTP HOST. Configuration一般只需要通过内部代码完成的配置,一般用于设置复杂类型的数据. 目前Abp在setting 这个功能模块只能从配置文件读取设置,无法从其他source(比如数据库)读取设置.也可以自定义SettingSto