「ipsec.conf」- IPsec的配置和连接

  CREATED BY JENKINSBOT

配置文件描述

可选的ipsec.conf文件指定了strongSwan IPsec子系统的大多数配置和控制信息。 主要的例外是身份验证的机密;见ipsec.secrets(5)。其内容不是安全敏感的。

该文件是一个文本文件,由一个或多个部分组成。空格后跟“#”后跟任何到行末尾是注释,而被忽略,空行不包含在部分内。

包含include和文件名的行(由空格分隔)将替换为该文件的内容。 如果文件名不是完整路径名,则认为它与包含包含文件的目录相关。 这种包含可以嵌套。 可能只提供一个文件名,它可能不包含空格,但它可能包含shell通配符(参见sh(1));例如:

	include ipsec.*.conf

包含工具的目的主要是为了使连接或连接集的信息与主配置文件分开。这允许更改这些连接描述,将其复制到所涉及的其他安全网关等,而不必经常从配置文件中提取它们然后将它们插回到配置文件中。还要注意,还允许将“单个逻辑部分”(例如连接描述)分成“几个实际部分”的参数(如下所述)。

部分如下形式的一行开头:

	**type name**

其中type表示后面的部分类型,name是一个任意名称,用于区分该部分与相同类型的部分。 以空格开头的所有后续非空行都是该部分的一部分。 合并具有相同名称的相同类型的部分。

部分内的行通常是形式

	**parameter=value**

(注意前面的强制空格)。在“=”的两侧可以有空白区域。参数名称特定于部分类型。

空值表示参数的系统默认值(如果有的话),即它大致相当于完全省略参数行。这可能有助于清除从%default部分继承的设置或通过参数(参见下文)。value可以包含单个空格(额外的空格减少到一个空格)。要保留写入的空格,请将整个值括在双引号(”)中;在这样的值中,双引号本身可以通过在它们前面添加”\“字符进行转义。双引号字符串可以跨越多行,通过用”\“字符结束行。(后续的行不必以空格开头,因为它将被保留)。此外,以下控制字符可以用双引号字符串编码:\n, \r, \t, \b, \f。

数值被指定为“整数”(数字序列)或“小数”(数字序列可选地后跟“.”和另一个数字序列)。

目前有一个参数可用于任何类型的部分:

	**also** 该参数的值是部分名;该部分的参数由当前部分继承。当前节中的参数始终覆盖继承的参数,即also跟在它们后面。指定的部分必须存在,且必须具有相同的部分类型;在当前部分之前或之后定义都可以,则不会。允许嵌套,并且单个部分中可能存在多个also(引用部分中的参数将按照这些参数的顺序继承和覆盖)。

名称为%default的节指定相同类型的节的默认值。这其中的所有参数都由该类型的所有其他部分继承。

目前有三种类型的部分:config部分指定IPsec的一般配置信息;conn部分指定IPsec连接;而ca部分指定证书颁发机构的特殊属性。

「CONFIG」部分

目前,IPsec软件已知的唯一config部分是名为setup的config部分,即config setup,其中包含软件启动时使用的信息。在config setup部分中当前接受的参数名称为:

cachecrls = yes | no
如果启用,通过HTTP或LDAP获取的证书吊销列表(CRL)将在/etc/ipsec.d/crls/中缓存,在从证书颁发机构的公钥派生的唯一文件名下。

charondebug = <debug list>
应该记录多少charon调试输出。可以指定包含type/level对的逗号分隔列表,例如:dmn 3,ike 1,net -1。可接受的type值有:dmn,mgr,ike,chd,job,cfg,knl,net,asn,enc,lib,esp,tls,tnc,imc,imv,pts;可接受的level由:-1,0,1,2,3,4(silent, audit, control, controlmore, raw, private)。 默认情况下,所有type的level都设置为1。 有关更多灵活性,请参阅strongswan.conf(5)中的「LOGGER CONFIGURATION」部分。

strictcrlpolicy = yes | ifuri | no
定义是否必须有新的CRL才能使基于RSA签名的对等身份验证成功。IKEv2另外识别ifuri,如果至少定义了一个CRL URI则为yes,如果没有知道URI则为no。

uniqueids = yes | no | never | replace | keep
特定参与者ID是否应该保持唯一,任何新的IKE_SA使用被认为替换使用该ID的所有旧ID的ID;可接受的值是yes(默认值),no,never。 参与者ID通常是唯一的,因此使用相同ID的新IKE_SA几乎总是用于替换旧ID。 no和never之间的区别在于,如果选项为no,守护程序将在接收INITIAL_CONTACT通知时替换旧的IKE_SAs,但如果从未配置,则将忽略这些通知。 守护进程还接受与yes相同的值replace,并且值保持拒绝新的IKE_SA设置并保持先前建立的副本。

「CONN」部分

conn部分包含连接规范,定义使用IPsec进行的网络连接。给定的name是任意的,用于标识连接。 这是一个简单的例子:

	conn snt
		left=192.168.0.1
		leftsubnet=10.1.0.0/16
		right=192.168.0.2
		rightsubnet=10.1.0.0/16
		keyingtries=%forever
		auto=add

