此内容没有您所选择的语言版本。
2.7.8. Road Warrior Access VPN Using Libreswan and XAUTH with X.509
Libreswan offers a method to natively assign
IP address and DNS information to roaming VPN clients as the connection is established by using the XAUTH IPsec extension. Extended authentication (XAUTH) can be deployed using PSK or X.509 certificates. Deploying using X.509 is more secure. Client certificates can be revoked by a certificate revocation list or by Online Certificate Status Protocol (OCSP). With X.509 certificates, individual clients cannot impersonate the server. With a PSK, also called Group Password, this is theoretically possible.
XAUTH requires the VPN client to additionally identify itself with a user name and password. For One time Passwords (OTP), such as Google Authenticator or RSA SecureID tokens, the one-time token is appended to the user password.
There are three possible backends for XAUTH:
xauthby=pam- This uses the configuration in
/etc/pam.d/plutoto authenticate the user. Pluggable Authentication Modules (PAM) can be configured to use various backends by itself. It can use the system account user-password scheme, an LDAP directory, a RADIUS server or a custom password authentication module. See the Using Pluggable Authentication Modules (PAM) chapter for more information. xauthby=file- This uses the configuration file
/etc/ipsec.d/passwd(not to be confused with/etc/ipsec.d/nsspassword). The format of this file is similar to the Apache.htpasswdfile and the Apachehtpasswdcommand can be used to create entries in this file. However, after the user name and password, a third column is required with the connection name of theIPsecconnection used, for example when using aconn remoteusersto offer VPN to remote users, a password file entry should look as follows:user1:$apr1$MIwQ3DHb$1I69LzTnZhnCT2DPQmAOK.:remoteusers
NOTE: when using thehtpasswdcommand, the connection name has to be manually added after the user:password part on each line. xauthby=alwaysok- The server will always pretend the XAUTH user and password combination was correct. The client still has to specify a user name and a password, although the server ignores these. This should only be used when users are already identified by X.509 certificates, or when testing the VPN without needing an XAUTH backend.
An example server configuration with X.509 certificates:
conn xauth-rsa
auto=add
authby=rsasig
pfs=no
rekey=no
left=ServerIP
leftcert=vpn.example.com
#leftid=%fromcert
leftid=vpn.example.com
leftsendcert=always
leftsubnet=0.0.0.0/0
rightaddresspool=10.234.123.2-10.234.123.254
right=%any
rightrsasigkey=%cert
modecfgdns1=1.2.3.4
modecfgdns2=8.8.8.8
modecfgdomain=example.com
modecfgbanner="Authorized access is allowed"
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=pam
dpddelay=30
dpdtimeout=120
dpdaction=clear
ike_frag=yes
# for walled-garden on xauth failure
# xauthfail=soft
#leftupdown=/custom/_updown
When
xauthfail is set to soft, instead of hard, authentication failures are ignored, and the VPN is setup as if the user authenticated properly. A custom updown script can be used to check for the environment variable XAUTH_FAILED. Such users can then be redirected, for example, using iptables DNAT, to a “walled garden” where they can contact the administrator or renew a paid subscription to the service.
VPN clients use the
modecfgdomain value and the DNS entries to redirect queries for the specified domain to these specified nameservers. This allows roaming users to access internal-only resources using the internal DNS names.
The
modecfgdns options contain a comma-separated list of internal DNS servers for the client to use for DNS resolution. Optionally, to send a banner text to VPN cliens, use the modecfgbanner option.
If
leftsubnet is not 0.0.0.0/0, split tunneling configuration requests are sent automatically to the client. For example, when using leftsubnet=10.0.0.0/8, the VPN client would only send traffic for 10.0.0.0/8 through the VPN.
On the client, the user has to input a user password, which depends on the backend used. For example:
xauthby=file- The administrator generated the password and stored it in the
/etc/ipsec.d/passwdfile. xauthby=pam- The password is obtained at the location specified in the PAM configuration in the
/etc/pam.d/plutofile. xauthby=alwaysok- The password is not checked and always accepted. Use this option for testing purposes or if you want to ensure compatibility for xauth-only clients.
For more information about XAUTH, see the Extended Authentication within ISAKMP/Oakley (XAUTH) Internet-Draft document.
