İnterfeys işləyir, amma wg-quick uğursuz oldu: sonra nə etməli

Bölmə qırmızıdır, interfeys mövcuddur və tunel əsasən işləyir — bu, mümkün olan ən çaşdırıcı birləşmədir. Quraşdırma ardıcıllıqdır: əvvəlcə interfeys yaradılır, sonra ünvanlar, marşrutlar, resolver ayarları və hər hansı əlavə əmrlər gəlir. Dördüncü addımdakı uğursuzluq ilk üçünü yerində qoyur, yəni interfeys adı başlamanın sübutudur, bitmənin deyil. Bir əlavə fakt bu qarışıqlığı qurtarardı: uğursuz olan addım.

Qismən vəziyyət normal uğursuzluqdur

Bu davranışı korrupsiya kimi qəbul etməkdənsə gözləməyə dəyər. İnterfeys quraşdırmanın ən ucuz hissəsidir və geridə qalması ən asandır, həm də maşını yarımçıq işləyən kimi göstərən hissə məhz budur.

Hələ mövcud olmayan şey uğursuz addımdan sonra gələn hər şeydir. Uğursuzluq resolver mərhələsində olubsa, ünvanlar və marşrutlar var, DNS isə yoxdur. Əgər marşrut olubsa, tunelin ünvanı var, amma ondan keçən yol yoxdur.

Nəticə bəzi testlərə cavab verən, bəzilərində isə uğursuz olan bir maşındır; insanlar buna görə xidmətin dalğalandığını düşünür, halbuki o, heç vaxt uğurla başlamayıb. Heç vaxt bitməyən xidmət dalğalana bilməz. O, yalnız eyni səbəbdən təkrar-təkrar uğursuz ola bilər.

İlk uğursuz addımı tapın

Yalnız cari statusu deyil, bölmənin jurnalını oxuyun və onu uğursuz işə salmanın başından oxuyun. Son sətir çıxış kodunu deyir; ilk xəta isə nəyi bərpa etməli olduğunuzu deyir.

Bu əmrlər bölmənin vəziyyətini, həmin bölmənin yükləmə jurnalını və canlı tunel vəziyyətini çap edir:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

Resolver xətası, artıq mövcud olan marşrut, sıfırdan fərqli kodla çıxan qarmaq və konfiqurasiya oxuma xətası — hamısı həmin pəncərədə görünür və hər biri öz komponentini adlandırır. Yalnız interfeys vəziyyətindən təxmin etmək bütün bu məlumatı görməzdən gəlir.

Bərpanı təyin edən üç şərt

Təmizləyirsiniz, yerində bərpa edirsiniz, yoxsa bölməni yükləmə yolundan çıxarırsınız — bunu nəyisə yazmadan əvvəl qərarlaşdırın.

İnterfeys sınıq, konfiqurasiya isə düzgündürsə, təmizləyin və yenidən başlayın. Konfiqurasiya səhvdirsə, onu düzəldin və yenə əvvəlcə təmizləyin, çünki qismən vəziyyətin üstündə ikinci menecer işə salmaq bir interfeys üçün iki sahib yaradır. Uğursuzluq maşında olmayan resolver köməkçisi kimi çatışmayan sistem komponentidirsə, bölməni şikayət etməyi dayandırana qədər redaktə etməkdənsə, asılılığı qəsdən quraşdırın və ya silin.

Bu üç hal sirli qırmızı bölmə kimi görünən şeylərin çoxunu əhatə edir. Fərqləndirici sual eyni uğursuzluğun təmiz vəziyyətli maşında da baş verib-verməyəcəyidir, cavab isə adətən ilk xəta sətrindən gəlir.

Yenidən cəhddən əvvəl təmizləyin

Mövcud vəziyyətin üstündə yenidən cəhd yeni səbəbdən uğursuz ola və orijinal səbəbi gizlədə bilər. İnterfeysi onu yaradan alətin özü ilə aşağı salın, sonra heç nəyin qalmadığını təsdiqləyin.

Əlaqəsiz interfeysləri silməyin və host şəbəkə yığınını sıfırlamayın. Hər ikisi kiçik bir obyekti düzəltmək üçün görülən böyük işlərdir və tək uğursuz tuneli digər bağlantıları yenidən qurulmalı olan maşına çevirir. Düzgün əhatə bir interfeys və ona sahib bölmədir. Daha geniş hər şey baş verməzdən əvvəl yazılmış bir səbəb tələb edir.

Bölməni deyil, tuneli sübut edin

Yaşıl bölmə başlama ardıcıllığının sıfırla çıxdığını bildirir. Bu, paketin o tərəfə çatdığını bildirmir və resolverin istədiyiniz kimi qurulduğunu da bildirmir.

Tuneldən sorğu göndərin və onu yaradan vəziyyəti oxuyun:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

Cavabsız əl sıxma yenə də tunelin qurulduğunu və o tərəfin səssiz olduğunu bildirir; bu, heç vaxt başlamayan bölmədən fərqli bir problemdir. Bölmə vəziyyətini, əl sıxmanı və sorğu nəticəsini bir qeyddə saxlayın, çünki onlar ayrı-ayrılıqda uğursuz olur və sistemi yalnız onların birgəliyi təsvir edir.