关于术语的说明:有两种通信方式:用户IP数据包的传输;用于键控,密钥更新和一般控制的网关到网关协商。控制连接的路径在IKEv1中称为“ISAKMP SA”,在IKEv2协议中称为“IKE SA”。正在协商的内核级数据路径称为“IPsec SA”或“Child SA”。 strongSwan之前使用了两个独立的键控守护进程,pluto和charon。本手册不再讨论pluto选项,而只讨论自StrongSwan 5.0同时支持IKEv1和IKEv2的charon。

为了避免对配置文件进行微不足道的编辑以适应连接中涉及的每个系统,连接规范是按照左右参与者的方式编写的,而不是根据本地和远程方式编写的。哪个参与者被认为是左或右是任意的;对于每个连接描述,尝试确定本地端点是否应该充当左端点或右端点。这是通过将为两个端点定义的IP地址与分配给本地网络接口的IP地址进行匹配来完成的。如果找到匹配,则匹配的角色(左或右)将被视为本地角色。如果在启动期间未找到匹配项,则将左侧视为本地匹配项。这允许在两端使用相同的连接规范。有些情况下没有对称性;一个很好的约定是左侧用于本地侧,右侧用于远侧(第一个字母是一个很好的助记符)。

许多参数涉及一个参与者或另一个参与者;这里仅列出左边的那些,但是名称以left开头的每个参数都有一个right对应物,其描述相同,但左右颠倒。

除非标记为“(必需)”,否则参数是可选的。

「CONN」参数

除非另有说明,否则对于工作连接,通常两端必须完全同意这些参数的值。

also = <name>
引入conn部分<name>

aaa_identity = <id>
定义IKEv2 EAP身份验证期间使用的AAA后端的标识。 如果EAP客户端使用验证服务器标识的方法(例如EAP-TLS),但它与IKEv2网关标识不匹配,则这是必需的。

aggressive = yes | no
是否使用IKEv1 Aggressive或Main Mode(默认值)。

ah = <cipher suites>
用于连接的以逗号分隔的AH算法列表,例如,sha1-sha256-modp1024。 符号是完整性[-dhgroup]。 对于IKEv2,可以在单个提议中包含相同类型的多个算法(由-分隔)。IKEv1仅包含提案中的第一个算法。 只能使用ah或esp关键字,不支持AH+ESP包。

没有默认的AH密码套件,因为默认使用ESP。守护程序将其广泛的默认提议添加到配置的值。 要将其限制为已配置的提议,可以在末尾添加感叹号(!!)。

如果指定了dh-group,则设置CHILD_SA/Quick模式并且重新加密包括单独的Diffie-Hellman交换(有关详细信息,请参阅esp关键字)。

auth = <value>
由pluto IKEv1守护程序使用,它来为ESP加密数据包使用AH完整性保护,但在charon中不支持。关键字ah指定用于AH的完整性保护的算法,但没有加密。不支持AH + ESP捆绑包。

authby = pubkey | rsasig | ecdsasig | psk | secret | never | xauthpsk | xauthrsasig
这两个安全网关应该如何相互验证;可接受的值是:

	* **psk, secret**,用于预共享密钥;
	* **pubkey**,(默认)公钥签名;
	* **rsasig**,RSA数字签名;
	* **ecdsasig**,椭圆曲线DSA签名;
	* **never**,如果永远不会尝试或接受协商,则可以使用never(对于仅有分流的conn非常有用)。
	* **xauthpsk, xauthrsasig**,IKEv1还支持xauthpsk和xauthrsasig值,除了基于”共享机密“或”数字RSA签名“的IKEv1主模式之外,它还将启用扩展认证(XAUTH)。

数字签名在各方面都优于共享机密。

不推荐使用此参数,因为两个对等方不需要就IKEv2中的身份验证方法达成一致。 请改用leftauth参数来定义身份验证方法。

auto = ignore | add | route | start
在IPsec启动时,应该自动完成哪些操作(如果有的话);当前接受的值是add,route,start,ignore(默认值):

	* **add**,加载连接而不启动它。
	* **route**,加载连接并安装内核陷阱。 如果在leftsubnet和rightsubnet之间检测到流量,则建立连接。
	* **start**,加载连接并立即启动。
	* **ignore**,忽略连接。这等于从配置文件中删除连接。仅在本地相关,其他目的不需要就此达成一致。

closeaction = none | clear | hold | restart
定义远程对等方意外关闭CHILD_SA时要采取的操作(有关值的含义,请参阅dpdaction)。 如果对等方使用reauthentication或uniquids检查,则不应使用closeaction,因为这些事件可能在不需要时触发定义的操作。

compress = yes | no
是否建议在连接上进行IPComp压缩内容(链路级压缩对加密数据不起作用,因此要有效,必须在加密前进行压缩);可接受的值是yes和no(默认值)。 值为yes会导致守护程序同时提出压缩和解压缩,并且更喜欢压缩。值为no会阻止守护程序提出或接受压缩。

