VPSCrypto
دلیل رمزگذاری سروری که اجاره میکنید، محدودتر از چیزی است که تبلیغات نشان میدهد، اما درست در همان محدودهٔ کوچک، بسیار قویتر است. درایوهای NVMe از کار میافتند و درحالیکه دادههای شما هنوز رویشان است به فروشنده بازمیگردند. نودها از رده خارج میشوند و فضای ذخیرهسازیشان دوباره فروخته میشود. از سختافزار ایمیج گرفته میشود، یا از یک رک بیرون برده میشود. در تکتک این موارد، LUKS همان تفاوت میان یک فایلسیستم خوانا — کلیدهای شما، پایگاه دادهٔ شما، صندوق پستی شما — و یک تودهٔ نویز است که هیچکس نمیتواند کاری با آن بکند.
چیزی که این کار نیست، محافظت در برابر ماشینی است که رویش در حال اجرا هستید. این تفکیک، کل این راهنماست، پس پیش از هر دستوری میآید. بعد نوبت کار میرسد: یک حجم LUKS2 که درست انجام شده، یک پشتیبان هدر، swap رمزگذاریشده، باز کردن قفل از راه دور روی SSH، و برنامهٔ بازیابی برای ریاستارتی که برنمیگردد. سروری که زیر پایتان است را میتوانید بدون مدرک شناسایی اجاره کنید و با مونرو پرداخت کنید؛ رمزگذاری لایهای است که روی آن اضافه میکنید، نه جایگزینی برایش.
رمزگذاری در حال سکون واقعاً از چه چیزی محافظت میکند
رمزگذاری کامل دیسک به یک پرسش پاسخ میدهد، و آن را کامل پاسخ میدهد: وقتی شخص دیگری سرانجام دیسک را درحالیکه خاموش است در دست بگیرد، چه اتفاقی میافتد؟ روی زیرساخت اجارهای، این یک فرض نیست. درایوها از کار میافتند و به تأمینکننده بازمیگردند. نودها بازنشسته میشوند و فضای ذخیرهسازیشان دوباره فروخته میشود. از حجمها در جریان یک بازرسی ایمیج گرفته میشود، یا در یک جعبه از یک ساختمان خارج میشوند.
- پوشش دادهشده. دیسکی خاموش، ایمیجی آفلاین از حجم شما، درایوی بازگرداندهشده تحت گارانتی، نودی از ردهخارجشده، فایل اسنپشاتی کپیشده. در هر یک از این موارد، مهاجم متن رمزشده و یک هدر در دست دارد، و بدون عبارت عبور، داستان همانجا تمام میشود.
- پوشش دادهنشده: ماشینی در حال اجرا. بهمحض اینکه حجم باز شود، کلید در حافظهٔ کرنل قرار میگیرد و فایلسیستم برای هر چیزی که دسترسی root داشته باشد، ساده و خوانا است.
- پوشش دادهنشده: ترافیک شما. بایتهای روی سیم، مسئلهٔ TLS و WireGuard هستند. LUKS هرگز آنها را نمیبیند.
- پوشش دادهنشده: حساب root که به خطر افتاده. نفوذگری که از قبل داخل شده، فایلهای شما را از همان مسیر مونتشدهای میخواند که خودتان میخوانید. کاربرد سختسازی همینجاست، و این دو کنترل جایگزین هم نیستند.
این فهرست عمداً کوتاه است. رمزگذاری در حال سکون یک کنترل ارزان و پرارزش با دامنهای دقیقاً محدود است، و تقریباً همهٔ نارضایتیهایی که مردم دربارهٔ آن گزارش میکنند، از این میآید که در خفا انتظار داشتهاند آن سه خط دیگر را هم پوشش دهد.
نکتهٔ هشداردهندهٔ سختافزار اجارهای، بهروشنی بیان شده
وقتی حجم رمزگذاریشدهٔ شما باز است، کلید در RAM مهمان قرار دارد — و در هر VPS در هر جایی، آن RAM روی ماشینی زندگی میکند که اپراتور از نظر فیزیکی کنترلش میکند. یک هایپروایزر میتواند حافظهٔ مهمان را بخواند. این نه یک نقص در LUKS است، نه در KVM، و نه بهطور خاص در این میزبان؛ این همان معنای اجارهٔ یک کامپیوتر است، و هر ارائهدهندهای که خلاف آن را بگوید، محصولی را توصیف میکند که وجود ندارد.
پس این حسابوکتاب، بیپرده است: رمزگذاری در حال سکون، حملهٔ آفلاین را به چیزی غیرممکن تبدیل میکند و حملهٔ آنلاین را دقیقاً همانجایی که بود رها میکند. درایوی که رک را ترک میکند، بیارزش میشود. سروری در حال اجرا، درست به همان اندازهٔ دیروز در معرض خطر است. هر دو نیمهٔ این جمله همزمان درستاند، و راهنمایی که فقط نیمهٔ اول را به شما بگوید، لطفی در حقتان نکرده است.
آنچه عقربهٔ دوم را حرکت میدهد، مجموعهای متفاوت از کنترلهاست که روی رمزگذاری انباشته میشوند، نه اینکه جایگزینش کنند. چیزی در پرونده نیست که افشا شود، چون ثبتنام اینجا بدون KYC است — فقط یک ایمیل برای تحویل اطلاعات ورود و نه چیز دیگری. پرداخت روی زنجیره تسویه میشود، نه از طریق یک بانک. و حوزهٔ قضاییای که سرور در آن قرار دارد تعیین میکند که اصلاً کدام دستورها میتوانند چیزی را اجبار کنند. تحلیل صادقانهٔ ما از آنچه یک VPS پرداختشده با رمزارز پنهان میکند بقیهٔ ماجرا را باز میکند، و مدخل چهارده چشم جنبهٔ اشتراکگذاری اطلاعات را پوشش میدهد. اگر آن را یکی از چند لایه بخوانید، LUKS ارزشی فوقالعاده دارد. اگر آن را سپری در برابر میزبان خودتان بخوانید، یک سوءتفاهم است.
حجم داده یا فایلسیستم root: پیش از تایپکردن انتخاب کنید
دو شکل برای این کار وجود دارد، و انتخاب دربارهٔ ریسک است، نه دربارهٔ قدرت.
- یک حجم دادهٔ رمزگذاریشده. یک کانتینر LUKS در کنار سیستمعامل. هر چیزی که اهمیت دارد — پایگاههای داده، ایمیل، کلیدها، آپلودها، پشتیبانها — داخل آن زندگی میکند؛ خودِ سیستمعامل رمزنشده باقی میماند. ده دقیقه کار، بدون هیچ ریسکی برای بوت، و در هر لحظه برگشتپذیر. این همان چیزی است که اکثر خوانندگان باید بسازند، و همان کاری است که مراحل زیر انجام میدهند.
- یک فایلسیستم root رمزگذاریشده. همهچیز داخل آن است، از جمله لاگها، فهرست بستهها و تاریخچهٔ شلی که فراموشش کرده بودید. قطعاً قویتر است، و واقعاً سختتر است که روی ماشینی که از قبل در حال اجراست پیاده شود.
دلیل آن دشواری ارزش گفتن دارد، چون هیچ آموزشی هرگز آن را نمیگوید: نمیتوانید فایلسیستمی را رمزگذاری کنید که هماکنون بهصورت read-write مونت شده و به نشست SSH شما سرویس میدهد. هر دو روش واقعی — کوچککردن و کپیکردن، یا cryptsetup reencrypt درجا — نیاز دارند که root آفلاین باشد. روی ماشینی با کنسول خارج از باند، یک نصبکننده بوت میکنید و این کاری روتین است. روی یک VPS بدون کنسول، ابتدا سیستم در حال اجرا را به یک دیسک RAM منتقل میکنید، و اگر هر بخشی از آن اشتباه پیش برود، سرور برنمیگردد و مسیر بازیابی یک نصب مجدد است که دیسک را کاملاً پاک میکند.
پس: همین امروز حجم داده را بسازید، هر چیز مهمی را رویش بگذارید، و رمزگذاری root را تصمیمی در نظر بگیرید که در زمان دیپلوی، روی ماشینی که هنوز چیزی برای از دست دادن ندارد میگیرید. بخش آخر این مسیر را پوشش میدهد، از جمله dropbear-initramfs برای تایپکردن عبارت عبور روی SSH هنگام بوت.
پیش از شروع به چه چیزی نیاز دارید
چیز زیادی نیست، و بخشی از دلیلی که این کار ارزش انجامدادن دارد همین است.
- یک پلن. رمزگذاری هیچ نیاز RAM اضافهای ایجاد نمیکند و تقریباً هیچ CPUای هم نمیخواهد. Cub (1 vCPU / 2 GB / 40 GB NVMe، $5.00/mo) کافی است؛ Scout (2 vCPU / 4 GB / 70 GB، $9.00/mo) اندازهٔ راحت است اگر سرور سرویس واقعی دیگری هم اجرا کند. تنها عددی که اهمیت دارد دیسک است، چون حجم رمزگذاریشدهٔ شما از همانجا کسر میشود.
- Debian 12 یا 13 از کتابخانهٔ قالبها، یا Ubuntu LTS — دستورهای زیر به سبک Debian هستند و نام بستهها در جاهای دیگر فرق میکند. دیپلوی حدود یک دقیقه طول میکشد و مجازیسازی کامل KVM یعنی یک کرنل واقعی با ماژولهای
dm-cryptحاضر، نه یک کانتینر که از دیگری قرض گرفته. - ده دقیقه سختسازی اولیه در ابتدا. رمزگذاری روی سروری که هنوز ورود با رمز عبور را میپذیرد، مثل قفلی روی دری بدون چارچوب است.
- عبارت عبوری که در هیچ جای دیگری استفاده نکردهاید، تولیدشده بهجای ابداعشده، و نگهداریشده در جایی که حتی با از دستدادن این ماشین هم باقی میماند. هیچ بازیابی، هیچ ریست و هیچ تیکت پشتیبانیای وجود ندارد که کمکی بکند.
- جایی خارج از سرور برای نگهداشتن پشتیبان هدر. اسنپشاتهای هفتگی روی هر پلن گنجانده شدهاند، اما اسنپشات از یک حجم رمزگذاریشده هم همچنان رمزگذاریشده است — برای بازگردانی مفید است، و اگر عبارت عبور از دست رفته باشد، بیفایده.
مکان هیچ فرقی در این موضوع ندارد، پس بر اساس قیمت یا حوزهٔ قضایی انتخاب کنید: Amsterdam، Paris، Bucharest و Sofia با قیمت پایه هستند، درحالیکه Zurich، Reykjavik، Stockholm و Kuala Lumpur ضریبی اضافه دارند.
گام به گام
- دیپلوی کنید، سختسازی کنید، و مطمئن شوید CPU از AES-NI پشتیبانی میکند
Debian 13 را از کتابخانهٔ قالبها دیپلوی کنید و ابتدا ده دقیقه را صرف اصول اولیه کنید: فقط کلیدهای SSH، غیرفعالکردن ورود با رمز عبور root، پیشفرض-رد در nftables، بهروزرسانیهای امنیتی خودکار. سپس مطمئن شوید سختافزار شما را برای این کار مجازات نمیکند:
grep -o -m1 ' aes ' /proc/cpuinfo apt update && apt install -y cryptsetup cryptsetup benchmarkدنبال اعدادی برای
aes-xtsدر حد چند گیگابایت بر ثانیه میگردید. هر CPU سرور x86-64 مربوط به دههٔ اخیر دارای AES-NI است، پس رمزگذاری گلوگاه شما نخواهد بود — NVMe زیرش خواهد بود، دقیقاً مثل قبل. - فضا را برای حجم اختصاص دهید
اگر دیسک پلن شما فضای بدون پارتیشن دارد، از آن استفاده کنید — یک پارتیشن واقعی، تمیزترین چیز برای رمزگذاریکردن است:
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT sgdisk -n 0:0:0 -c 0:secure /dev/vda partprobe /dev/vdaاگر قالب کل دیسک را پر کرده، با آن نجنگید. یک کانتینر فایلمحور اینجا یک شهروند درجهیک است، هیچ هزینهای در توان عملیاتی روی NVMe ندارد، و بعداً هم میتوان بزرگش کرد:
fallocate -l 20G /var/lib/secure.img chmod 600 /var/lib/secure.img losetup --find --show /var/lib/secure.imgدستگاه loopای را که چاپ میکند یادداشت کنید — معمولاً
/dev/loop0. همهجا در ادامه،/dev/disk/by-partlabel/secureنوشته شده؛ اگر مسیر کانتینر را انتخاب کردهاید، دستگاه loop خودتان را جایگزین کنید. - آن را بهصورت LUKS2 فرمت کنید — و هزینهٔ حافظه را محدود کنید
این دستوری است که همهچیز را تعیین میکند، پس ارزش خواندن دارد، نه فقط پیستکردن:
cryptsetup luksFormat --type luks2 \ --cipher aes-xts-plain64 --key-size 512 \ --pbkdf argon2id --pbkdf-memory 262144 --iter-time 5000 \ /dev/disk/by-partlabel/secure--key-size 512یعنی AES-256 در حالت XTS، که کلید را به دو نیم تقسیم میکند — این AES-512 نیست، که اصلاً وجود ندارد.--pbkdf argon2idهمان اشتقاق کلید حافظهسخت است که حدس فراگیر عبارت عبور شما را هم از نظر RAM و هم از نظر CPU پرهزینه میکند.--pbkdf-memory 262144آن را در 256 مگابایت محدود میکند، و همان خطی است که مردم حذفش میکنند و بعد پشیمان میشوند. اگر دستنخورده رها شود،cryptsetupهزینهٔ حافظه را با RAM موجود در زمان فرمت تنظیم میکند. اگر بعداً همان هدر را جایی با RAM کمتر باز کنید — یک پلن 1 گیگابایتی، یک محیط ریسکیو، یک initramfs — ممکن است کاملاً شکست بخورد. آن را عمداً محدود کنید. - بازش کنید، رویش یک فایلسیستم بگذارید، مونتش کنید
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \ --allow-discards open /dev/disk/by-partlabel/secure secure mkfs.ext4 -L secure /dev/mapper/secure mkdir -p /srv/secure mount -o noatime /dev/mapper/secure /srv/secure df -h /srv/secureاین دو گزینهٔ workqueue فقط روی NVMe اهمیت دارند و هیچجای دیگری؛
--allow-discardsکارکردن TRIM را حفظ میکند، به قیمت آنکه به هر کسی که دیسک خاموش را در دست دارد نشان میدهد کدام بلاکها در حال استفادهاند. هر دو در ادامه بررسی میشوند — پیشفرضهای بالا برای یک سرور عمومیمنظوره درستاند. - از هدر LUKS، خارج از سرور، پشتیبان بگیرید
این کار را همین حالا انجام دهید، پیش از آنکه چیزی روی حجم باشد که ارزش از دستدادن داشته باشد. هدر تقریباً 16 مگابایت متادیتاست که اسلاتهای کلید را نگه میدارد، و هدر خرابشده یعنی متن رمزشده غیرقابلبازیابی است، فارغ از اینکه چقدر خوب عبارت عبور را به خاطر بسپارید:
cryptsetup luksHeaderBackup /dev/disk/by-partlabel/secure \ --header-backup-file /root/secure-header.img sha256sum /root/secure-header.imgآن را جای دیگری کپی کنید — با
scpپایین بکشیدش، در یک پسورد منیجر بگذاریدش، هشش را چاپ کنید — سپس نسخهٔ محلی را حذف کنید. با آن فایل مثل خودِ عبارت عبور رفتار کنید، چون وقتی با هر عبارت عبوری که تا به حال داشته ترکیب شود، دقیقاً همان است. - چیزهایی را که اهمیت دارند به حجم منتقل کنید
حجم رمزگذاریشدهای که چیزی رویش نوشته نمیشود، از هیچچیز محافظت نمیکند. اول سرویس را متوقف کنید، وضعیتش را منتقل کنید، سپس مسیر قدیمی را bind mount کنید تا چیز دیگری نیاز به پیکربندی دوباره نداشته باشد:
systemctl stop postgresql rsync -aHAX --info=progress2 /var/lib/postgresql/ /srv/secure/postgresql/ mv /var/lib/postgresql /var/lib/postgresql.old mkdir /var/lib/postgresql echo '/srv/secure/postgresql /var/lib/postgresql none bind 0 0' >> /etc/fstab mount /var/lib/postgresql systemctl start postgresqlپیش از
shred-کردن یا حذف دایرکتوری.old، مطمئن شوید سرویس سالم است — و به یاد داشته باشید که روی یک فایلسیستم copy-on-write یا یک NVMe با wear levelling، حذف متن ساده با نابودکردنش یکی نیست. نسخهٔ تمیز این ماجرا این است که حجم رمزگذاریشده را پیش از وجودآمدن سرویس بسازید. - تصمیم بگیرید چطور باز شود، و دربارهٔ آن صادق باشید
این همان دوراهیای است که همه به آن میرسند. حجم را با
noautoبه/etc/crypttabاضافه کنید تا چیزی جلوی بوت را نگیرد، و هر وقت لازم شد آن را دستی روی SSH باز کنید:echo 'secure /dev/disk/by-partlabel/secure none \ luks,noauto,discard,no-read-workqueue,no-write-workqueue' >> /etc/crypttab cryptdisks_start secureاین همان پیکربندی صادقانه است: کلید فقط تا زمانی وجود دارد که شما حاضر باشید، و یک ریاستارت، حجم را بسته نگه میدارد تا خودتان چیز دیگری بگویید. هزینهاش این است که ریاستارتهای بدون نظارت با سرویسِ خاموش برمیگردند.
گزینهٔ دیگر، یک keyfile در
/etc/crypttabاست تا حجم بهطور خودکار باز شود. اگر آن keyfile روی همان دیسک زندگی کند، شما هیچچیزی را رمزگذاری نکردهاید — هر کسی که درایو خاموش را در دست داشته باشد، کلید را هم درست کنار قفل در دست دارد. این کار فقط وقتی معنا پیدا میکند که کلید از جایی بیاید که دیسک از آن نیست: گرفتهشده از یک تونل WireGuard هنگام بوت، یا تایپشده در یک initramfs روی SSH، همانطور که در بخش آخر گفته شد. آگاهانه انتخاب کنید؛ پیشفرضِ باز کردن دستی، همان چیزی است که واقعاً معنایش را میرساند. - swap را رمزگذاری کنید، و کل ماجرا را تأیید کنید
swap همانجایی است که حافظه به یک شیء روی دیسک تبدیل میشود، پس یک حجم رمزگذاریشده کنار یک swap متنساده، دقیقاً همان رازهایی را لو میدهد که داشتید از آنها محافظت میکردید. یک کلید تصادفی در هر بوت، پاسخ درست است — چیزی برای مدیریتکردن نیست، چیزی برای از دستدادن نیست. اول
swapon --showرا بررسی کنید و دستگاه خودتان را جایگزین کنید؛ اگر قالب بهجای یک پارتیشن، یک فایل swap به شما داده، آن را حذف کنید و بهجایش از یک پارتیشن کوچک استفاده کنید، چون یک دستگاه با کلید تصادفی به یک دستگاه بلاکی نیاز دارد:swapoff -a sed -i '/swap/s/^/#/' /etc/fstab echo 'swap /dev/vda3 /dev/urandom \ swap,cipher=aes-xts-plain64,size=512' >> /etc/crypttab echo '/dev/mapper/swap none swap sw 0 0' >> /etc/fstabسپس ریاستارت کنید — حالا که هنوز اشتباهکردن ارزان است — و نتیجه را صادقانه بررسی کنید:
lsblk -o NAME,FSTYPE,MOUNTPOINT cryptsetup status secure blkid /dev/disk/by-partlabel/secure # should say crypto_LUKS swapon --show # should show /dev/mapper/swapآزمونی که واقعاً اهمیت دارد: با بستهبودن حجم، مطمئن شوید
/srv/secureخالی است و سرویسی که به آن وابسته است از اجراشدن سر باز میزند. اگر هر دو درست باشند، رمزگذاری واقعی است، نه تزئینی.
اسلاتهای کلید، هدرها و عبارت عبوری که چرخاندهاید
LUKS2 تا 32 اسلات کلید نگه میدارد. هر یک نسخهای از همان کلید اصلی را در خود دارد که با عبارت عبوری متفاوت پیچیده شده است، و به همین دلیل میتوانید بدون رمزگذاری دوبارهٔ هیچچیز، یک عبارت عبور دوم اضافه کنید:
cryptsetup luksAddKey /dev/disk/by-partlabel/secure
cryptsetup luksDump /dev/disk/by-partlabel/secure | grep -A2 '^Keyslots'
cryptsetup luksKillSlot /dev/disk/by-partlabel/secure 1داشتن دو عبارت عبور از همان ابتدا، پیشفرض درست است: یکی که استفاده میکنید، یکی که نوشته و در جایی دیگر نگهداری میشود. از دستدادن تنها راه دسترسی به یک حجم بهخاطر یک اشتباه تایپی در یک پسورد منیجر، رایجترین راهی است که مردم دادههای LUKS را از دست میدهند، خیلی جلوتر از هر کاری که یک مهاجم انجام میدهد.
حالا تله. پشتیبانی از هدر که پیش از چرخاندن یک عبارت عبور گرفته شده، همچنان حجم را با همان عبارت عبور قدیمی باز میکند. اسلاتهای کلید داخل هدر زندگی میکنند، پس یک نسخهٔ قدیمی از هدر، یک نسخهٔ قدیمی از اسلاتهای کلید هم هست — کلید اصلی زیرین هرگز تغییر نکرده است. اگر به این دلیل عبارت عبور را میچرخانید که ممکن است لو رفته باشد، باید هر پشتیبان هدری را که پیش از چرخش گرفته شده نابود کنید و یکی تازه بگیرید. در غیر این صورت، چرخش هیچ کاری نکرده جز اینکه حس بهتری به شما داده است.
همین واقعیت باعث میشود پشتیبانهای هدر، بهخودیخود حساس باشند: آن فایل 16 مگابایتی بهعلاوهٔ هر عبارت عبوری که تا به حال شناخته، برای رمزگشایی حجم کافی است. آن را همانجایی نگه دارید که عبارت عبور را نگه میدارید، نه همانجایی که اسنپشاتهایتان را نگه میدارید.
کارایی: AES-NI، NVMe و دو گزینهای که ارزش دانستن دارند
cryptsetup benchmark در حدود پانزده ثانیه حقیقت را برای vCPU خاص شما میگوید. روی هر CPUای با AES-NI — که یعنی هر پردازندهٔ سرور x86-64 مربوط به دههٔ اخیر — انتظار چند گیگابایت بر ثانیه برای aes-xts را داشته باشید، بهطرز راحتی سریعتر از NVMe زیرش. سربار عملی روی بارهای کاری واقعی چند درصد ناچیز است، و این سربار مربوط به CPU است، نه تأخیر.
دو گزینهٔ cryptsetup روی ذخیرهسازی سریع اهمیت دارند، و فقط روی ذخیرهسازی سریع:
cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue \
--allow-discards open /dev/disk/by-partlabel/secure secureگزینههای workqueue، صفهای داخلی dm-crypt را دور میزنند و I/O را مستقیم به دستگاه تحویل میدهند. روی یک دیسک گردان هیچ چیزی تغییر نمیکند؛ روی NVMe RAID10 آنها یک گلوگاه واقعی را در عمق صف بالا از میان برمیدارند. برای دائمیکردنشان، آنها را به خط گزینههای crypttab بهصورت no-read-workqueue,no-write-workqueue اضافه کنید.
--allow-discards همان گزینهای است که یک مصالحه دارد. این گزینه TRIM را تا NVMe عبور میدهد، که کارایی نوشتن را در طول زمان بالا نگه میدارد — و همچنین به هر کسی که دیسک خاموش را در دست دارد نشان میدهد کدام بلاکها در حال استفادهاند و کدامها آزادند. این یک نشتی اطلاعاتی واقعی، هرچند اندک، است: تقریباً نشان میدهد حجم چقدر پر است و میتواند سرنخی از ساختار فایلسیستم بدهد. روی یک سرور عمومیمنظوره، کارایی را انتخاب کنید. اگر محتوای حجم شما از آن دسته چیزهایی است که اندازهاش حساس است، discard را غیرفعال نگه دارید.
مسیر فایلسیستم root، و باز کردن قفل از راه دور روی SSH
اگر میخواهید همهچیز رمزگذاری شود، این کار را روی ماشینی انجام دهید که هنوز چیزی رویش نیست — دیپلوی کنید، تبدیل کنید، سپس بسازید. خودِ فرایند تبدیل استاندارد است: فایلسیستم root را درحالیکه آفلاین است کوچک کنید، یک کانتینر LUKS2 در فضای آزادشده بسازید، سیستم را با rsync -aHAX کپی کنید، /etc/fstab و /etc/crypttab را به دستگاه mapper اشاره دهید، سپس update-initramfs -u -k all را اجرا کنید و GRUB را دوباره نصب کنید. بخشی که این کار را به یک مسئلهٔ VPS بدون کنسول تبدیل میکند، همان کلمات درحالیکه آفلاین است هستند: رسیدن به آن حالت بدون کنسول یعنی ابتدا سیستم در حال اجرا را به یک root در RAM منتقل کنید، و این همان مرحلهای است که وقتی اشتباه پیش برود، به یک نصب مجدد ختم میشود.
چیزی که اصلاً استفاده از یک root رمزگذاریشده را روی یک ماشین دوردست ممکن میکند، dropbear-initramfs است — یک سرور SSH حدود 200 کیلوبایتی که داخل ایمیج بوت پخته شده و درحالی گوش میدهد که کرنل منتظر عبارت عبور است:
apt install dropbear-initramfs cryptsetup-initramfs
# Debian 12/13: /etc/dropbear/initramfs/
cp ~/.ssh/unlock_key.pub /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys
echo 'DROPBEAR_OPTIONS="-I 300 -j -k -p 2222 -s -c cryptroot-unlock"' \
>> /etc/dropbear/initramfs/dropbear.conf
echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
update-initramfs -u -k allسپس هنگام بوت ssh -p 2222 root@your-ip میزنید و دستور اجباریِ cryptroot-unlock عبارت عبور را میخواهد. پیش از آنکه به آن تکیه کنید، دانستن سه نکته دربارهٔ آن ارزش دارد. initramfs کلید میزبان مخصوص به خودش را دارد، پس کلاینت شما دربارهٔ عدم تطابقی روی پورت 2222 هشدار میدهد — این طبیعی است و همان دلیلی است که باید برایش یک پورت اختصاصی در نظر گرفت. آن کلید میزبان و authorized_keys شما روی یک پارتیشن بوت رمزگذارینشده قرار دارند که هر کسی که دیسک را در دست داشته باشد میتواند بخواندشان، پس کلیدی برای باز کردن قفل استفاده کنید که کار دیگری انجام نمیدهد. و -s ورود با رمز عبور را در initramfs غیرفعال میکند، که اختیاری نیست.
جزئیات دیگری که روی پلنهای کوچک گاز میگیرد، همان مورد مرحلهٔ سوم است، و اینجا از همهجا سختتر گاز میگیرد. initramfs پیش از آنکه بیشتر RAM شما برای کار راحتی در دسترس باشد اجرا میشود، پس ممکن است هدری که با هزینهٔ حافظهٔ Argon2id بزرگی فرمت شده، دقیقاً روی همان ماشینی که آن را ساخته باز نشود. با --pbkdf-memory محدودشده فرمت کنید، و درحالیکه هنوز چیزی برای از دستدادن ندارید، ریاستارت را امتحان کنید.
روز دوم: چه چیزی تغییر میکند، و چه چیزی نه
خیلی کم، و همین کل نکته است. یک حجم باز LUKS، یک دستگاه بلاکی معمولی است؛ fsck، rsync، df و ابزار پشتیبانگیری شما همگی دقیقاً مثل قبل رفتار میکنند. ارتقای کرنل تأثیری نمیگیرد چون dm-crypt در خود درخت کرنل است. بزرگکردن حجم بعد از ارتقای پلن، دو دستور است — cryptsetup resize و سپس ابزار resize خود فایلسیستم — و به رمزگذاری دوباره نیازی ندارد.
سه عادت ارزش ساختن دارند. ریاستارت را طبق یک برنامهٔ زمانی تمرین کنید بهجای آنکه ساعت 3 بامداد کشف کنید عبارت عبوری که هرگز ننوشتهاید، تنها نسخهٔ موجود است. پشتیبانها را مستقل رمزگذاریشده نگه دارید — restic یا borg به مقصدی خارج از سرور، که کنترلی جداگانه از خود حجم است و حتی با از دستدادن کامل سرور هم زنده میماند؛ افزونهٔ پشتیبانگیری روزانهٔ خارج از سرور $2.00/mo هزینه دارد اگر ترجیح میدهید خودتان آن را نسازید. و پیش از آنکه دیگر برایتان مهم نباشد چه بلایی سر سرور میآید، حجم را ببندید: اجرای cryptsetup close secure پیش از یک خاموشکردن برنامهریزیشده، مهاجرت یا نصب مجدد یعنی کلید از حافظه بیرون میرود پیش از آنکه دیسک از آنِ شما بودن دست بکشد.
از نظر سیاست، چیزی برای مذاکره نیست. شما روی یک مهمان KVM دسترسی کامل root دارید و کاری که با لایهٔ بلاک میکنید به خودتان مربوط است؛ رمزگذاری حجم خودتان مدیریت سیستم معمولی است، نه یک استثنا. سیاست استفادهٔ مجاز دربارهٔ رفتار است — کف سختگیرانهاش نبود CSAM و نبود تروریسم است — و هیچ حرفی دربارهٔ dm-crypt ندارد. آنچه رمزگذاری واقعاً تغییر میدهد، شکل یک روز بد فرضی است: حجمی خاموش که این ساختمان را ترک میکند، فقط نویز است، و این ارزش ده دقیقه از وقت شما را دارد.
پرسشهای متداول
آیا رمزگذاری کامل دیسک جلوی خواندن دادههایم توسط ارائهدهندهٔ هاستینگم را میگیرد؟
نه درحالیکه سرور در حال اجراست. بهمحض اینکه حجم باز شود، کلید در RAM مهمان قرار میگیرد، و در هر VPSای، آن حافظه روی سختافزاری است که اپراتور کنترلش میکند — یک هایپروایزر میتواند آن را بخواند. کاری که LUKS بهطور کامل انجام میدهد، بیارزشکردن دیسک خاموش است: درایوی بازگرداندهشده به فروشنده، نودی از ردهخارجشده، یک ایمیج آفلاین. هر کسی که رمزگذاری دیسک را بهعنوان محافظت در برابر میزبان خودتان تبلیغ کند، دارد چیزی را توصیف میکند که وجود ندارد.
آیا میتوانم یک VPS را که کنسول یا دسترسی KVM-over-IP ندارد رمزگذاری کنم؟
یک حجم داده رمزگذاریشده، بله — کاملاً روی SSH، بدون هیچ ریسکی برای بوت، در حدود ده دقیقه. یک فایلسیستم root رمزگذاریشده فرق دارد: هر روشی نیاز دارد root آفلاین باشد، که روی یک ماشین بدون کنسول یعنی ابتدا انتقال سیستم در حال اجرا به یک دیسک RAM. این کار میکند، و همچنین همان راهی است که مردم سرورهایشان را از دست میدهند. در زمان دیپلوی که سرور هنوز چیزی رویش نیست تبدیلش کنید، و از dropbear-initramfs استفاده کنید تا بتوانید عبارت عبور را هنگام بوت روی SSH تایپ کنید.
رمزگذاری LUKS واقعاً چقدر کارایی هزینه میکند؟
روی هر CPUای با AES-NI، که یعنی هر vCPU مدرن x86-64، چند درصد ناچیز. cryptsetup benchmark را اجرا کنید و aes-xts را در حد چند گیگابایت بر ثانیه خواهید دید — سریعتر از NVMeای که رویش نشسته، پس ذخیرهسازی همچنان گلوگاه باقی میماند. روی دیسکهای سریع، --perf-no_read_workqueue و --perf-no_write_workqueue بیشتر آنچه را باقی مانده در عمق صف بالا بازمیگردانند.
اگر عبارت عبور را گم کنم چه اتفاقی میافتد؟
دادهها از بین رفتهاند. هیچ مکانیزم بازیابی، هیچ کلید اصلی در دست شخص دیگری و هیچ تیکت پشتیبانیای که کمک کند وجود ندارد — این همان ویژگیای است که خریداری کرده بودید. از قبل کاهشش دهید: با cryptsetup luksAddKey یک عبارت عبور دوم در یک اسلات کلید جداگانه اضافه کنید، و یک پشتیبان هدر را خارج از سرور نگه دارید. توجه داشته باشید که پشتیبان هدری که پیش از چرخاندن یک عبارت عبور گرفته شده، همچنان حجم را با عبارت عبور قدیمی باز میکند، پس هنگام چرخاندن، نسخههای قدیمی را نابود کنید.
برای اجرای یک حجم رمزگذاریشده به کدام پلن VPS نیاز دارم؟
رمزگذاری هیچ نیاز RAM اضافهای ایجاد نمیکند و تقریباً هیچ CPUای هم نمیخواهد، پس رده را بار کاری شما تعیین میکند، نه LUKS. Cub (1 vCPU / 2 GB / 40 GB NVMe، $5.00/mo) یک حجم رمزگذاریشده را بدون آنکه متوجه شود اجرا میکند؛ Scout (2 vCPU / 4 GB / 70 GB، $9.00/mo) اندازهٔ راحت است وقتی سرور یک پایگاه داده یا یک سرور ایمیل هم اجرا میکند. تنها محدودیت واقعی دیسک است، چون حجم از همانجا کسر میشود.
آیا رمزگذاریکردن سرورم روی پلنهای شما مجاز است؟
بله — این مدیریت سیستم معمولی است. شما روی یک مهمان KVM با یک کرنل واقعی، دسترسی کامل root دارید، پس dm-crypt، پارتیشنبندی سفارشی و هر چیز دیگری در لایهٔ بلاک، برای پیکربندی در اختیار شماست. سیاست استفادهٔ مجاز رفتار را حکمفرمایی میکند، نه پیکربندی را، و کف سختگیرانهاش در آنجا نبود CSAM و نبود تروریسم است.
آیا باید swap را هم رمزگذاری کنم؟
بله، و این همان مرحلهای است که اکثر راهنماها از آن رد میشوند. swap همانجایی است که حافظهٔ کرنل — از جمله کلیدها و بافرهای رمزگشاییشده — سرانجام به یک شیء روی دیسک تبدیل میشود، پس یک swap متنساده کنار یک حجم رمزگذاریشده، همان چیزی را لو میدهد که داشتید از آن محافظت میکردید. از یک کلید تصادفی در هر بوت از طریق /etc/crypttab استفاده کنید: چیزی برای مدیریتکردن نیست و چیزی برای از دستدادن نیست. در نتیجه، hibernation غیرممکن میشود، که روی یک VPS هیچ هزینهای برایتان ندارد.
