En fait, la non réponse donnée par user2000606 mène au succès.
Les messages HTTP envoyés à l'ASA diffèrent, selon la façon dont vous sélectionnez un groupe et les passerelles VPN peuvent être difficiles à ce sujet.
Ceci est mon appel de base à openconnect
openconnect -v --printcookie --dump-http-traffic \
--passwd-on-stdin \
-u johnsmith \
vpn.ssl.mydomain.tld
Émettre cette commande et fournir mon groupe VPN souhaité après avoir été invité entraîne le chat HTTP suivant (je n'ai inclus que les parties apparemment pertinentes des documents 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
Remarquez les group-select
groupes et que toutes les demandes le sont POST / HTTP/1.1
. Le même résultat est obtenu en fournissant --authgroup AnyConnect-MyGroup
l'appel de base à openconnect
.
Lors de l'utilisation -g AnyConnect-MyGroup
au lieu de --authgroup AnyConnect-MyGroup
ce qui suit se produit:
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>
Notez que cette fois, nous ne le disons pas au serveur, group-select
mais simplement pressons le nom de notre groupe avec group-access
et la requête HTTP. Le même résultat négatif est provoqué lors de l'ajout du nom de groupe à l'adresse de la passerelle, c'est-à-dire en utilisantvpn.ssl.mydomain.tld/AnyConnect-MyGroup
comme dernière ligne de l'appel de base vers openconnect
.