dpdaction = none | clear | hold | restart
控制”死亡对等检测协议“(DPD,RFC 3706)的使用,其中周期性地发送R_U_THERE通知消息(IKEv1)或空的INFORMATIONAL消息(IKEv2)以检查IPsec对等体的活跃性。值clear,hold,restart都会激活DPD并确定要在超时时执行的操作。使用clear,在连接后关闭,不再采取进一步措施。 hold会安装陷阱策略,该策略将捕获匹配的流量并尝试按需重新协商连接。restart将立即触发尝试重新协商连接。默认值为none,禁用活动发送DPD消息。

dpddelay = 30s | <time>
定义R_U_THERE messages/INFORMATIONAL交换发送给对等体的周期时间间隔。仅在未收到其他流量时才会发送这些流量。在IKEv2中,值0不发送任何其他INFORMATIONAL消息,仅使用标准消息(例如重定密消息)来检测死亡对等体。

dpdtimeout = 150s | <time>
定义超时间隔,之后在不活动的情况下删除与对等体的所有连接。 这仅适用于IKEv1,在IKEv2中应用默认重传超时,因为每个交换用于检测死对等体。

inactivity = <time>
定义超时间隔,如果CHILD_SA未发送或接收任何流量,则关闭CHILD_SA。 在CHILD_SA重新加密期间重置不活动计数器。 这意味着不活动超时必须小于重新加密间隔才能产生任何效果。

eap_identity = <id>
定义客户端用于回复EAP身份请求的身份。如果在EAP服务器上定义,则定义的标识将在EAP身份验证期间用作对等标识。特殊值%identity使用EAP Identity方法向客户端询问EAP身份。 如果未定义,则IKEv2标识将用作EAP标识。

esp = <cipher suites>
用于连接的以逗号分隔的ESP加密/认证算法列表,例如,aes128-sha256。符号是加密完整性[-dhgroup] [-esnmode]。对于IKEv2,可以在单个提议中包含相同类型的多个算法(由-分隔)。 IKEv1仅包含提案中的第一个算法。只能使用ah或esp关键字,不支持AH+ESP包。

默认为aes128-sha256。守护程序将其广泛的默认提议添加到此默认值或配置的值。要将其限制为已配置的提议,可以在末尾添加感叹号(!)。

注意:作为响应者,守护程序默认选择同级也支持的第一个已配置的提议。这可以通过strongswan.conf(5)更改为选择由对等方发送的第一个可接受的提议。为了限制响应者只接受特定的密码套件,可以使用严格的标志(!,感叹号),例如:aes256-sha512-modp4096!

如果指定了dh-group,则CHILD_SA/Quick模式重新加密和初始协商将使用指定的组进行单独的Diffie-Hellman交换。但是,对于IKEv2,使用IKE_SA隐式创建的CHILD_SA的键将始终从IKE_SA的密钥材料派生。因此,此处指定的任何DH组仅在稍后重新生成CHILD_SA或使用单独的CREATE_CHILD_SA交换创建时才适用。因此,建立SA时可能不会立即注意到建议不匹配,但可能会在以后导致重新生成失败。

对于esnmode的有效值是esn和noesn。指定两者协商对等体的扩展序列号支持,默认为noesn。

forceencaps = yes | no
即使没有检测到NAT情况,也强制对ESP数据包进行UDP封装。 这可能有助于克服限制性防火墙。 为了强制对等体封装数据包,NAT检测有效负载是伪造的。

fragmentation = yes | accept | force | no
是否使用IKE分片(根据RFC 7383的专有IKEv1扩展或IKEv2分段)。 可接受的值是yes(默认值),accept,force,no。 如果设置为yes,并且对等体支持它,则超大IKE消息将以片段形式发送。 如果设置为accept,则会向对等方通知对碎片的支持,但守护程序不会以碎片形式发送自己的消息。 如果设置为force(仅支持IKEv1),则初始IKE消息将在必要时进行分段。 最后,将该选项设置为no将禁用宣布对此功能的支持。

请注意,无论此选项的值如何(即使设置为no),始终接受对等方发送的碎片化IKE消息。

ike = <cipher suites>
要使用的以逗号分隔的IKE/ISAKMP SA加密/认证算法列表,例如,aes128-sha256-modp3072。 表示法是encryption-integrity[-prf]-dhgroup。 如果没有给出PRF,则定义的完整性算法用于PRF。 prf关键字与完整性算法相同,但具有prf前缀(例如prfsha1,prfsha256,prfaesxcbc)。

在IKEv2中,可以包括多个算法和提议,例如aes128-aes256-sha1-modp3072-modp2048,3des-sha1-md5-modp1024。

默认为aes128-sha256-modp3072。 守护程序将其广泛的默认提议添加到此默认值或配置的值。 要将其限制为已配置的提议,可以在末尾添加感叹号(!)。

