Skriptet avslutas med noll, tunneln dyker upp och nästa körning avvisas innan det ens frågar efter ett lösenord. Eller samma kommando fungerar i en terminal och misslyckas från ett schemalagt jobb med felet «händelsen hittades inte» som inte namnger något användbart. Båda är AnyConnect-klientens samtal över standardin som går fel, inte ett nätverksfel. Behandla inloggningen som en skriven fråga och ett svar och felen blir förutsägbara och små.

Varför samma kommando misslyckas inne i ett skript

Klienten läser sina svar från standardin, en rad per fråga, i den ordning som gatewayen begär dem. Allt som ändrar antalet frågor, som en ny banner, en gruppväljare eller en andrafaktor-utmaning, förskjuter varje senare svar en rad. Klienten läser då ett användarnamn där den väntade ett lösenord och rapporterar ett fel som inte pekar på något av dem.

Ett lösenord med ett utropstecken lägger till ett tystare andra fel. Inom dubbla citattecken expanderar skalet det långt innan klienten ser något.

Sätt nyttolasten inom enkla citattecken och tecknet färdas intakt. Det är hela rättelsen, och den förklarar en hel klass av rapporter där samma uppgifter fungerar när de skrivs in och misslyckas när de sparas. Kontrollera vad skalet gjorde innan du kontrollerar gatewayen: skriv ut nyttolasten genom ett omslag som visar de exakta byten och räkna raderna. De flesta av dessa utredningar slutar just där.

Skriv svaren i den ordning klienten frågar

Kör klienten interaktivt en gång och skriv ned varje fråga i ordning. En gruppväljare visas bara när gatewayen publicerar flera profiler, och en bannerfråga visas bara när en är konfigurerad. Svarsfilen måste matcha den gateway du faktiskt pekar på, inte den i dokumentationen.

Bygg sedan filen med exakt den sekvensen, ett svar per rad. Gruppindexet är numret som klienten listar, inte en profils position i ett dokument. Acceptera bannern bara om din gateway skickar en, och lägg till en rad för varje extra fråga som den gatewayen är känd för att ställa. Starta klienten med den icke-interaktiva flaggan så att den förbrukar filen i stället för att vänta på en terminal.

connect vpn.lab.example
0
username
password
y
exit
/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

Samma sekvens kan komma genom ett rör när du helst inte vill ha en fil på disken. Citatreglerna avgör fortfarande om den överlever.

Håll uppgifterna utanför processlistan

Ett argument på kommandoraden är läsbart för varje lokal användare under processens hela livstid, så lösenordet hör hemma i en fil eller ett rör och aldrig i argumentlistan. Gör den filen läsbar bara för kontot som kör skriptet, och radera den när jobbet är klart. På macOS ligger binären oftast på samma sökväg som på Linux, men bekräfta den installerade platsen i stället för att anta den. Ett omslag som testar båda sökvägarna är kortare än incidentrapporten.

printf 'username\npassword\ny\n' | /opt/cisco/anyconnect/bin/vpn -s connect vpn.lab.example

Låt inte skriptet försöka igen i evighet heller. En ändrad banner eller ett lösenord som gick ut under natten förvandlar en fast svarsfil till en återförsöksslinga, och det är den slingan som låser kontot.

Misslyckas en gång, skriv ut klientens egen feltext och avsluta. Ett schemalagt jobb behöver samma genomgång av identitet och tillgänglighet för uppgifterna som alla andra oövervakade uppgifter, eftersom uppgifter som tyst löper ut inte går att skilja från ett avbrott klockan tre på natten.

Bekräfta sessionen innan du litar på slutkoden

Ett anslutet tillstånd bevisar att tunneln finns och inget mer. Testa en resurs som måste vara nåbar genom den innan skriptet börjar med riktigt arbete, och behandla ett fel där som ett annat fel än en misslyckad inloggning. Annars försöker du igen med en helt bra anslutning som helt enkelt inte når sitt mål.

Fråga klienten om dess tillstånd före och efter frånkopplingen, eftersom en inaktuell session kan avvisa nästa anslutning medan skriptet rapporterar framgång.

/opt/cisco/anyconnect/bin/vpn state
/opt/cisco/anyconnect/bin/vpn disconnect

Notera tillståndsutdata bredvid slutkoden, eftersom en kod ensam inte kan skilja en avvisad inloggning från en session som aldrig stängdes. När gatewayen kräver en andra faktor eller ett interaktivt godkännande, sluta skripta det steget och använd i stället mekanismen som klienten stöder. En fast svarsfil är en bekvämlighet för uppgifter du kontrollerar, inte ett sätt att kringgå ett autentiseringssteg du inte kontrollerar. Håll omfånget så smalt och detta förblir ett kort skript.

När en fast svarsfil är fel verktyg

En andra faktor eller en godkännandeförfrågan besegrar mönstret helt, och det är en designgräns, inte en skriptgåta. Använd den mekanism klienten stöder för det steget i stället för att gissa svaret i förväg. En fast fil fungerar bara för uppgifter som är desamma mellan körningar.

Två äldre stilar av uppgifter blandas också ihop med AnyConnect. En vpnc-profil talar ett annat protokoll, och den vill ha gruppnamnet som IPSec-identifierare, därefter en delad grupphemlighet, därefter dina egna kontouppgifter.

Eftersom protokollen skiljer sig kan vpnc inte nå en gateway som bara publicerar AnyConnect-profiler, och det vanliga öppna alternativet för den tjänsten är openconnect med sin anyconnect-protokoll vald. En pcf-fil tillhör den gamla Cisco-klienten och även om värden, gruppnamnet och grupplösenordet kan anges igen i en klient som fortfarande talar Cisco IPsec, flyttas inte filen mellan klienter. En ovanlig port eller ett icke-standardiserat tunnel-läge går vanligtvis förlorat i den flytten. Avgör vilket protokoll gatewayen erbjuder innan du väljer ett verktyg.

Relaterade artiklar