W rzeczywistości brak odpowiedzi podanej przez użytkownika2000606 prowadzi do sukcesu.
Wiadomości HTTP wysyłane do ASA różnią się w zależności od sposobu wyboru grupy, a bramy VPN mogą być wybredne.
To jest moje podstawowe wezwanie do openconnect
openconnect -v --printcookie --dump-http-traffic \
--passwd-on-stdin \
-u johnsmith \
vpn.ssl.mydomain.tld
Wydanie tego polecenia i podanie mojej żądanej grupy VPN po wyświetleniu monitu powoduje następującą rozmowę HTTP (załączyłem tylko pozornie istotne części dokumentów 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
Zwróć uwagę na group-select
-groups i że wszystkie żądania są POST / HTTP/1.1
. Ten sam rezultat osiąga się przez zapewnienie --authgroup AnyConnect-MyGroup
podstawowego połączenia z openconnect
.
Podczas używania -g AnyConnect-MyGroup
zamiast --authgroup AnyConnect-MyGroup
dzieje się:
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>
Zauważ, że tym razem nie mówimy do serwera, group-select
ale po prostu wciskamy nazwę naszej grupy group-access
i żądanie HTTP. Ten sam negatywny wynik jest wywoływany przy dodawaniu nazwy grupy do adresu bramy, tj. Przy użyciu vpn.ssl.mydomain.tld/AnyConnect-MyGroup
jako ostatniego wiersza podstawowego połączenia z openconnect
.