注意:作为响应者,守护程序接受从对等方收到的第一个支持的提议。 为了限制响应者只接受特定的密码套件,可以使用严格的标志(!,感叹号),例如:aes256-sha512-modp4096!

ikedscp = 000000 | <DSCP field>
差分服务字段代码点,用于设置从此连接发送的传出IKE数据包。 该值是一个六位二进制编码字符串,用于定义要设置的Codepoint,如RFC 2474中所定义。

ikelifetime = 3h | <time>
连接的密钥信道(ISAKMP或IKE SA)在重新协商之前应该持续多长时间。 另见下面的EXPIRY/REKEY。

installpolicy = yes | no
决定是否由charon守护程序为给定连接在内核中安装了IPsec策略。 和平合作,例如 使用想要控制内核策略的Mobile IPv6守护程序mip6d。 可接受的值是yes(默认值)和no。

keyexchange = ike | ikev1 | ikev2
应该使用哪个密钥交换协议来启动连接。 标有ike的连接在启动时使用IKEv2,但在响应时接受任何协议版本。

keyingtries = 3 | <number> | %forever
在放弃之前,应该进行多少次尝试(整数或永远不变)来协商连接,或替换连接(默认3)。值%forever意味着“永不放弃”。 仅在本地相关,其他目的不需要就此达成一致。

left = <ip address> | <fqdn> | %any | <range> | <subnet>
The IP address of the left participant’s public-network interface or one of several magic values. The value %any (the default) for the local endpoint signifies an address to be filled in (by automatic keying) during negotiation. If the local peer initiates the connection setup the routing table will be queried to determine the correct local IP address. In case the local peer is responding to a connection setup then any IP address that is assigned to a local interface will be accepted.

The prefix % in front of a fully-qualified domain name or an IP address will implicitly set leftallowany=yes.

If %any is used for the remote endpoint it literally means any IP address.

If an FQDN is assigned it is resolved every time a configuration lookup is done. If DNS resolution times out, the lookup is delayed for that time.

To limit the connection to a specific range of hosts, a range ( 10.1.0.0-10.2.255.255 ) or a subnet ( 10.1.0.0/16 ) can be specified, and multiple addresses, ranges and subnets can be separated by commas. While one can freely combine these items, to initiate the connection at least one non-range/subnet is required.

Please note that with the usage of wildcards multiple connection descriptions might match a given incoming connection attempt. The most specific description is used in that case.

leftallowany = yes | no
a modifier for left, making it behave as %any although a concrete IP address or domain name has been assigned.

leftauth = <auth method>
Authentication method to use locally (left) or require from the remote (right) side. Acceptable values are pubkey for public key authentication (RSA/ECDSA), psk for pre-shared key authentication, eap to (require the) use of the Extensible Authentication Protocol in IKEv2, and xauth for IKEv1 eXtended Authentication.

To require a trustchain public key strength for the remote side, specify the key type followed by the minimum strength in bits (for example ecdsa-384 or rsa-2048-ecdsa-256). To limit the acceptable set of hashing algorithms for trustchain validation, append hash algorithms to pubkey or a key strength definition (for example pubkey-sha256-sha512, rsa-2048-sha256-sha384-sha512, or rsa-2048-sha256-ecdsa-256-sha256-sha384). Unless disabled in strongswan.conf(5), or explicit IKEv2 signature constraints are configured (see below), such key types and hash algorithms are also applied as constraints against IKEv2 signature authentication schemes used by the remote side.

If both peers support RFC 7427 (“Signature Authentication in IKEv2”) specific hash algorithms to be used during IKEv2 authentication may be configured. The syntax is the same as above, but with ike: prefix. For example, with ike:pubkey-sha384-sha256 a public key signature scheme with either SHA-384 or SHA-256 would get used for authentication, in that order and depending on the hash algorithms supported by the peer. If no specific hash algorithms are configured, the default is to prefer an algorithm that matches or exceeds the strength of the signature key. If no constraints with ike: prefix are configured any signature scheme constraint (without ike: prefix) will also apply to IKEv2 authentication, unless this is disabled in strongswan.conf(5).

To use or require RSASSA-PSS signatures use rsa/pss instead of rsa as in e.g. ike:rsa/pss-sha256. If pubkey or rsa constraints are configured RSASSA-PSS signatures will only be used/accepted if enabled in strongswan.conf(5).

For eap, an optional EAP method can be appended. Currently defined methods are eap-aka, eap-gtc, eap-md5, eap-mschapv2, eap-peap, eap-sim, eap-tls, eap-ttls, eap-dynamic, and eap-radius. Alternatively, IANA assigned EAP method numbers are accepted. Vendor specific EAP methods are defined in the form eap-type-vendor (e.g. eap-7-12345). To specify signature and trust chain constraints for EAP-(T)TLS, append a colon to the EAP method, followed by the key type/size and hash algorithm as discussed above. For xauth, an XAuth authentication backend can be specified, such as xauth-generic or xauth-eap. If XAuth is used in leftauth, Hybrid authentication is used. For traditional XAuth authentication, define XAuth in lefauth2.

