- rewrite of logger_manager, uses now one instance per context
- cleanups for logger here and there - removed critical flag check in payload verification (conformance to IKEv2) - so thats and theres everywere... ;-)
This commit is contained in:
@@ -51,6 +51,9 @@ Therefore plutos behavior is changed to discard any IKEv2 traffic silently.
|
||||
IKEv2 keying daemon: charon
|
||||
=============================
|
||||
|
||||
Threading modell
|
||||
------------------
|
||||
|
||||
All IKEv2 stuff is handled in charon. It uses a newer and more flexible
|
||||
architecture than pluto. Charon uses a thread-pool, which allows parallel
|
||||
execution SA-management. Beside the thread-pool, there are some special purpose
|
||||
@@ -60,14 +63,14 @@ threads which do their job for the common health of the daemon.
|
||||
¦ E Q ¦
|
||||
¦ v u ¦---+ +------+ +------+
|
||||
¦ e e ¦ ¦ ¦ ¦ ¦ IKE- ¦
|
||||
¦ n u ¦ +----------+ ¦ ¦--¦ SA ¦
|
||||
¦ t e ¦ ¦ ¦ ¦ I M ¦ +------+
|
||||
+------------+ ¦ - ¦ ¦ Sceduler ¦ ¦ K A ¦
|
||||
¦ receiver ¦ +------+ ¦ ¦ ¦ E N ¦ +------+
|
||||
+----+-------+ +----------+ ¦ - A ¦ ¦ IKE- ¦
|
||||
¦ ¦ +------+ ¦ ¦ S G ¦--¦ SA ¦
|
||||
+-------+--+ +-----¦ J Q ¦---+ +------------+ ¦ A E ¦ +------+
|
||||
-¦ socket ¦ ¦ o u ¦ ¦ ¦ ¦ - R ¦
|
||||
¦ n u ¦ +-----------+ ¦ ¦--¦ SA ¦
|
||||
¦ t e ¦ ¦ ¦ ¦ I M ¦ +------+
|
||||
+------------+ ¦ - ¦ ¦ Scheduler ¦ ¦ K a ¦
|
||||
¦ receiver ¦ +------+ ¦ ¦ ¦ E n ¦ +------+
|
||||
+----+-------+ +-----------+ ¦ - a ¦ ¦ IKE- ¦
|
||||
¦ ¦ +------+ ¦ ¦ S g ¦--¦ SA ¦
|
||||
+-------+--+ +-----¦ J Q ¦---+ +------------+ ¦ A e ¦ +------+
|
||||
-¦ socket ¦ ¦ o u ¦ ¦ ¦ ¦ - r ¦
|
||||
+-------+--+ ¦ b e ¦ ¦ Thread- ¦ ¦ ¦
|
||||
¦ ¦ - u ¦ ¦ Pool ¦ ¦ ¦
|
||||
+----+-------+ ¦ e ¦------¦ ¦---¦ ¦
|
||||
@@ -77,18 +80,16 @@ threads which do their job for the common health of the daemon.
|
||||
¦ ¦ S Q ¦
|
||||
¦ ¦ e u ¦
|
||||
¦ ¦ n e ¦
|
||||
¦ ¦ d u ¦
|
||||
¦ ¦ - e ¦
|
||||
¦ +--+---+
|
||||
¦ ¦
|
||||
+---------------+
|
||||
+------------¦ d u ¦
|
||||
¦ - e ¦
|
||||
+--+---+
|
||||
|
||||
The thread-pool is the heart of the architecture. It processes jobs from a
|
||||
(fully synchronized) job-queue. Mostly, a job is associated with a specific
|
||||
IKE SA. These IKE SAs are synchronized, only one thread can work one an IKE SA.
|
||||
This makes it unnecesary to use further synchronisation methods once a IKE SA
|
||||
is checked out. The (rather complex) synchronization of IKE SAs is completely
|
||||
don in the IKE SA manager.
|
||||
done in the IKE SA manager.
|
||||
The sceduler is responsible for event firing. It waits until a event in the
|
||||
(fully synchronized) event-queue is ready for processing and pushes the event
|
||||
down to the job-queue. A thread form the pool will pick it up as quick as
|
||||
@@ -101,6 +102,11 @@ There are even more threads, not drawn in the upper scheme. The stroke thread
|
||||
is responsible for reading and processessing commands from another process. The
|
||||
kernel interface thread handles communication from and to the kernel via a
|
||||
netlink socket. It waits for kernel events and processes them appropriately.
|
||||
|
||||
|
||||
configuration backends
|
||||
------------------------
|
||||
|
||||
The configuration architecture for charon is complex, but is flexible and
|
||||
extensible. All configuration stuff is split up in multiple parts:
|
||||
|
||||
@@ -110,13 +116,13 @@ policy Defines the rules to apply ontop of a connection. A policy is
|
||||
defined between two IDs. Proposals and traffic selectors allow
|
||||
fine grained configuration of the CHILD SAs (AH and ESP) to set
|
||||
up.
|
||||
credential A credential something used for authentication, such as a
|
||||
credential A credential is something used for authentication, such as a
|
||||
preshared key, a RSA private or public key, certificate, ...
|
||||
configuration The configuration itself handles daemon related configuration
|
||||
stuff, such as interface binding or logging settings.
|
||||
|
||||
These configuration types are defined as interfaces, and are currently
|
||||
implemented only in the stroke class. Through the modular design, parts can be
|
||||
implemented only in the stroke class. Through the modular design, parts could be
|
||||
replaced with more powerful backends, such as a RADIUS server for the
|
||||
credentials, a SQL database for the connections, policy definitions on an LDAP
|
||||
server, and so on...
|
||||
server, and so on...
|
||||
|
||||
Reference in New Issue
Block a user