Ладно, прежде чем слишком радоваться, расскажу про свой конкретный кейс, который может отличаться от вашего и потребовать правок в некоторых компонентах аутентификации.
Я начал этим заниматься, потому что хотел иметь возможность отправлять диагностические устройства, к которым у меня может не быть прямого доступа в удалённых сетях. Чтобы обойти эту проблему, я подумал, что раз у меня уже настроен удалённый VPN (L2TP) на шлюзе, то если мне удастся заставить диагностические устройства туннелироваться в мою сеть с удалённого сайта, проблема решена.
Сервер: Unifi USG - удалённый VPN - L2TP - аутентификация RADIUS через 2012 R2
Клиент: свежий экземпляр Ubuntu 16.04 на EC2 AWS с установленными strongswan и xl2tpd.
USG:
USG Radius:
2012 R2 NPS Policy - Network Policy - Constraints - Authentication Methods:
Потратил пару дней на это. Ни один из туториалов даже близко не подходил. В смысле, были в районе стадиона, но почти на парковке.
Ссылка, которую разместил @Chatelier, реально меня приблизила к решению и помогла довести настройку до ума на основе отладочных логов для завершения туннеля. Основная часть проблем возникает из-за несоответствия параметров фазы 1/2 по ключевым настройкам. Если посмотреть на соответствующие файлы на вашем USG, станет ясно, насколько далеко расхождения у параметров в большинстве гайдов и сколько компонентов просто отсутствуют, хотя есть на стороне USG (ipsec/xl2tpd/ppp).
/etc/ipsec.conf — конфигурация:
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
nat_traversal=yes
protostack=netkey
conn L2TP-PSK
authby=secret
pfs=no
auto=start
keyexchange=ikev1
keyingtries=3
dpddelay=15
dpdtimeout=45
dpdaction=clear
rekey=no
ikelifetime=3600
keylife=3600
type=transport
# Замените ниже на ваш локальный IP (частный, натский IP тоже подходит)
left=[local.private.ip]
leftprotoport=17/1701
# Замените IP на IP вашего VPN-сервера
right=[server.public.ip]
rightprotoport=17/%any
ike=aes128-sha1-modp2048,aes256-sha1-modp4096,aes128-sha1-modp1536,aes256-sha1-modp2048,aes128-sha1-modp1024,aes256-sha1-modp1536,aes256-sha1-modp1024,aes256-sha1,3des-sha1-modp1024,3des-sha1!
esp=aes128-sha1-modp2048,aes256-sha1-modp4096,aes128-sha1-modp1536,aes256-sha1-modp2048,aes128-sha1-modp1024,aes256-sha1-modp1536,aes256-sha1-modp1024,aes128-sha1,aes256-sha1,3des-sha1!
/etc/ipsec.secret
[client.private.ip] [public.server.ip] : PSK "[remote.vpn.psk]"
/etc/xl2tpd/xl2tpd.conf
[lac vpn-connection]
lns = [server.public.ip]
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
/etc/ppp/options.l2tpd.client
ipcp-accept-local
ipcp-accept-remote
noccp
refuse-eap
refuse-chap
noauth
idle 1800
mtu 1410
mru 1410
defaultroute
usepeerdns
debug
logfile /var/log/xl2tpd.log
connect-delay 5000
proxyarp
name [ad.user.login]
password [ad.user.password]
По пути было много проблем. Сначала я ставил в параметре right= в /etc/ipsec.conf fqdn вместо IP. Поскольку на сервере не было leftid, установленного на fqdn, рукопожатия не происходило, даже если я ставил rightid на fqdn в клиенте.
Ещё одна проблема — ошибки аутентификации (боже, их было много), но не на уровне логина и пароля, а именно в методе аутентификации. Тут очень помогло добавление "refuse-eap" и "refuse-chap" в /etc/ppp/options.l2tpd.client. В одном из гайдов сказано, что нельзя напрямую указать require mschap-v2, нужно как бы направлять клиента и сервер туда, отказываясь от eap и chap.
Важно: не ограничивайтесь просмотром логов только на клиенте при отладке, проверяйте все компоненты — сервер, RADIUS и все промежуточные звенья. Никогда не знаешь, откуда придёт идея, где найдёшь подсказку.
Сейчас, если я перезапускаю клиента, он сам дотягивается до фазы 1 туннеля без участия пользователя. Но чтобы начать ppp, всё ещё нужно выполнить команду:
echo "c vpn-connection" | sudo tee /var/run/xl2tpd/l2tp-control
После инициации ppp нужно добавить маршрут к серверной сети:
sudo ip route add 10.0.0.0/8 via [vpn.default.gateway] dev ppp0
Как только туннель поднят, можно убрать все debug-строки из конфигураций, потому что с включённым отладочным логом в syslog просто невыносимо громко.
PPP-конфигурация и на клиенте, и на USG настроена с тайм-аутом idle 30 минут — похоже, что при отсутствии активности туннель разрывается (отправляется сигнал завершения клиенту). Не уверен, не отменяет ли это серверное значение настройка на клиенте. В GUI нет опции для этого, возможно, нужно лезть в CLI и менять вручную через config.gateway.json на контроллере. Либо просто заставить клиент периодически пинговать VPN-шлюз, чтобы поддерживать связь. Мне кажется, есть более правильный способ, когда трафика нет, но я только вчера запустил туннель и глазам нужен отдых.
Надеюсь, это поможет или направит вас в правильное русло.