leftauth2 = <auth method>
Same as leftauth, but defines an additional authentication exchange. In IKEv1, only XAuth can be used in the second authentication round. IKEv2 supports multiple complete authentication rounds using “Multiple Authentication Exchanges” defined in RFC 4739. This allows, for example, separated authentication of host and user.

leftca = <issuer dn> | %same
the distinguished name of a certificate authority which is required to lie in the trust path going from the left participant’s certificate up to the root certification authority. %same means that the value configured for the right participant should be reused.

leftca2 = <issuer dn> | %same
Same as leftca, but for the second authentication round (IKEv2 only).

leftcert = <path>
the path to the left participant’s X.509 certificate. The file can be encoded either in PEM or DER format. OpenPGP certificates are supported as well. Both absolute paths or paths relative to /etc/ipsec.d/certs are accepted. By default leftcert sets leftid to the distinguished name of the certificate’s subject. The left participant’s ID can be overridden by specifying a leftid value which must be certified by the certificate, though.
A value in the form %smartcard[<slot nr>[@<module>]]:<keyid> defines a specific certificate to load from a PKCS#11 backend for this connection. See ipsec.secrets(5) for details about smartcard definitions. leftcert is required only if selecting the certificate with leftid is not sufficient, for example if multiple certificates use the same subject.
Multiple certificate paths or PKCS#11 backends can be specified in a comma separated list. The daemon chooses the certificate based on the received certificate requests if possible before enforcing the first.

leftcert2 = <path>
Same as leftcert, but for the second authentication round (IKEv2 only).

leftcertpolicy = <OIDs>
Comma separated list of certificate policy OIDs the peer’s certificate must have. OIDs are specified using the numerical dotted representation.

leftdns = <servers>
Comma separated list of DNS server addresses to exchange as configuration attributes. On the initiator, a server is a fixed IPv4/IPv6 address, or %config4/%config6 to request attributes without an address. On the responder, only fixed IPv4/IPv6 addresses are allowed and define DNS servers assigned to the client.

leftfirewall = yes | no
whether the left participant is doing forwarding-firewalling (including masquerading) using iptables for traffic from leftsubnet, which should be turned off (for traffic to the other subnet) once the connection is established; acceptable values are yes and no (the default). May not be used in the same connection description with leftupdown. Implemented as a parameter to the default ipsec _updown script. See notes below. Relevant only locally, other end need not agree on it.

If one or both security gateways are doing forwarding firewalling (possibly including masquerading), and this is specified using the firewall parameters, tunnels established with IPsec are exempted from it so that packets can flow unchanged through the tunnels. (This means that all subnets connected in this manner must have distinct, non-overlapping subnet address blocks.) This is done by the default ipsec _updown script.

In situations calling for more control, it may be preferable for the user to supply his own updown script, which makes the appropriate adjustments for his system.

leftgroups = <group list>
a comma separated list of group names. If the leftgroups parameter is present then the peer must be a member of at least one of the groups defined by the parameter.

leftgroups2 = <group list>
Same as leftgroups, but for the second authentication round defined with leftauth2.

lefthostaccess = yes | no
inserts a pair of INPUT and OUTPUT iptables rules using the default ipsec _updown script, thus allowing access to the host itself in the case where the host’s internal interface is part of the negotiated client subnet. Acceptable values are yes and no (the default).

leftid = <id>
how the left participant should be identified for authentication; defaults to left or the subject of the certificate configured with leftcert. If leftcert is configured the identity has to be confirmed by the certificate.

Can be an IP address, a fully-qualified domain name, an email address or a Distinguished Name for which the ID type is determined automatically and the string is converted to the appropriate encoding. The rules for this conversion are described in IDENTITY PARSING below.

