این آزمون درسهای بخش دوم را میسنجد: شبکه و آدرس IP، پورت، پروتکل و بستهها، DNS، کلاینت و سرور، وب و HTTP، رمز عبور، هش و رمزنگاری، HTTPS و گواهی و سرور، دیتاسنتر و ابر. بعد از هر پاسخ، جواب درست و توضیح نشان داده میشود. نتیجهات در همین مرورگر ذخیره میشود (پیشرفت من).
همکارت میگوید «سرور روی 192.168.1.50 است» و تو از خانه نمیتوانی وصل شوی. محتملترین علت؟
جواب درست: 192.168.x.x یک IP خصوصی است و فقط داخل شبکهی اداره معنی دارد
IPهای 192.168، 10 و 172.16 تا 172.31 خصوصیاند. از بیرون، آدرس عمومی یا VPN اداره لازم است.
- سرور خاموش است ← ممکن است روشن باشد؛ مشکل این است که از بیرون اصلاً راهی به این آدرس نیست.
- DNS خراب است ← اینجا اسمی در کار نیست؛ مستقیم IP داده شده.
- پورت 22 بسته است ← قبل از پورت، خود آدرس از اینترنت قابلدسترسی نیست.
در 10.20.5.7/24 چند آدرس در همان شبکه است؟
جواب درست: 256
/24 یعنی ۲۴ بیت برای شبکه و ۸ بیت برای دستگاهها: 2^8 = 256 آدرس (۲۵۴ دستگاه).
- 24 ← 24 تعداد بیتهای بخش شبکه است، نه تعداد آدرس.
- 65536 ← 65536 برای /16 است.
- 16 میلیون ← 16 میلیون برای /8 است.
ping 192.168.1.1 (روتر) جواب میدهد، ping 8.8.8.8 جواب میدهد، ولی هیچ سایتی باز نمیشود. اول چه چیزی را بررسی میکنی؟
جواب درست: DNS، مثلاً با dig و dig @1.1.1.1
اتصال تا اینترنت سالم است (۸.۸.۸.۸ جواب داد). وقتی با IP کار میکند ولی با اسم نه، مشکل در تبدیل اسم به IP است.
- کابل شبکه ← اگر کابل مشکل داشت، ping روتر هم جواب نمیداد.
- گواهی HTTPS سایتها ← گواهی برای همهی سایتها همزمان خراب نمیشود؛ و قبل از گواهی باید اسم پیدا شود.
- RAM کامپیوتر ← RAM ربطی به باز نشدن سایتها با اتصال سالم ندارد.
nc -zv server 5432 جواب «Connection refused» داد. یعنی…
جواب درست: کامپیوتر در دسترس است ولی هیچ برنامهای روی این پورت و آدرس گوش نمیدهد
refused یعنی سیستمعامل مقصد فوراً «رد» برگرداند. دیتابیس خاموش است یا فقط روی 127.0.0.1 گوش میدهد.
- فایروال بسته را بیصدا دور ریخت ← فایروال بیصدا معمولاً timeout میدهد، نه refused.
- رمز دیتابیس اشتباه است ← به مرحلهی رمز نرسیدی؛ اتصال TCP هم برقرار نشد.
- DNS خراب است ← اسم با موفقیت به IP تبدیل شده که به کامپیوتر رسیدی.
کدام برای تماس تصویری زنده مناسبتر است؟
جواب درست: UDP، چون بستهی دیررسیده بیفایده است و ارسال دوباره فقط تأخیر میآورد
برای دادهی زنده، دیر رسیدن از نرسیدن بدتر است. TCP برای وب، فایل و دیتابیس.
- TCP، چون هیچ بستهای گم نمیشود ← ارسال دوبارهی TCP تصویر را عقب نگه میدارد.
- هر دو یکساناند ← فرقشان دقیقاً در همین تضمین و تأخیر است.
- هیچکدام؛ HTTP لازم است ← HTTP روی TCP (یا QUIC) است و برای تماس زنده استفاده نمیشود.
IP سایت را در پنل دامنه عوض کردی. تو سایت جدید را میبینی ولی همکارت هنوز قدیمی را. چرا؟
جواب درست: resolver همکار جواب قدیمی را تا پایان TTL در کش دارد
جوابهای DNS به اندازهی TTL کش میشوند. قبل از جابهجایی، TTL را کم کن.
- تغییر ذخیره نشده ← اگر ذخیره نشده بود، تو هم سایت جدید را نمیدیدی.
- مرورگر همکار خراب است ← رفتار مرورگر درست است؛ جواب کششده را میگیرد.
- سرور قدیمی هک شده ← هیچ نشانهای از هک نیست؛ این رفتار عادی کش است.
در /etc/hosts خط «127.0.0.1 shop.test» هست. dig +short shop.test چه میدهد؟
جواب درست: هیچچیز؛ dig مستقیم از DNS میپرسد و hosts را نمیخواند
getent hosts، مرورگر و curl از سیستمعامل میپرسند (شامل hosts)؛ dig ابزار DNS خالص است.
- 127.0.0.1 ← این جواب getent hosts است، نه dig.
- خطا ← dig خطا نمیدهد؛ فقط جوابی پیدا نمیکند (NXDOMAIN).
- IP عمومی ← shop.test در DNS عمومی وجود ندارد.
python3 -m http.server 8000 در یک پوشه اجرا شده و از گوشی در همان Wi-Fi باز میشود. اگر با --bind 127.0.0.1 اجرا شود چه؟
جواب درست: فقط از خود همان کامپیوتر باز میشود
127.0.0.1 یعنی فقط خودم؛ 0.0.0.0 (پیشفرض) یعنی همهی آدرسهای این کامپیوتر.
- از گوشی هم باز میشود ← گوشی از آدرس شبکه وصل میشود که سرور دیگر رویش گوش نمیدهد.
- هیچجا باز نمیشود ← از خود کامپیوتر با localhost باز میشود.
- فقط با HTTPS ← bind ربطی به HTTPS ندارد.
پاسخ «HTTP/1.1 502 Bad Gateway» از nginx یعنی…
جواب درست: nginx سالم است ولی برنامهی پشتش جواب درستی نداد
5xx یعنی مشکل سمت سرور؛ 502 مخصوص وقتی است که یک سرور واسط از سرور بعدی جواب نگرفته.
- صفحه پیدا نشد ← صفحه پیدا نشد 404 است.
- دسترسی نداری ← دسترسی نداشتن 403 است.
- باید وارد شوی ← نیاز به ورود 401 است.
کدام بخش URL زیر هرگز به سرور فرستاده نمیشود؟ https://shop.ir/p/42?color=red#reviews
جواب درست: #reviews
fragment فقط برای مرورگر است (کجای صفحه).
- /p/42 ← path در خط درخواست میرود.
- ?color=red ← query هم در خط درخواست میرود.
- shop.ir ← host هم در DNS و هم در هدر Host استفاده میشود.
سایتی کوکی «role=user» میگذارد و اگر «role=admin» بیاید، پنل مدیریت را نشان میدهد. مشکل چیست؟
جواب درست: کوکی در دست کلاینت است و کاربر میتواند آن را به admin عوض کند
در کوکی فقط یک شناسهی تصادفی جلسه بگذار؛ نقش کاربر را سرور از روی آن شناسه پیدا کند.
- کوکیها کوتاهاند ← طول کوکی مسئله نیست.
- مرورگرها این کوکی را نمیفرستند ← مرورگرها همهی کوکیهای سایت را میفرستند.
- مشکلی نیست ← این دقیقاً یک حفرهی امنیتی است.
چرا برای ذخیرهی رمز عبور SHA-256 ساده کافی نیست؟
جواب درست: خیلی سریع است و بدون نمک، رمزهای یکسان هش یکسان دارند و جدولهای آماده کار میکنند
برای رمز: هش کند (bcrypt، Argon2، scrypt، yescrypt) با نمک تصادفی برای هر کاربر.
- خیلی کند است ← برعکس؛ سریع بودنش مشکل است.
- قابلبرگشت است ← هش قابلبرگشت نیست؛ مشکل حدس زدن سریع است.
- فارسی را پشتیبانی نمیکند ← هش روی بایتها کار میکند و زبان اهمیتی ندارد.
در فایل تنظیمات یک برنامه «password: UzNjdXJlLVBhc3M=» دیدی. دربارهاش چه میگویی؟
جواب درست: احتمالاً Base64 است؛ encoding است نه رمزنگاری و با یک دستور برمیگردد
echo "UzNjdXJlLVBhc3M=" | base64 -d. Base64 هیچ امنیتی ندارد.
- رمزنگاری قوی است ← رمزنگاری بدون کلید برنمیگردد؛ این با یک دستور برمیگردد.
- هش است و برنمیگردد ← هشها معمولاً هگز یا قالب $نوع$نمک$ دارند و برنمیگردند.
- کلید عمومی است ← کلیدها خیلی بلندترند و قالب PEM یا ssh- دارند.
مرورگر برای https://www.shop.ir خطای «certificate is not valid for this name» میدهد ولی https://shop.ir درست است. چه کنی؟
جواب درست: گواهی را با هر دو اسم (shop.ir و www.shop.ir) در SAN دوباره بگیر
هر اسمی که سایت با آن باز میشود باید در فهرست اسمهای گواهی باشد (یا wildcard).
- کاربرها «ادامه» بزنند ← دور زدن خطا، کاربر را به کلیک روی هشدارها عادت میدهد.
- DNS را عوض کن ← DNS درست است؛ اسم به سرور درست رسیده.
- از HTTP استفاده کن ← HTTP یعنی بیرمزنگاری؛ راهحل نیست.
یک سایت فیشینگ با آدرس شبیه بانک، قفل HTTPS معتبر دارد. چه نتیجهای میگیری؟
جواب درست: ارتباط تو با همان دامنهی جعلی رمزنگاری شده؛ قفل دربارهی صداقت صاحب دامنه چیزی نمیگوید
قفل یعنی «ارتباط امن با این دامنه»؛ همیشه خود اسم دامنه را بخوان.
- سایت قابلاعتماد است ← قفل اعتبار صاحب سایت را تضمین نمیکند.
- گواهی جعلی است ← گرفتن گواهی واقعی برای دامنهای که خودشان خریدهاند رایگان و آسان است.
- مرورگر خراب است ← مرورگر درست کار کرده؛ گواهی واقعاً برای همان دامنه است.
میخواهی یک ربات تلگرام پایتونی را همیشه روشن نگه داری. کدام میزبانی؟
جواب درست: یک VPS کوچک
VPS دسترسی root و اجرای برنامهی دائمی میدهد و کوچکترینش برای یک ربات کافی است.
- هاست اشتراکی ← هاست اشتراکی معمولاً اجرای برنامهی دائمی پایتون را اجازه نمیدهد.
- سرور اختصاصی بزرگ ← برای یک ربات، سرور اختصاصی هزینهی بیدلیل است.
- لپتاپ خانه ← لپتاپ خاموش میشود و پشت NAT است.
یک اسکریپت check-sites.sh بنویس که یک فایل از آدرسها (هر خط یک آدرس) بگیرد و برای هر آدرس اینها را در یک خط چاپ کند: وضعیت (ok، ERROR برای کد ۴۰۰ به بالا، DOWN وقتی اصلاً جوابی نیامد)، کد HTTP، زمان کل و خود آدرس. در آخر تعداد مشکلها را بگوید و اگر مشکلی بود با کد غیر صفر خارج شود. با سرور python3 -m http.server 8000 در ~/site (درس کلاینت و سرور) و یک پورت خاموش امتحانش کن.
راهنمایی
curl -s -o /dev/null -m 5 -w "%{http_code} %{time_total}" URL کد و زمان را میدهد؛ اگر وصل نشود، کد 000 است. با while read -r url; do ... done < file فایل را خط به خط بخوان. ${result%% *} تکهی قبل از اولین فاصله و ${result##* } تکهی بعد از آخرین فاصله را میدهد.
راهحل
#!/usr/bin/env bash# check-sites.sh: کد وضعیت و زمان هر آدرس در یک فایلproblems=0while read -r url; do [ -z "$url" ] && continue result=$(curl -s -o /dev/null -m 5 -w "%{http_code} %{time_total}" "$url") code=${result%% *} time=${result##* } if [ "$code" = "000" ]; then status="DOWN" elif [ "$code" -ge 400 ]; then status="ERROR" else status="ok" fi [ "$status" = "ok" ] || problems=$((problems + 1)) printf "%-6s %s %ss %s\n" "$status" "$code" "$time" "$url"done < "${1:-urls.txt}"echo "problems: $problems"[ "$problems" -eq 0 ]http://localhost:8000/http://localhost:8000/notes.txthttp://localhost:8000/missing.htmlhttp://localhost:8000/imageshttp://localhost:8001/chmod +x check-sites.sh./check-sites.sh urls.txt; echo "exit=$?"ok 200 0.003883s http://localhost:8000/ok 200 0.000969s http://localhost:8000/notes.txtERROR 404 0.000862s http://localhost:8000/missing.htmlok 301 0.000735s http://localhost:8000/imagesDOWN 000 0.000086s http://localhost:8001/problems: 2exit=1ریدایرکت 301 را مشکل حساب نکردیم (کمتر از ۴۰۰)؛ اگر بخواهی مقصد نهایی را بسنجی، -L به curl اضافه کن. 000 یعنی curl اصلاً پاسخ HTTP نگرفت (اینجا Connection refused؛ ممکن بود DNS یا timeout باشد). خط آخر ([ "$problems" -eq 0 ]) کد خروج اسکریپت را تعیین میکند تا cron یا اسکریپت دیگر بفهمد چیزی خراب است. همین اسکریپت، با cron (دورهی لینوکس)، یک «مانیتورینگ» ساده و واقعی است.