Како да автоматизирате VPN најава што чека токен код

Скрипта што стартува VPN клиент на продавач виси додека не истече времето, а дневникот покажува дека клиентот бара верификациски код што никој не го внел. Лозинката беше доставена, па очигледниот заклучок е дека лозинката е погрешна. Не е. Барањето код е одделен разговор на одделен канал, и вашата скрипта никогаш не го отвори.

Поминете ги петте проверки подолу по ред. Запрете кај првата што ќе не успее, бидејќи секој следен чекор претпоставува дека претходните важат.

Проверка 1: дали клиентот воопшто го чита стандардниот влез?

Тестирајте пред да напишете каква било автоматизација: префрлете лажен таен податок во клиентот низ цевка и гледајте што се случува. Ако го испечати своето барање и потоа чека, не ја чита цевката.

Многу клиенти го отвораат терминалскиот уред директно, или одбиваат да земат таен податок од поток што не е терминал, за да не може залутана цевка да ја протече лозинката. OpenVPN е документираниот исклучок, бидејќи --auth-user-pass зема патека до датотека. Клиентите на продавачи што бараат еднократен код обично немаат еквивалентна опција, и нивното барање чека терминал што вашата скрипта никогаш не го обезбедила.

Проверка 2: дали детскиот процес има терминал?

pty доделува терминал на детето, што ги претвора барањата во читлив излез на кој можете да одговорите по ред.

import pexpect

child = pexpect.spawn("openconnect vpn.example.net", encoding="utf-8", timeout=30)
child.expect("GROUP:")
child.sendline("staff")
child.expect("USERNAME:")
child.sendline("alice")
child.expect("PASSWORD:")
child.sendline(PASSWORD)
child.expect("Connected as", timeout=60)

Низите за барање погоре се илустративни; копирајте го точниот текст што го печати вашиот клиент, вклучително големи и мали букви и интерпункција. Секое очекување носи временско ограничување, а затворено дете фрла исклучок наместо да врати статус, затоа завиткајте ја низата и третирајте го крајот на датотеката како неуспех. Забележете што овој блок не прави: детето умира со скриптата, бидејќи pty не е механизам за одвојување, а disown е вградена наредба на лушпата што не може да стигне до процес што вашата скрипта го создала.

Проверка 3: дали има поддржан неинтерактивен влез?

Скребувањето на екранот се крши при надградби на клиентот, затоа прво барајте документирана опција.

Проверете го излезот од помошта за опција за токен или еднократен код, и проверете дали услугата сѐ уште го прифаќа кодот додаден на полето за лозинка. Онаму каде клиентот чита датотека со акредитиви, дајте му ја датотеката наместо барање:

openvpn --config office.ovpn --auth-user-pass <(printf "%s\n%s\n" "$USER_NAME" "$PASSWORD")

Замената на процеси му дава на клиентот читлива патека на системи што обезбедуваат /dev/fd. Тајниот податок останува таен од гледна точка на клиентот, затоа држете го подалеку од дневници, историја на лушпата и списоци со процеси. Ако клиентот го одбие /dev/fd или ја отвори патеката до акредитивите повеќе од еднаш, напишете вистинска датотека со строги дозволи и избришете ја во истата скрипта.

Проверка 4: дали тунелот ќе ја надживее скриптата?

Стандардно тунелот умира со својот родител, што е спротивно од она што му е потребно на скриптата за подигање.

disown -h помага само кога клиентот сте го стартувале како задача на лушпата, бидејќи ја уредува табелата со задачи на таа лушпа и не може да стигне до процес што вашата скрипта го создала преку pty. Управувачот со услуги е подобар дом за сѐ што мора да се поврзе повторно без надзор, бидејќи го рестартира клиентот и запишува зошто умрел. Во секој случај, очекувајте нов код по секое повторно поврзување: еднократниот токен се троши при првата успешна автентикација.

Гледајте што прави sudo со низата. Барањето лозинка на sudo не е барањето на VPN, и да му одговорите со лозинката на VPN е најчестиот начин инаку правилен ред на очекувања да не успее.

Проверка 5: дали кодот на една личност треба да биде во скрипта?

Ова е проверката што луѓето ја прескокнуваат. Токенот му припаѓа на личност, додека тунелот што мора да се крене по распоред му припаѓа на машината.

Ако задачата мора да се поврзува повторно без надзор, прашајте дали машински сертификат или сервисна сметка може да го замени интерактивното најавување. Автоматизирањето на нечиј еднократен код го претвора вториот фактор во зачуван таен податок, што е промена на политика, а не погодност за скрипти. Онаму каде услугата ги поддржува двете, изберете ги акредитивите што одговараат на тоа како задачата навистина работи. Запишете го одговорот, бидејќи следната личност ќе праша зошто скриптата држи токен.

Како изгледа скрипта што работи

Скриптата го печати чекорот до кој стигнала, никогаш тајниот податок, и излегува со ненула код при секое неуспешно очекување.

Тестирајте ја со намерно кршење: погрешна лозинка, погрешна група, истечен токен. Секој неуспех треба да запре на именуван чекор наместо да виси. Потоа пуштете ја еднаш против вистинската услуга и проверете го тунелот однадвор од скриптата, не одвнатре.