تشخیص تفاوت میان خطای بوت یک Pi بدون نمایشگر و خطای شبکه

کارت پیش از آنکه کسی بپرسد کدام‌یک از آن چهار چیز واقعاً شکست خورده، از محفظه بیرون کشیده می‌شود. Pi پس از تغییری در VPN یا شبکه از پاسخ دادن بازماند و نوشتن دوباره تنها حرکت باقی‌مانده به نظر می‌رسد. به‌ندرت چنین است: اجاره می‌تواند جابه‌جا شود، sshd می‌تواند متوقف شود، یا پاسخ می‌تواند از مسیری خارج شود که نمی‌توانید دنبالش کنید، و هر یک از این‌ها راه‌حل خودش را دارد. کار سودمند جدا کردن آن چیزی است که مشاهده کردید از آن چیزی که فرض کردید.

چهار نتیجه، نه یکی

بوت شدن، نشانی گرفتن، گوش دادن و دسترس‌پذیری چهار پیامد جداگانه‌اند و هر یک از آن‌ها می‌تواند شکست بخورد در حالی که بقیه هنوز برقرارند. یک برد می‌تواند بی‌عیب بوت شود و هرگز در شبکه ظاهر نشود. می‌تواند با نشانی‌ای ظاهر شود که کسی انتظارش را نداشت، یا نشانی درست را با SSH غیرفعال نگه دارد. می‌تواند هر سه را درست انجام دهد و باز هم دسترس‌ناپذیر باشد، چون پاسخ‌ها از دروازه اشتباه بیرون می‌روند.

غریزه نوشتن دوباره آن چهار مورد را در یک پرسش جمع می‌کند، و همین است که اغلب یک Pi سالم و هیچ توضیحی درباره اینکه واقعاً چه شکست، به بار می‌آورد.

شواهد واقعاً کجا تمام می‌شوند

پیش از دست زدن به هر چیز سه مورد را بنویسید: نشانی و مسیر بالاسری که آخرین بار کار می‌کرد، آنچه تغییر کرد، و نخستین عملیاتی که از کار افتاد. نام میزبان که دیگر حل نمی‌شود، اتصال SSH که به پایان زمان می‌رسد، و اتصال TCP که رد می‌شود سه مشاهده متفاوت‌اند که به سه لایه متفاوت اشاره می‌کنند. پینگ ناموفق دسترس‌پذیری یک نشانی را می‌آزماید و به هر یک از دلایل بالا شکست می‌خورد، از جمله بردی که هرگز آغاز نشد. از همین رو نمی‌تواند جای آزمون بوت را بگیرد.

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

مسیر دسترسی را روی یک سامانه در حال اجرا بازسازی کنید

مسیر بالاسری و نشانی کنونی را از طریق آنچه پیکربندی شبکه را در اختیار دارد پیدا کنید، سپس آن را با فهرست کنونی کلاینت‌های مسیریاب و با نشانی‌ای که کلاینت SSH به کار برده مقایسه کنید. نام میزبان ذخیره‌شده یا اجاره کهنه DHCP می‌تواند هفته‌ها به مقصد دیروز اشاره کند. سپس تأیید کنید که sshd فعال است، روی نشانی‌ای که وجود دارد گوش می‌دهد و از شبکه مدیریت مجاز است. راهنمای SSH در Raspberry Pi فعال‌کردن سرور و اتصال به نشانی کنونی را دو گام جدا می‌داند، و نصب تازه Raspberry Pi OS دسترسی SSH را به‌طور پیش‌فرض خاموش می‌گذارد.

نام میزبان را می‌توان به ماشین دیگری بازنشانه کرد، و تصویر جانشین با کلید خودش می‌آید، پس اثر انگشت را از مسیری که از پیش به آن اعتماد دارید بررسی کنید نه با کلیک کردن و رد شدن از هشدار. پاک کردن هشدار همان راهی است که تبدیلی موقت در نشانی را به مسئله اعتماد دائمی بدل می‌کند. اگر تنها نشانه همان اعلان کلید باشد، شما با پرسش هویت روبه‌رو هستید نه با پرسش دسترس‌پذیری.

پیش از سرزنش برد، مسیر پاسخ را ردیابی کنید

VPN می‌تواند انتخاب مسیر را تغییر دهد در حالی که پیوند فیزیکی پیوسته می‌ماند، و همین دقیقاً حالتی است که Pi روشن است، گوش می‌دهد و باز هم دسترس‌ناپذیر است. درخواست می‌رسد و پاسخ از تونلی بیرون می‌رود که کلاینت مدیر نمی‌تواند از آن بگذرد. کنسول محلی و سوکت شنوا درباره مسیر بازگشت هیچ چیز اثبات نمی‌کنند، پس تأیید کنید کدام واسط پاسخ را حمل می‌کند و کدام دروازه را برمی‌گزیند. آن را با شبکه‌ای که مدیر واقعاً روی آن است مقایسه کنید، چون این خرابی بیش از هر خرابی دیگری به‌اشتباه برد مرده تشخیص داده می‌شود.

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

هر بار یک مرز، و اینکه نوشتن دوباره چه وقت درست است

پیکربندی را پس از حفظ وضعیت کنونی از طریق صاحبش اصلاح کنید. تعویض مدیر شبکه، خالی کردن دیوار آتش و حدس زدن یک نشانی ایستا سه تغییری هستند که مشاهده بعدی را بی‌فایده می‌کنند. اگر شواهد به مسیر یا فیلترکردن VPN اشاره می‌کند، به روال توقف یا تعمیر خودِ آن کلاینت بازگردید و در چارچوب برنامه بازیابی توافق‌شده کار کنید؛ مقایسه کنترل‌شده چیزی دیگر است غیر از خاموش کردن محافظت روی میزبانی که توضیحش را نداده‌اید.

نوشتن دوباره یک انتخاب بازیابی آگاهانه است که پس از درک داده‌ها، هویت و مرحله‌ای که شکست خورد گرفته می‌شود. این نیست که نبود ورود به سیستم به‌طور پیش‌فرض باید آن را برانگیزد.

سوابق پیکربندی را جایی نگه دارید که بدون Pi خوانده شود، و راهی برای بازگشت که از تونلی که می‌خواهید تغییر دهید نمی‌گذرد. سپس به ترتیب کار کنید: مرحله را از کنسول محلی تأیید کنید، نشانی کنونی را پیدا کنید، شنونده و سیاستش را بررسی کنید، مسیر پاسخ را ردیابی کنید و یک چیز را تغییر دهید. اگر برد هرگز به سیستم‌عامل نرسید، گام بعدی مستندات بازیابی است نه شبکه.