conf: Split strongswan.conf(5) man page and use generated snippet
This commit is contained in:
Tobias Brunner
parent
7f62b7d02d
commit
c4bb26b849
|
|
@ -1,4 +1,6 @@
|
|||
default.conf
|
||||
strongswan.conf.5
|
||||
strongswan.conf.5.head
|
||||
strongswan.conf.5.tail
|
||||
*/*.conf
|
||||
*/*.tmp
|
||||
|
|
@ -58,6 +58,10 @@ strongswan.conf.5.main: $(alloptions)
|
|||
$(AM_V_GEN) \
|
||||
$(PYTHON) $(srcdir)/format-options.py -f man $^ > $@
|
||||
|
||||
strongswan.conf.5: strongswan.conf.5.head strongswan.conf.5.main strongswan.conf.5.tail
|
||||
$(AM_V_GEN) \
|
||||
cat $^ > $@
|
||||
|
||||
maintainer-clean-local:
|
||||
cd $(srcdir) && \
|
||||
rm -f $(confsnippets) default.conf plugins/*.conf plugins/*.tmp
|
||||
|
|
|
|||
|
|
@ -0,0 +1,127 @@
|
|||
.TH STRONGSWAN.CONF 5 "" "@PACKAGE_VERSION@" "strongSwan"
|
||||
.SH NAME
|
||||
strongswan.conf \- strongSwan configuration file
|
||||
.SH DESCRIPTION
|
||||
While the
|
||||
.IR ipsec.conf (5)
|
||||
configuration file is well suited to define IPsec related configuration
|
||||
parameters, it is not useful for other strongSwan applications to read options
|
||||
from this file.
|
||||
The file is hard to parse and only
|
||||
.I ipsec starter
|
||||
is capable of doing so. As the number of components of the strongSwan project
|
||||
is continually growing, a more flexible configuration file was needed, one that
|
||||
is easy to extend and can be used by all components. With strongSwan 4.2.1
|
||||
.IR strongswan.conf (5)
|
||||
was introduced which meets these requirements.
|
||||
|
||||
.SH SYNTAX
|
||||
The format of the strongswan.conf file consists of hierarchical
|
||||
.B sections
|
||||
and a list of
|
||||
.B key/value pairs
|
||||
in each section. Each section has a name, followed by C-Style curly brackets
|
||||
defining the section body. Each section body contains a set of subsections
|
||||
and key/value pairs:
|
||||
.PP
|
||||
.EX
|
||||
settings := (section|keyvalue)*
|
||||
section := name { settings }
|
||||
keyvalue := key = value\\n
|
||||
.EE
|
||||
.PP
|
||||
Values must be terminated by a newline.
|
||||
.PP
|
||||
Comments are possible using the \fB#\fP-character, but be careful: The parser
|
||||
implementation is currently limited and does not like brackets in comments.
|
||||
.PP
|
||||
Section names and keys may contain any printable character except:
|
||||
.PP
|
||||
.EX
|
||||
. { } # \\n \\t space
|
||||
.EE
|
||||
.PP
|
||||
An example file in this format might look like this:
|
||||
.PP
|
||||
.EX
|
||||
a = b
|
||||
section-one {
|
||||
somevalue = asdf
|
||||
subsection {
|
||||
othervalue = xxx
|
||||
}
|
||||
# yei, a comment
|
||||
yetanother = zz
|
||||
}
|
||||
section-two {
|
||||
x = 12
|
||||
}
|
||||
.EE
|
||||
.PP
|
||||
Indentation is optional, you may use tabs or spaces.
|
||||
|
||||
.SH INCLUDING FILES
|
||||
Using the
|
||||
.B include
|
||||
statement it is possible to include other files into strongswan.conf, e.g.
|
||||
.PP
|
||||
.EX
|
||||
include /some/path/*.conf
|
||||
.EE
|
||||
.PP
|
||||
If the file name is not an absolute path, it is considered to be relative
|
||||
to the directory of the file containing the include statement. The file name
|
||||
may include shell wildcards (see
|
||||
.IR sh (1)).
|
||||
Also, such inclusions can be nested.
|
||||
.PP
|
||||
Sections loaded from included files
|
||||
.I extend
|
||||
previously loaded sections; already existing values are
|
||||
.IR replaced .
|
||||
It is important to note that settings are added relative to the section the
|
||||
include statement is in.
|
||||
.PP
|
||||
As an example, the following three files result in the same final
|
||||
config as the one given above:
|
||||
.PP
|
||||
.EX
|
||||
a = b
|
||||
section-one {
|
||||
somevalue = before include
|
||||
include include.conf
|
||||
}
|
||||
include other.conf
|
||||
|
||||
include.conf:
|
||||
# settings loaded from this file are added to section-one
|
||||
# the following replaces the previous value
|
||||
somevalue = asdf
|
||||
subsection {
|
||||
othervalue = yyy
|
||||
}
|
||||
yetanother = zz
|
||||
|
||||
other.conf:
|
||||
# this extends section-one and subsection
|
||||
section-one {
|
||||
subsection {
|
||||
# this replaces the previous value
|
||||
othervalue = xxx
|
||||
}
|
||||
}
|
||||
section-two {
|
||||
x = 12
|
||||
}
|
||||
.EE
|
||||
|
||||
.SH READING VALUES
|
||||
Values are accessed using a dot-separated section list and a key.
|
||||
With reference to the example above, accessing
|
||||
.B section-one.subsection.othervalue
|
||||
will return
|
||||
.BR xxx .
|
||||
|
||||
.SH DEFINED KEYS
|
||||
The following keys are currently defined (using dot notation). The default
|
||||
value (if any) is listed in brackets after the key.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,606 @@
|
|||
.SH LOGGER CONFIGURATION
|
||||
The options described below provide a much more flexible way to configure
|
||||
loggers for the IKEv2 daemon charon than using the
|
||||
.B charondebug
|
||||
option in
|
||||
.BR ipsec.conf (5).
|
||||
.PP
|
||||
.B Please note
|
||||
that if any loggers are specified in strongswan.conf,
|
||||
.B charondebug
|
||||
does not have any effect.
|
||||
.PP
|
||||
There are currently two types of loggers defined:
|
||||
.TP
|
||||
.B File loggers
|
||||
Log directly to a file and are defined by specifying the full path to the
|
||||
file as subsection in the
|
||||
.B charon.filelog
|
||||
section. To log to the console the two special filenames
|
||||
.BR stdout " and " stderr
|
||||
can be used.
|
||||
.TP
|
||||
.B Syslog loggers
|
||||
Log into a syslog facility and are defined by specifying the facility to log to
|
||||
as the name of a subsection in the
|
||||
.B charon.syslog
|
||||
section. The following facilities are currently supported:
|
||||
.BR daemon " and " auth .
|
||||
.PP
|
||||
Multiple loggers can be defined for each type with different log verbosity for
|
||||
the different subsystems of the daemon.
|
||||
.SS Options
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.default " [1]"
|
||||
.TQ
|
||||
.BR charon.syslog.<facility>.default
|
||||
Specifies the default loglevel to be used for subsystems for which no specific
|
||||
loglevel is defined.
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.<subsystem> " [<default>]"
|
||||
.TQ
|
||||
.BR charon.syslog.<facility>.<subsystem>
|
||||
Specifies the loglevel for the given subsystem.
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.append " [yes]"
|
||||
If this option is enabled log entries are appended to the existing file.
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.flush_line " [no]"
|
||||
Enabling this option disables block buffering and enables line buffering.
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.ike_name " [no]"
|
||||
.TQ
|
||||
.BR charon.syslog.<facility>.ike_name
|
||||
Prefix each log entry with the connection name and a unique numerical
|
||||
identifier for each IKE_SA.
|
||||
.TP
|
||||
.BR charon.filelog.<filename>.time_format
|
||||
Prefix each log entry with a timestamp. The option accepts a format string as
|
||||
passed to
|
||||
.BR strftime (3).
|
||||
.TP
|
||||
.BR charon.syslog.identifier
|
||||
Global identifier used for an
|
||||
.BR openlog (3)
|
||||
call, prepended to each log message by syslog. If not configured,
|
||||
.BR openlog (3)
|
||||
is not called, so the value will depend on system defaults (often the program
|
||||
name).
|
||||
|
||||
.SS Subsystems
|
||||
.TP
|
||||
.B dmn
|
||||
Main daemon setup/cleanup/signal handling
|
||||
.TP
|
||||
.B mgr
|
||||
IKE_SA manager, handling synchronization for IKE_SA access
|
||||
.TP
|
||||
.B ike
|
||||
IKE_SA
|
||||
.TP
|
||||
.B chd
|
||||
CHILD_SA
|
||||
.TP
|
||||
.B job
|
||||
Jobs queueing/processing and thread pool management
|
||||
.TP
|
||||
.B cfg
|
||||
Configuration management and plugins
|
||||
.TP
|
||||
.B knl
|
||||
IPsec/Networking kernel interface
|
||||
.TP
|
||||
.B net
|
||||
IKE network communication
|
||||
.TP
|
||||
.B asn
|
||||
Low-level encoding/decoding (ASN.1, X.509 etc.)
|
||||
.TP
|
||||
.B enc
|
||||
Packet encoding/decoding encryption/decryption operations
|
||||
.TP
|
||||
.B tls
|
||||
libtls library messages
|
||||
.TP
|
||||
.B esp
|
||||
libipsec library messages
|
||||
.TP
|
||||
.B lib
|
||||
libstrongwan library messages
|
||||
.TP
|
||||
.B tnc
|
||||
Trusted Network Connect
|
||||
.TP
|
||||
.B imc
|
||||
Integrity Measurement Collector
|
||||
.TP
|
||||
.B imv
|
||||
Integrity Measurement Verifier
|
||||
.TP
|
||||
.B pts
|
||||
Platform Trust Service
|
||||
.SS Loglevels
|
||||
.TP
|
||||
.B -1
|
||||
Absolutely silent
|
||||
.TP
|
||||
.B 0
|
||||
Very basic auditing logs, (e.g. SA up/SA down)
|
||||
.TP
|
||||
.B 1
|
||||
Generic control flow with errors, a good default to see whats going on
|
||||
.TP
|
||||
.B 2
|
||||
More detailed debugging control flow
|
||||
.TP
|
||||
.B 3
|
||||
Including RAW data dumps in Hex
|
||||
.TP
|
||||
.B 4
|
||||
Also include sensitive material in dumps, e.g. keys
|
||||
.SS Example
|
||||
.PP
|
||||
.EX
|
||||
charon {
|
||||
filelog {
|
||||
/var/log/charon.log {
|
||||
time_format = %b %e %T
|
||||
append = no
|
||||
default = 1
|
||||
}
|
||||
stderr {
|
||||
ike = 2
|
||||
knl = 3
|
||||
ike_name = yes
|
||||
}
|
||||
}
|
||||
syslog {
|
||||
# enable logging to LOG_DAEMON, use defaults
|
||||
daemon {
|
||||
}
|
||||
# minimalistic IKE auditing logging to LOG_AUTHPRIV
|
||||
auth {
|
||||
default = -1
|
||||
ike = 0
|
||||
}
|
||||
}
|
||||
}
|
||||
.EE
|
||||
|
||||
.SH JOB PRIORITY MANAGEMENT
|
||||
Some operations in the IKEv2 daemon charon are currently implemented
|
||||
synchronously and blocking. Two examples for such operations are communication
|
||||
with a RADIUS server via EAP-RADIUS, or fetching CRL/OCSP information during
|
||||
certificate chain verification. Under high load conditions, the thread pool may
|
||||
run out of available threads, and some more important jobs, such as liveness
|
||||
checking, may not get executed in time.
|
||||
.PP
|
||||
To prevent thread starvation in such situations job priorities were introduced.
|
||||
The job processor will reserve some threads for higher priority jobs, these
|
||||
threads are not available for lower priority, locking jobs.
|
||||
.SS Implementation
|
||||
Currently 4 priorities have been defined, and they are used in charon as
|
||||
follows:
|
||||
.TP
|
||||
.B CRITICAL
|
||||
Priority for long-running dispatcher jobs.
|
||||
.TP
|
||||
.B HIGH
|
||||
INFORMATIONAL exchanges, as used by liveness checking (DPD).
|
||||
.TP
|
||||
.B MEDIUM
|
||||
Everything not HIGH/LOW, including IKE_SA_INIT processing.
|
||||
.TP
|
||||
.B LOW
|
||||
IKE_AUTH message processing. RADIUS and CRL fetching block here
|
||||
.PP
|
||||
Although IKE_SA_INIT processing is computationally expensive, it is explicitly
|
||||
assigned to the MEDIUM class. This allows charon to do the DH exchange while
|
||||
other threads are blocked in IKE_AUTH. To prevent the daemon from accepting more
|
||||
IKE_SA_INIT requests than it can handle, use IKE_SA_INIT DROPPING.
|
||||
.PP
|
||||
The thread pool processes jobs strictly by priority, meaning it will consume all
|
||||
higher priority jobs before looking for ones with lower priority. Further, it
|
||||
reserves threads for certain priorities. A priority class having reserved
|
||||
.I n
|
||||
threads will always have
|
||||
.I n
|
||||
threads available for this class (either currently processing a job, or waiting
|
||||
for one).
|
||||
.SS Configuration
|
||||
To ensure that there are always enough threads available for higher priority
|
||||
tasks, threads must be reserved for each priority class.
|
||||
.TP
|
||||
.BR charon.processor.priority_threads.critical " [0]"
|
||||
Threads reserved for CRITICAL priority class jobs
|
||||
.TP
|
||||
.BR charon.processor.priority_threads.high " [0]"
|
||||
Threads reserved for HIGH priority class jobs
|
||||
.TP
|
||||
.BR charon.processor.priority_threads.medium " [0]"
|
||||
Threads reserved for MEDIUM priority class jobs
|
||||
.TP
|
||||
.BR charon.processor.priority_threads.low " [0]"
|
||||
Threads reserved for LOW priority class jobs
|
||||
.PP
|
||||
Let's consider the following configuration:
|
||||
.PP
|
||||
.EX
|
||||
charon {
|
||||
processor {
|
||||
priority_threads {
|
||||
high = 1
|
||||
medium = 4
|
||||
}
|
||||
}
|
||||
}
|
||||
.EE
|
||||
.PP
|
||||
With this configuration, one thread is reserved for HIGH priority tasks. As
|
||||
currently only liveness checking and stroke message processing is done with
|
||||
high priority, one or two threads should be sufficient.
|
||||
.PP
|
||||
The MEDIUM class mostly processes non-blocking jobs. Unless your setup is
|
||||
experiencing many blocks in locks while accessing shared resources, threads for
|
||||
one or two times the number of CPU cores is fine.
|
||||
.PP
|
||||
It is usually not required to reserve threads for CRITICAL jobs. Jobs in this
|
||||
class rarely return and do not release their thread to the pool.
|
||||
.PP
|
||||
The remaining threads are available for LOW priority jobs. Reserving threads
|
||||
does not make sense (until we have an even lower priority).
|
||||
.SS Monitoring
|
||||
To see what the threads are actually doing, invoke
|
||||
.IR "ipsec statusall" .
|
||||
Under high load, something like this will show up:
|
||||
.PP
|
||||
.EX
|
||||
worker threads: 2 or 32 idle, 5/1/2/22 working,
|
||||
job queue: 0/0/1/149, scheduled: 198
|
||||
.EE
|
||||
.PP
|
||||
From 32 worker threads,
|
||||
.IP 2
|
||||
are currently idle.
|
||||
.IP 5
|
||||
are running CRITICAL priority jobs (dispatching from sockets, etc.).
|
||||
.IP 1
|
||||
is currently handling a HIGH priority job. This is actually the thread currently
|
||||
providing this information via stroke.
|
||||
.IP 2
|
||||
are handling MEDIUM priority jobs, likely IKE_SA_INIT or CREATE_CHILD_SA
|
||||
messages.
|
||||
.IP 22
|
||||
are handling LOW priority jobs, probably waiting for an EAP-RADIUS response
|
||||
while processing IKE_AUTH messages.
|
||||
.PP
|
||||
The job queue load shows how many jobs are queued for each priority, ready for
|
||||
execution. The single MEDIUM priority job will get executed immediately, as
|
||||
we have two spare threads reserved for MEDIUM class jobs.
|
||||
|
||||
.SH IKE_SA_INIT DROPPING
|
||||
If a responder receives more connection requests per seconds than it can handle,
|
||||
it does not make sense to accept more IKE_SA_INIT messages. And if they are
|
||||
queued but can't get processed in time, an answer might be sent after the
|
||||
client has already given up and restarted its connection setup. This
|
||||
additionally increases the load on the responder.
|
||||
.PP
|
||||
To limit the responder load resulting from new connection attempts, the daemon
|
||||
can drop IKE_SA_INIT messages just after reception. There are two mechanisms to
|
||||
decide if this should happen, configured with the following options:
|
||||
.TP
|
||||
.BR charon.init_limit_half_open " [0]"
|
||||
Limit based on the number of half open IKE_SAs. Half open IKE_SAs are SAs in
|
||||
connecting state, but not yet established.
|
||||
.TP
|
||||
.BR charon.init_limit_job_load " [0]"
|
||||
Limit based on the number of jobs currently queued for processing (sum over all
|
||||
job priorities).
|
||||
.PP
|
||||
The second limit includes load from other jobs, such as rekeying. Choosing a
|
||||
good value is difficult and depends on the hardware and expected load.
|
||||
.PP
|
||||
The first limit is simpler to calculate, but includes the load from new
|
||||
connections only. If your responder is capable of negotiating 100 tunnels/s, you
|
||||
might set this limit to 1000. The daemon will then drop new connection attempts
|
||||
if generating a response would require more than 10 seconds. If you are
|
||||
allowing for a maximum response time of more than 30 seconds, consider adjusting
|
||||
the timeout for connecting IKE_SAs
|
||||
.RB ( charon.half_open_timeout ).
|
||||
A responder, by default, deletes an IKE_SA if the initiator does not establish
|
||||
it within 30 seconds. Under high load, a higher value might be required.
|
||||
|
||||
.SH LOAD TESTS
|
||||
To do stability testing and performance optimizations, the IKEv2 daemon charon
|
||||
provides the load-tester plugin. This plugin allows one to setup thousands of
|
||||
tunnels concurrently against the daemon itself or a remote host.
|
||||
.PP
|
||||
.B WARNING:
|
||||
Never enable the load-testing plugin on productive systems. It provides
|
||||
preconfigured credentials and allows an attacker to authenticate as any user.
|
||||
.SS Options
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.addrs
|
||||
Subsection that contains key/value pairs with address pools (in CIDR notation)
|
||||
to use for a specific network interface e.g. eth0 = 10.10.0.0/16
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.addrs_keep " [no]"
|
||||
Whether to keep dynamic addresses even after the associated SA got terminated
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.addrs_prefix " [16]"
|
||||
Network prefix length to use when installing dynamic addresses. If set to -1 the
|
||||
full address is used (i.e. 32 or 128)
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.ca_dir
|
||||
Directory to load (intermediate) CA certificates from
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.child_rekey " [600]"
|
||||
Seconds to start CHILD_SA rekeying after setup
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.delay " [0]"
|
||||
Delay between initiatons for each thread
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.delete_after_established " [no]"
|
||||
Delete an IKE_SA as soon as it has been established
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.digest " [sha1]"
|
||||
Digest algorithm used when issuing certificates
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.dpd_delay " [0]"
|
||||
DPD delay to use in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.dynamic_port " [0]"
|
||||
Base port to be used for requests (each client uses a different port)
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.eap_password " [default-pwd]"
|
||||
EAP secret to use in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.enable " [no]"
|
||||
Enable the load testing plugin
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.esp " [aes128-sha1]"
|
||||
CHILD_SA proposal to use for load tests
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.fake_kernel " [no]"
|
||||
Fake the kernel interface to allow load-testing against self
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.ike_rekey " [0]"
|
||||
Seconds to start IKE_SA rekeying after setup
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.init_limit " [0]"
|
||||
Global limit of concurrently established SAs during load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator " [0.0.0.0]"
|
||||
Address to initiate from
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiators " [0]"
|
||||
Number of concurrent initiator threads to use in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator_auth " [pubkey]"
|
||||
Authentication method(s) the intiator uses
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator_id
|
||||
Initiator ID used in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator_match
|
||||
Initiator ID to match against as responder
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator_tsi
|
||||
Traffic selector on initiator side, as proposed by initiator
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.initiator_tsr
|
||||
Traffic selector on responder side, as proposed by initiator
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.iterations " [1]"
|
||||
Number of IKE_SAs to initiate by each initiator in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.issuer_cert
|
||||
Path to the issuer certificate (if not configured a hard-coded value is used)
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.issuer_key
|
||||
Path to private key that is used to issue certificates (if not configured a
|
||||
hard-coded value is used)
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.mode " [tunnel]"
|
||||
IPsec mode to use, one of \fBtunnel\fR, \fBtransport\fR, or \fBbeet\fR.
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.pool
|
||||
Provide INTERNAL_IPV4_ADDRs from a named pool
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.preshared_key " [default-psk]"
|
||||
Preshared key to use in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.proposal " [aes128-sha1-modp768]"
|
||||
IKE proposal to use in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.responder " [127.0.0.1]"
|
||||
Address to initiation connections to
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.responder_auth " [pubkey]"
|
||||
Authentication method(s) the responder uses
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.responder_id
|
||||
Responder ID used in load test
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.responder_tsi " [initiator_tsi]"
|
||||
Traffic selector on initiator side, as narrowed by responder
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.responder_tsr " [initiator_tsr]"
|
||||
Traffic selector on responder side, as narrowed by responder
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.request_virtual_ip " [no]"
|
||||
Request an INTERNAL_IPV4_ADDR from the server
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.shutdown_when_complete " [no]"
|
||||
Shutdown the daemon after all IKE_SAs have been established
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.socket " [unix://@piddir@/charon.ldt]"
|
||||
Socket provided by the load-tester plugin
|
||||
.TP
|
||||
.BR charon.plugins.load-tester.version " [0]"
|
||||
IKE version to use (0 means use IKEv2 as initiator and accept any version as
|
||||
responder)
|
||||
.PP
|
||||
.SS Configuration details
|
||||
For public key authentication, the responder uses the
|
||||
.B \(dqCN=srv, OU=load-test, O=strongSwan\(dq
|
||||
identity. For the initiator, each connection attempt uses a different identity
|
||||
in the form
|
||||
.BR "\(dqCN=c1-r1, OU=load-test, O=strongSwan\(dq" ,
|
||||
where the first number inidicates the client number, the second the
|
||||
authentication round (if multiple authentication is used).
|
||||
.PP
|
||||
For PSK authentication, FQDN identities are used. The server uses
|
||||
.BR srv.strongswan.org ,
|
||||
the client uses an identity in the form
|
||||
.BR c1-r1.strongswan.org .
|
||||
.PP
|
||||
For EAP authentication, the client uses a NAI in the form
|
||||
.BR 100000000010001@strongswan.org .
|
||||
.PP
|
||||
To configure multiple authentication, concatenate multiple methods using, e.g.
|
||||
.EX
|
||||
initiator_auth = pubkey|psk|eap-md5|eap-aka
|
||||
.EE
|
||||
.PP
|
||||
The responder uses a hardcoded certificate based on a 1024-bit RSA key.
|
||||
This certificate additionally serves as CA certificate. A peer uses the same
|
||||
private key, but generates client certificates on demand signed by the CA
|
||||
certificate. Install the Responder/CA certificate on the remote host to
|
||||
authenticate all clients.
|
||||
.PP
|
||||
To speed up testing, the load tester plugin implements a special Diffie-Hellman
|
||||
implementation called modpnull. By setting
|
||||
.EX
|
||||
proposal = aes128-sha1-modpnull
|
||||
.EE
|
||||
this wicked fast DH implementation is used. It does not provide any security
|
||||
at all, but allows one to run tests without DH calculation overhead.
|
||||
.SS Examples
|
||||
.PP
|
||||
In the simplest case, the daemon initiates IKE_SAs against itself using the
|
||||
loopback interface. This will actually establish double the number of IKE_SAs,
|
||||
as the daemon is initiator and responder for each IKE_SA at the same time.
|
||||
Installation of IPsec SAs would fails, as each SA gets installed twice. To
|
||||
simulate the correct behavior, a fake kernel interface can be enabled which does
|
||||
not install the IPsec SAs at the kernel level.
|
||||
.PP
|
||||
A simple loopback configuration might look like this:
|
||||
.PP
|
||||
.EX
|
||||
charon {
|
||||
# create new IKE_SAs for each CHILD_SA to simulate
|
||||
# different clients
|
||||
reuse_ikesa = no
|
||||
# turn off denial of service protection
|
||||
dos_protection = no
|
||||
|
||||
plugins {
|
||||
load-tester {
|
||||
# enable the plugin
|
||||
enable = yes
|
||||
# use 4 threads to initiate connections
|
||||
# simultaneously
|
||||
initiators = 4
|
||||
# each thread initiates 1000 connections
|
||||
iterations = 1000
|
||||
# delay each initiation in each thread by 20ms
|
||||
delay = 20
|
||||
# enable the fake kernel interface to
|
||||
# avoid SA conflicts
|
||||
fake_kernel = yes
|
||||
}
|
||||
}
|
||||
}
|
||||
.EE
|
||||
.PP
|
||||
This will initiate 4000 IKE_SAs within 20 seconds. You may increase the delay
|
||||
value if your box can not handle that much load, or decrease it to put more
|
||||
load on it. If the daemon starts retransmitting messages your box probably can
|
||||
not handle all connection attempts.
|
||||
.PP
|
||||
The plugin also allows one to test against a remote host. This might help to
|
||||
test against a real world configuration. A connection setup to do stress
|
||||
testing of a gateway might look like this:
|
||||
.PP
|
||||
.EX
|
||||
charon {
|
||||
reuse_ikesa = no
|
||||
threads = 32
|
||||
|
||||
plugins {
|
||||
load-tester {
|
||||
enable = yes
|
||||
# 10000 connections, ten in parallel
|
||||
initiators = 10
|
||||
iterations = 1000
|
||||
# use a delay of 100ms, overall time is:
|
||||
# iterations * delay = 100s
|
||||
delay = 100
|
||||
# address of the gateway
|
||||
remote = 1.2.3.4
|
||||
# IKE-proposal to use
|
||||
proposal = aes128-sha1-modp1024
|
||||
# use faster PSK authentication instead
|
||||
# of 1024bit RSA
|
||||
initiator_auth = psk
|
||||
responder_auth = psk
|
||||
# request a virtual IP using configuration
|
||||
# payloads
|
||||
request_virtual_ip = yes
|
||||
# enable CHILD_SA every 60s
|
||||
child_rekey = 60
|
||||
}
|
||||
}
|
||||
}
|
||||
.EE
|
||||
|
||||
.SH IKEv2 RETRANSMISSION
|
||||
Retransmission timeouts in the IKEv2 daemon charon can be configured globally
|
||||
using the three keys listed below:
|
||||
.PP
|
||||
.RS
|
||||
.nf
|
||||
.BR charon.retransmit_base " [1.8]"
|
||||
.BR charon.retransmit_timeout " [4.0]"
|
||||
.BR charon.retransmit_tries " [5]"
|
||||
.fi
|
||||
.RE
|
||||
.PP
|
||||
The following algorithm is used to calculate the timeout:
|
||||
.PP
|
||||
.EX
|
||||
relative timeout = retransmit_timeout * retransmit_base ^ (n-1)
|
||||
.EE
|
||||
.PP
|
||||
Where
|
||||
.I n
|
||||
is the current retransmission count.
|
||||
.PP
|
||||
Using the default values, packets are retransmitted in:
|
||||
|
||||
.TS
|
||||
l r r
|
||||
---
|
||||
lB r r.
|
||||
Retransmission Relative Timeout Absolute Timeout
|
||||
1 4s 4s
|
||||
2 7s 11s
|
||||
3 13s 24s
|
||||
4 23s 47s
|
||||
5 42s 89s
|
||||
giving up 76s 165s
|
||||
.TE
|
||||
|
||||
.SH FILES
|
||||
/etc/strongswan.conf
|
||||
|
||||
.SH SEE ALSO
|
||||
\fBipsec.conf\fR(5), \fBipsec.secrets\fR(5), \fBipsec\fR(8), \fBcharon-cmd\fR(8)
|
||||
|
||||
.SH HISTORY
|
||||
Written for the
|
||||
.UR http://www.strongswan.org
|
||||
strongSwan project
|
||||
.UE
|
||||
by Tobias Brunner, Andreas Steffen and Martin Willi.
|
||||
|
|
@ -1545,7 +1545,8 @@ AC_CONFIG_FILES([
|
|||
# =================
|
||||
|
||||
AC_CONFIG_FILES([
|
||||
conf/strongswan.conf.5
|
||||
conf/strongswan.conf.5.head
|
||||
conf/strongswan.conf.5.tail
|
||||
man/ipsec.conf.5
|
||||
man/ipsec.secrets.5
|
||||
src/charon-cmd/charon-cmd.8
|
||||
|
|
|
|||
Loading…
Reference in New Issue