قرار است یک وب‌سرور را از نصب تا بهره‌برداری بسازیم. امشب محیطی آماده می‌کنیم که تغییر اشتباه در آن قابل بازگشت باشد و بتوانیم درخواست مجاز و غیرمجاز را از دو ماشین متفاوت بفرستیم.

این جلسه بخشی از دورهٔ آپاچی در ۵۰ شب است. قرارداد نام‌ها، مسیرها و روش اعمال تغییر را در راهنمای دوره بخوان.

پیش‌نیاز: کار با shell، sudo، IP و سرویس systemd؛ دو VM وب و دو کلاینت مطابق راهنمای دوره.

قبل از Apache چه اتفاقی می‌افتد؟#

HTTP پروتکل درخواست و پاسخ وب است. کلاینت نام را با DNS به IP تبدیل می‌کند، اتصال TCP برقرار می‌کند و درخواست را می‌فرستد. در HTTPS، مذاکرهٔ TLS برای رمزنگاری و بررسی هویت سرور پیش از HTTP انجام می‌شود. Apache سپس میزبان مجازی و مسیر فایل یا برنامه را انتخاب می‌کند. هر خرابی را در همان لایه بررسی می‌کنیم.

روی هر ماشین مشخصات واقعی را ثبت کن:

cat /etc/os-release
ip -br address
ip route
timedatectl status
ss -lntup
mkdir -p ~/apache-lab/evidence

نام‌های www.example.test، app.example.test و wp.example.test محلی‌اند. .test دامنهٔ عمومی برای صدور گواهی نیست. VMهای وب روی 192.168.56.10 و 192.168.56.30، کلاینت مجاز روی .20 و کلاینت غیرمجاز روی .21 قرار می‌گیرند. کارت NAT جدا فقط برای دریافت بسته است؛ آزمایشگاه را به شبکهٔ عمومی وصل نکن.

شاهد و راه برگشت#

Snapshot بگیر و ورود از کنسول را امتحان کن. از هر دو کلاینت مسیر رسیدن به وب‌سرور را بررسی کن. شکست ping به‌تنهایی اثبات قطع HTTP نیست؛ ممکن است فقط ICMP مسدود باشد. پس از نصب، درخواست HTTP و لاگ Apache شاهد اصلی خواهند بود.

در دفترچهٔ هر شب بنویس: هدف، وضعیت قبل، تغییر، نتیجهٔ مورد انتظار، خروجی واقعی و راه برگشت. نمونه‌های این دوره دستور آموزشی‌اند؛ اجرای واقعی همهٔ توزیع‌ها در این مخزن ادعا نمی‌شود.

تمرین: تفاوت «نام resolve نمی‌شود»، «اتصال رد می‌شود» و «HTTP 403» را توضیح بده. پاسخ راهنما: اولی مسئلهٔ نام، دومی اتصال به شنونده و سومی پاسخ برنامه یا وب‌سرور به درخواست است.

منبع: مبانی HTTP در MDN .