In certain special situations the identity parsing above might be inadequate or produce the wrong result. Examples are the need to encode a FQDN as KEY_ID or the string parser being unable to produce the correct binary ASN.1 encoding of a certificate’s DN. For these situations it is possible to enforce a specific identity type and to provide the binary encoding of the identity. To do this a prefix may be used, followed by a colon (:). If the number sign (#) follows the colon, the remaining data is interpreted as hex encoding, otherwise the string is used as is as the identification data. Note: The latter implies that no conversion is performed for non-string identities. For example, ipv4:10.0.0.1 does not create a valid ID_IPV4_ADDR IKE identity, as it does not get converted to binary 0x0a000001. Instead, one could use ipv4:#0a000001 to get a valid identity, but just using the implicit type with automatic conversion is usually simpler. The same applies to the ASN.1 encoded types. The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns, asn1dn, asn1gn and keyid. Custom type prefixes may be specified by surrounding the numerical type value by curly brackets.

For IKEv2 and rightid the prefix % in front of the identity prevents the daemon from sending IDr in its IKE_AUTH request and will allow it to verify the configured identity against the subject and subjectAltNames contained in the responder’s certificate (otherwise it is only compared with the IDr returned by the responder). The IDr sent by the initiator might otherwise prevent the responder from finding a config if it has configured a different value for leftid.

leftid2 = <id>
identity to use for a second authentication for the left participant (IKEv2 only); defaults to leftid.

leftikeport = <port>
UDP port the left participant uses for IKE communication. If unspecified, port 500 is used with the port floating to 4500 if a NAT is detected or MOBIKE is enabled. Specifying a local IKE port different from the default additionally requires a socket implementation that listens on this port.

leftprotoport = <protocol>/<port>
restrict the traffic selector to a single protocol and/or port. This option is now deprecated, protocol/port information can be defined for each subnet directly in leftsubnet.

leftsigkey = <raw public key> | <path to public key>
the left participant’s public key for public key signature authentication, in PKCS#1 format using hex (0x prefix) or base64 (0s prefix) encoding. With the optional dns: or ssh: prefix in front of 0x or 0s, the public key is expected to be in either the RFC 3110 (not the full RR, only RSA key part) or RFC 4253 public key format, respectively. Also accepted is the path to a file containing the public key in PEM, DER or SSH encoding. Both absolute paths or paths relative to /etc/ipsec.d/certs are accepted.

leftsendcert = never | no | ifasked | always | yes
Accepted values are never or no, always or yes, and ifasked (the default), the latter meaning that the peer must send a certificate request payload in order to get a certificate in return.

leftsourceip = %config4 | %config6 | <ip address>
Comma separated list of internal source IPs to use in a tunnel, also known as virtual IP. If the value is one of the synonyms %config, %cfg, %modeconfig, or %modecfg, an address (from the tunnel address family) is requested from the peer. With %config4 and %config6 an address of the given address family will be requested explicitly. If an IP address is configured, it will be requested from the responder, which is free to respond with a different address.

rightsourceip = %config | <network>/<netmask> | <from>-<to> | %poolname
Comma separated list of internal source IPs to use in a tunnel for the remote peer. If the value is %config on the responder side, the initiator must propose an address which is then echoed back. Also supported are address pools expressed as network/netmask and from-to or the use of an external IP address pool using %poolname, where poolname is the name of the IP address pool used for the lookup.

leftsubnet = <ip subnet>[[<proto/port>]][,…]
private subnet behind the left participant, expressed as network/netmask; if omitted, essentially assumed to be left/32, signifying that the left end of the connection goes to the left participant only. Configured subnets of the peers may differ, the protocol narrows it to the greatest common subnet. In IKEv1, this may lead to problems with other implementations, make sure to configure identical subnets in such configurations. IKEv2 supports multiple subnets separated by commas. IKEv1 only interprets the first subnet of such a definition, unless the Cisco Unity extension plugin is enabled. This is due to a limitation of the IKEv1 protocol, which only allows a single pair of subnets per CHILD_SA. So to tunnel several subnets a conn entry has to be defined and brought up for each pair of subnets.

The optional part after each subnet enclosed in square brackets specifies a protocol/port to restrict the selector for that subnet.

Examples: leftsubnet=10.0.0.1[tcp/http],10.0.0.2[6/80] or leftsubnet=fec1::1[udp],10.0.0.0/16[/53]. Instead of omitting either value %any can be used to the same effect, e.g. leftsubnet=fec1::1[udp/%any],10.0.0.0/16[%any/53].

If the protocol is icmp or ipv6-icmp the port is interpreted as ICMP message type if it is less than 256 or as type and code if it is greater or equal to 256, with the type in the most significant 8 bits and the code in the least significant 8 bits.

The port value can alternatively take the value %opaque for RFC 4301 OPAQUE selectors, or a numerical range in the form 1024-65535. None of the kernel backends currently supports opaque or port ranges and uses %any for policy installation instead.

Instead of specifying a subnet, %dynamic can be used to replace it with the IKE address, having the same effect as omitting leftsubnet completely. Using %dynamic can be used to define multiple dynamic selectors, each having a potentially different protocol/port definition.

leftupdown = <path>
what “updown” script to run to adjust routing and/or firewalling when the status of the connection changes (default ipsec _updown). May include positional parameters separated by white space (although this requires enclosing the whole string in quotes); including shell metacharacters is unwise. Relevant only locally, other end need not agree on it. Charon uses the updown script to insert firewall rules only, since routing has been implemented directly into the daemon.

lifebytes = <number>
the number of bytes transmitted over an IPsec SA before it expires.

lifepackets = <number>
the number of packets transmitted over an IPsec SA before it expires.

lifetime = 1h | <time>
how long a particular instance of a connection (a set of encryption/authentication keys for user packets) should last, from successful negotiation to expiry; acceptable values are an integer optionally followed by s (a time in seconds) or a decimal number followed by m, h, or d (a time in minutes, hours, or days respectively) (default 1h, maximum 24h). Normally, the connection is renegotiated (via the keying channel) before it expires (see margintime). The two ends need not exactly agree on lifetime, although if they do not, there will be some clutter of superseded connections on the end which thinks the lifetime is longer. Also see EXPIRY/REKEY below.

marginbytes = <number>
how many bytes before IPsec SA expiry (see lifebytes) should attempts to negotiate a replacement begin.

marginpackets = <number>
how many packets before IPsec SA expiry (see lifepackets) should attempts to negotiate a replacement begin.

margintime = 9m | <time>
how long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin; acceptable values as for lifetime (default 9m). Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY below.

mark = <value>[/<mask>]
sets an XFRM mark on the inbound policy and outbound IPsec SA and policy. If the mask is missing then a default mask of 0xffffffff is assumed. The special value %unique assigns a unique value to each newly created IPsec SA. To additionally make the mark unique for each IPsec SA direction (in/out) the special value %unique-dir may be used.

mark_in = <value>[/<mask>]
sets an XFRM mark on the inbound policy (not on the SA). If the mask is missing then a default mask of 0xffffffff is assumed.

mark_out = <value>[/<mask>]
sets an XFRM mark on the outbound IPsec SA and policy. If the mask is missing then a default mask of 0xffffffff is assumed.

mobike = yes | no
enables the IKEv2 MOBIKE protocol defined by RFC 4555. Accepted values are yes (the default) and no. If set to no, the charon daemon will not actively propose MOBIKE as initiator and ignore the MOBIKE_SUPPORTED notify as responder.

modeconfig = push | pull
defines which mode is used to assign a virtual IP. Accepted values are push and pull (the default). Push mode is currently not supported with IKEv2. The setting must be the same on both sides.

reauth = yes | no
whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1, reauthentication is always done. In IKEv2, a value of no rekeys without uninstalling the IPsec SAs, a value of yes (the default) creates a new IKE_SA from scratch and tries to recreate all IPsec SAs.

rekey = yes | no
whether a connection should be renegotiated when it is about to expire; acceptable values are yes (the default) and no. The two ends need not agree, but while a value of no prevents charon from requesting renegotiation, it does not prevent responding to renegotiation requested from the other end, so no will be largely ineffective unless both ends agree on it. Also see reauth.

rekeyfuzz = 100% | <percentage>
maximum percentage by which marginbytes, marginpackets and margintime should be randomly increased to randomize rekeying intervals (important for hosts with many connections); acceptable values are an integer, which may exceed 100, followed by a `%’ (defaults to 100%). The value of marginTYPE, after this random increase, must not exceed lifeTYPE (where TYPE is one of bytes, packets or time). The value 0% will suppress randomization. Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY below.

replay_window = -1 | <number>
The IPsec replay window size for this connection. With the default of -1 the value configured with charon.replay_window in strongswan.conf(5) is used. Larger values than 32 are supported using the Netlink backend only, a value of 0 disables IPsec replay protection.

reqid = <number>
sets the reqid for a given connection to a pre-configured fixed value.

sha256_96 = no | yes
HMAC-SHA-256 is used with 128-bit truncation with IPsec. For compatibility with implementations that incorrectly use 96-bit truncation this option may be enabled to configure the shorter truncation length in the kernel. This is not negotiated, so this only works with peers that use the incorrect truncation length (or have this option enabled).

tfc = <value>
number of bytes to pad ESP payload data to. Traffic Flow Confidentiality is currently supported in IKEv2 and applies to outgoing packets only. The special value %mtu fills up ESP packets with padding to have the size of the MTU.

type = tunnel | transport | transport_proxy | passthrough | drop
连接的类型;当前接受的值:

	* **tunnel**(默认值),表示主机到主机,主机到子网,子网到子网的隧道;
	* **transport**,表示主机到主机的传输方式;
	* **transport_proxy**,表示特殊的Mobile IPv6传输代理模式;
	* **passthrough**,表示根本不应该进行IPsec处理;
	* **drop**,表示应丢弃数据包。

xauth = client | server
specifies the role in the XAuth protocol if activated by authby=xauthpsk or authby=xauthrsasig. Accepted values are server and client (the default).

xauth_identity = <id>
defines the identity/username the client uses to reply to an XAuth request. If not defined, the IKEv1 identity will be used as XAuth identity.

CONN PARAMETERS: IKEv2 MEDIATION EXTENSION

The following parameters are relevant to IKEv2 Mediation Extension operation only.

mediation = yes | no
whether this connection is a mediation connection, ie. whether this connection is used to mediate other connections. Mediation connections create no child SA. Acceptable values are no (the default) and yes.

mediated_by = <name>
the name of the connection to mediate this connection through. If given, the connection will be mediated through the named mediation connection. The mediation connection must set mediation=yes.

me_peerid = <id>
ID as which the peer is known to the mediation server, ie. which the other end of this connection uses as its leftid on its connection to the mediation server. This is the ID we request the mediation server to mediate us with. If me_peerid is not given, the rightid of this connection will be used as peer ID.

CA SECTIONS

These are optional sections that can be used to assign special parameters to a Certification Authority (CA). Because the daemons automatically import CA certificates from /etc/ipsec.d/cacerts, there is no need to explicitly add them with a CA section, unless you want to assign special parameters (like a CRL) to a CA.

also = <name>
includes ca section <name>.

auto = ignore | add
currently can have either the value ignore (the default) or add.

cacert = <path>
defines a path to the CA certificate either relative to /etc/ipsec.d/cacerts or as an absolute path.
A value in the form %smartcard[<slot nr>[@<module>]]:<keyid> defines a specific CA certificate to load from a PKCS#11 backend for this CA. See ipsec.secrets(5) for details about smartcard definitions.

crluri = <uri>
defines a CRL distribution point (ldap, http, or file URI)

crluri1
synonym for crluri.

crluri2 = <uri>
defines an alternative CRL distribution point (ldap, http, or file URI)

ocspuri = <uri>
defines an OCSP URI.

ocspuri1
synonym for ocspuri.

ocspuri2 = <uri>
defines an alternative OCSP URI.

certuribase = <uri>
defines the base URI for the Hash and URL feature supported by IKEv2. Instead of exchanging complete certificates, IKEv2 allows one to send an URI that resolves to the DER encoded certificate. The certificate URIs are built by appending the SHA1 hash of the DER encoded certificates to this base URI.

IDENTITY PARSING

The type and binary encoding of identity strings specified in leftid are detected as follows:

· If the string value contains an equal sign (=) it is assumed to be a Distinguished Name, with RDNs separated by commas (,) or slashes (/ – the string must start with a slash to use this syntax). An attempt is made to create a binary ASN.1 encoding from this string. If that fails the type is set to KEY_ID with the literal string value adopted as encoding.

· If the string value contains an @ the type depends on the position of that character:

· If the string begins with @# the type is set to KEY_ID and the string following that prefix is assumed to be the hex-encoded binary value of the identity.

· If the string begins with @@ the type is set to USER_FQDN and the encoding is the literal string after that prefix.

· If the string begins with @ the type is set to FQDN and the encoding is the literal string after that prefix.

· All remaining strings containing an @ are assumed to be of type USER_FQDN/RFC822 with the literal string value as encoding.

· If the value does not contain any @ or = characters it is parsed as follows:

· If the value is an empty string, or equals %any[6], 0.0.0.0, ::, or * the type is set to ID_ANY, which matches any other identity.

· If the value contains a colon (:) it is assumed to be an IPv6 address. But if parsing the address and converting it to its binary encoding fails the type is set to KEY_ID and the encoding is the literal value.

· For all other strings an attempt at parsing them as IPv4 addresses is made. If that fails the type is set to FQDN and the literal value is adopted as encoding (this is where domain names and simple names end up).

SA EXPIRY/REKEY

	The IKE SAs and IPsec SAs negotiated by the daemon can be configured to expire after a specific amount of time. For IPsec SAs this can also happen after a specified number of transmitted packets or transmitted bytes. The following settings can be used to configure this:
	Setting         Default   Setting         Default
	──────────────────────────────────────────────────
	IKE SA                    IPsec SA
	 ikelifetime         3h    lifebytes            -
							   lifepackets          -
							   lifetime            1h

Rekeying

IKE SAs as well as IPsec SAs can be rekeyed before they expire. This can be configured using the following settings:

	Setting        Default   Setting           Default
	───────────────────────────────────────────────────
	IKE and IPsec SA         IPsec SA
	 margintime         9m    marginbytes            -
							  marginpackets          -

Randomization

To avoid collisions the specified margins are increased randomly before subtracting them from the expiration limits (see formula below). This is controlled by the rekeyfuzz setting:

	Setting       Default
	──────────────────────
	IKE and IPsec SA
	 rekeyfuzz       100%
	Randomization can be disabled by setting rekeyfuzz to 0%.

Formula

The following formula is used to calculate the rekey time of IPsec SAs:

	 rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))
	It applies equally to IKE SAs and byte and packet limits for IPsec SAs.

Example

	Let's consider the default configuration:
			   lifetime = 1h
			   margintime = 9m
			   rekeyfuzz = 100%
	From the formula above follows that the rekey time lies between:
			   rekeytime_min = 1h - (9m + 9m) = 42m
			   rekeytime_max = 1h - (9m + 0m) = 51m
	Thus, the daemon will attempt to rekey the IPsec SA at a random time between 42 and 51 minutes after establishing the SA. Or, in other words, between 9 and 18 minutes before the SA expires.

Notes

· Since the rekeying of an SA needs some time, the margin values must not be too low.

	·      The value margin... + margin... * rekeyfuzz must not exceed the original limit. For example, specifying margintime = 30m in the default configuration is a bad idea as there is a chance that the rekey time equals zero and, thus, rekeying gets disabled.

相关文件

/etc/ipsec.conf
/etc/ipsec.d/aacerts
/etc/ipsec.d/acerts
/etc/ipsec.d/cacerts
/etc/ipsec.d/certs
/etc/ipsec.d/crls

相关手册

strongswan.conf(5), ipsec.secrets(5), ipsec(8)

更新日志

11/05/2018 创建文章