Egy szkript, amely elindítja egy szállító VPN-kliensét, addig függ, amíg le nem jár az idő, és a napló azt mutatja, hogy a kliens olyan ellenőrző kódot kér, amelyet senki nem gépelt be. A jelszót megadtuk, tehát a kézenfekvő következtetés az, hogy a jelszó hibás. Nem az. A kódkérés külön beszélgetés egy külön csatornán, és a szkriptje soha nem nyitotta meg.

Végezze el az alábbi öt ellenőrzést sorrendben. Az elsőnél álljon meg, amelyik megbukik, mert minden későbbi lépés feltételezi, hogy az előzőek teljesülnek.

1. ellenőrzés: egyáltalán olvassa a kliens a szabványos bemenetet?

Teszteljen, mielőtt bármilyen automatizálást ír: küldjön egy ál-titkot a kliensnek a csövön, és figyelje, mi történik. Ha kiírja a kérését, majd vár, akkor nem olvassa a csövet.

Sok kliens közvetlenül nyitja meg a termináleszközt, vagy megtagadja, hogy titkot vegyen egy nem terminál folyamból, hogy egy elkóborolt cső ne szivárogtathasson jelszót. Az OpenVPN a dokumentált kivétel, mert az --auth-user-pass fájlútvonalat vesz. Az egyszeri kódot kérő szállítói klienseknek általában nincs ezzel egyenértékű kapcsolójuk, és a kérésük olyan terminálra vár, amelyet a szkriptje soha nem biztosított.

2. ellenőrzés: van a gyermekfolyamatnak terminálja?

A pty terminált rendel a gyermekhez, ami a kéréseket olvasható kimenetté alakítja, amelyre sorrendben válaszolhat.

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)

A fenti kérési karakterláncok szemléltetőek; másolja a kliens által kiírt pontos szöveget, beleértve a kis- és nagybetűket és az írásjeleket. Minden várakozásnak időkorlátja van, és a lezárt gyermek kivételt dob a státusz visszaadása helyett, ezért csomagolja be a sorozatot, és a fájl végét tekintse hibának. Figyelje meg, mit nem tesz ez a blokk: a gyermek meghal a szkripttel, mert a pty nem leválasztási mechanizmus, a disown pedig beépített shell-parancs, amely nem ér el egy olyan folyamatot, amelyet a szkriptje indított.

3. ellenőrzés: van támogatott nem interaktív bemenet?

A képernyőkaparás elromlik a kliensfrissítéseknél, ezért először keressen dokumentált kapcsolót.

Nézze át a súgó kimenetét token vagy egyszeri kód opció után kutatva, és ellenőrizze, elfogadja-e a szolgáltatás a jelszómezőhöz fűzött kódot. Ahol a kliens hitelesítő fájlt olvas, adjon neki fájlt a kérés helyett:

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

A folyamathelyettesítés olvasható útvonalat ad a kliensnek azokon a rendszereken, amelyek biztosítják a /dev/fd-t. A titok a kliens szempontjából továbbra is titok, ezért tartsa távol a naplóktól, a shell-előzményektől és a folyamatlistáktól. Ha a kliens elutasítja a /dev/fd-t, vagy a hitelesítő útvonalat egynél többször nyitja meg, írjon valódi fájlt szigorú jogosultságokkal, és törölje ugyanabban a szkriptben.

4. ellenőrzés: túléli az alagút a szkriptet?

Alapértelmezés szerint az alagút meghal a szülőjével, ami éppen az ellentéte annak, amire egy indítószkriptnek szüksége van.

A disown -h csak akkor segít, ha a klienst shell-feladatként indította, mert az adott shell feladattábláját szerkeszti, és nem ér el egy olyan folyamatot, amelyet a szkriptje pty-n keresztül indított. Szolgáltatáskezelő a jobb otthon mindennek, aminek felügyelet nélkül újra kell kapcsolódnia, mert újraindítja a klienst, és rögzíti, miért halt meg. Mindenképpen számítson új kódra minden újracsatlakozás után: az egyszeri token az első sikeres hitelesítéskor elhasználódik.

Figyelje, mit tesz a sudo a sorozattal. A sudo jelszókérése nem a VPN kérése, és arra a VPN jelszavával válaszolni a leggyakoribb módja annak, hogy egy egyébként helyes várakozási sorrend mégis megbukik.

5. ellenőrzés: egy ember kódjának szkriptben a helye?

Ezt az ellenőrzést szokták kihagyni. A token egy emberhez tartozik, míg az alagút, amelynek ütemterv szerint fel kell jönnie, a géphez.

Ha egy feladatnak felügyelet nélkül újra kell kapcsolódnia, kérdezze meg, helyettesítheti-e gépi tanúsítvány vagy szolgáltatásfiók az interaktív bejelentkezést. Valaki egyszeri kódjának automatizálása a második tényezőt tárolt titokká teszi, ami szabályzatváltozás, nem pedig szkriptelési kényelem. Ahol a szolgáltatás mindkettőt támogatja, válassza azt a hitelesítő adatot, amely illik ahhoz, ahogy a feladat valójában fut. Írja le a választ, mert a következő ember meg fogja kérdezni, miért tart a szkript tokent.

Hogyan néz ki egy működő szkript

A szkript kiírja az elért lépést, soha nem a titkot, és minden sikertelen várakozásnál nem nulla kóddal lép ki.

Tesztelje szándékos elrontással: rossz jelszó, rossz csoport, lejárt token. Minden hibának egy megnevezett lépésnél kell megállnia ahelyett, hogy függne. Utána futtassa le egyszer az igazi szolgáltatás ellen, és ellenőrizze az alagutat a szkripten kívülről, nem belülről.

Kapcsolódó cikkek