На самом деле, отказ от ответа пользователя 2000606 приводит к успеху.
HTTP-сообщения, отправляемые в ASA, различаются в зависимости от того, как вы выбираете группу, и VPN-шлюзы могут быть разборчивы в этом.
Это мой основной призыв к openconnect
openconnect -v --printcookie --dump-http-traffic \
--passwd-on-stdin \
-u johnsmith \
vpn.ssl.mydomain.tld
Выполнение этой команды и предоставление моей желаемой группы VPN после запроса приводит к следующему HTTP-чату (я включил только, казалось бы, соответствующие части документов XML):
[Certificate error, I tell openconnect to continue]
Me >> ASA: POST / HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld</group-access>
ASA << ME: HTTP/1.1 200 OK
Me >> ASA: POST / HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld/</group-access><group-select>AnyConnect-MyGroup</group-select>
ASA << ME: HTTP/1.1 200 OK
Me >> ASA: POST / HTTP/1.1
[...]<auth><username>johnsmith</username><password>secret</password></auth><group-select>AnyConnect-MyGroup</group-select>
ASA << ME: HTTP/1.1 200 OK
Обратите внимание на группы group-select
и все запросы POST / HTTP/1.1
. Тот же результат достигается путем предоставления --authgroup AnyConnect-MyGroup
базового вызова openconnect
.
При использовании -g AnyConnect-MyGroup
вместо этого --authgroup AnyConnect-MyGroup
происходит следующее:
Me >> ASA: POST /AnyConnect-MyGroup HTTP/1.1
[...]<group-access>https://vpn.ssl.mydomain.tld/AnyConnect-MyGroup</group-access>
ASA << ME: HTTP/1.1 200 OK
[...] <error id="91" param1="" param2="">Invalid host entry. Please re-enter.</error>
Обратите внимание, что на этот раз мы не сообщаем серверу, group-select
а просто сжимаем имя нашей группы с помощью group-access
и HTTP-запрос. Тот же самый отрицательный результат вызывается при добавлении имени группы к адресу шлюза, то есть при использовании vpn.ssl.mydomain.tld/AnyConnect-MyGroup
в качестве последней строки основного вызова openconnect
.