هغه سکریپټ چې د پلورونکي 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: ایا د یو کس کوډ باید په سکریپټ کې وي؟

دا هغه کتنه ده چې خلک یې پرېږدي. ټوکن د یو کس دی، خو هغه تونل چې باید پر مهال پورته شي د ماشین دی.

که یوه دنده باید پرته له څارنې بیا ونښلي، وپوښتئ چې ایا د ماشین سند یا د خدمت حساب کولی شي متقابل ننوتل بدل کړي. د چا یوځلی کوډ اتومات کول دوهم فکتور په زیرمه شوي راز بدلوي، چې د سکریپټ اسانتیا نه بلکې د پالیسۍ بدلون دی. چېرې چې خدمت دواړه ملاتړ کوي، هغه اعتبار وټاکئ چې د دندې ریښتیني بهیر سره ځي. ځواب ولیکئ، ځکه بل کس به وپوښتي چې سکریپټ ولې ټوکن لري.

کاري سکریپټ څنګه ښکاري

سکریپټ هغه ګام چاپوي چې ورته رسېدلی، هېڅکله راز نه، او په هر ناکام انتظار کې د صفر نه بېل کوډ سره وځي.

په قصد ناکامه کولو سره یې وازموئ: غلط پټنوم، غلط ګروپ، پای ته رسېدلی ټوکن. هره ناکامي باید د ځړېدو پرځای په نومول شوي ګام ودرېږي. بیا یې یو ځل د ریښتیني خدمت پر وړاندې وچلوئ او تونل له سکریپټ بهر وګورئ، له دننه نه.

اړوندې مقالې